The Origin Story of Scrum, Extreme Programming, and Fluid Scaling Technology (FAST Agile) Share a Common Thread.
I once went on a personal development class out in the woods where the instructor was trying to give us new ways of thinking and being. Frustrated that we were all drifting off in a session and sensing we were not getting his message, we were all marched down to the river and told to jump in. No changing your clothes or taking your shoes off — jump in, now, do it. Then we got to trudge back to the lecture room and all sit there sopping wet and dripping on the floor. Sometimes — a radical change is what is needed to cause a shift.
Below are three examples of a radical shift in the origin stories of Scrum, Extreme Programming (XP), and Fluid Scaling Technology (FAST Agile).
Extreme Programming was born from Chaos. A lot of innovation is. Chaos is not a bad thing — it is in fact a creative thing. More on that in another blog. But for now, the chaotic environment that Extreme Programming emerged from is an interesting story; a large project running way behind on schedule hires a guru (Kent Beck) to “fix” things.
Guru realizes that things are so dire so why not pull out all the stops and change everything? The project is fairly much doomed anyway so why not try something radical?
What are the best practices in software development? Let’s do all of them, at once, to the extreme (where the name Extreme Programming came from). No introducing them one at a time. Things are too desperate and we don’t have time. This is an emergency.
So they did — and Extreme Programming was born. (It didn’t manage to salvage the project, but a bold new agile method was born.)
In the book Scrum: The Art of Doing Twice the Work in Half the Time by Jeff Sutherland, Sutherland shares his origin story for Scrum.
“I decided the best option was for us to change everything. The operation was too broken to fix piecemeal… We came up with tools that found their way into Scrum ten years later” — Jeff Sutherland
So again we see this pattern of changing everything.
Not usually recommended, but there is a time an place.
Fluid Scaling Technology (FAST Agile)
FAST was also created by changing everything — well kind of. In fact, we were one large team and I wanted to work out if we could stay together as one team instead of splitting into two when we took on a second product (which would have been the standard Scrum answer). Not wanting to split the team was the driver to find a different agile method, which led to changing fairly much everything else and discovering a whole new agile method.
The experiment we tried was to use something similar to Open Space and create a marketplace of work. As long as all the work got done on both products, who cared who was on which product or which team? It gave people the opportunity to move between products, and allowed the business to flex effort should there be a need for more focus on one or other product at any time.
In the end, we had no stories, no story points, no acceptance criteria (well, it was optional). Reflect and improve and forecasting changed shape drastically also. We pretty much changed everything that was in traditional scrum and agile. The conditions that made this safe were that there were no looming deadlines, we had a lot of autonomy, and we agreed to try it for a few months and then evaluate if it was working. Of course, there was always the option of stopping sooner if the experiment was an obvious failure.
Well — the experiment ran for two years. It eventually stopped and the reasoning for that is as important as knowing what worked. There is a fuller account over on the Agile Alliance website in an experience report with the title Self-Organization Eats Agile at Scale for Breakfast.
Experimentation leads to new results. Changing one thing at a time is usually the best way to make incremental gains. But, every now and then, if it is safe, try changing many things at once. In complex systems, changing one thing at a time might not return you the same effect as changing several things. It is in the relationship between those things that new behaviour might emerge. Changing one thing at a time may never have gotten us Scrum, Extreme Programming or FAST Agile.