Agile 2.0: Embracing Lean and the Rise of Ultra Light Methods
The Essence of Agile
Over 12 years ago the single most important event in recent software development history took place: the birth of the Agile Movement, and the publishing of the Agile Manifesto.
The dictionary reminds us that agile is an adjective, it means nimble, quick, light, and able to move with ease. In the 1990s before the Agile Manifesto, Software Development was anything but agile. Ideas and methods that had worked once in construction and engineering were forced into the practice of Software Development. The result was abundant effort in planning and estimation, lots of documentation, lots of meetings, detailed process scrutiny, and lots of money spent in project management, but few successful software projects.
Enter the Agile Movement. Unlike other initiatives it didn’t come from a bunch of scientists or academics trying to invent a better mousetrap, but from 17 software professionals and software project managers who knew the main problem were these heavy processes they had been forced to follow. Let me paint you a mental picture so you can understand the situation better. Imagine a top marathon runner doing his best to win the race, but yet he is forced to run wearing a suit, carrying weights in a backpack, and responding to management evaluations and route changes via Bluetooth on his ears. Sounds crazy right? Well that is what had happened to software development in the 90s, well intentioned practices like IBM’s Rational Unified Process, and Waterfall had added heavy demands to the practice of software with detailed roles, requirements, specs, PERT charts, Critical Routes, Analysis Documents, and meetings and approvals galore. At the end of the day projects were overwhelmed by stuff that added no value, and delivered little real code to production.
Just how many of these heavy items were inside the Rational Unified Process? Some estimate them at over 120! And today a leading Waterfall project management method from PMI suggests over 42 processes, plus roles, rules and artifacts! No wonder these methods are collectively called Heavy Methodologies.
Agile Values and Principles guided us out of that mess. And we now have many more successful software projects than before. However the same inclination to over organize, over control, and micro manage software development that we had in the 90s is re-appearing today. Where is this trend you may ask? Well surprisingly it’s been making inroads inside some of the main Agile Methods we have today: Scrum and XP.
What happened with Agile 1.0?
The Values of the Agile Manifesto continue to point us in the right direction today: People and Communication have more value than processes and tools, Working Software is the reason we do anything, Collaboration is how we win, and Embracing Change is the right attitude. This continues to be the good stuff!
However someway on the path of making those values real some Agile Methods over prescribed many practices, roles, rules and “artifacts”; for simplicity sake let us group them together and called them components.
How many components can you identify in Scrum? My latest count of the current Scrum Guide showed at least 17. Extreme Programming has an even larger collection, which is not surprising considering that in addition to Agile project management it includes a variety of best practices for software development. Upon checking Extreme Programming 2nd Edition and other leading sources I found 13 primary practices, 11 corollary practices and 12 rules, making a total between 24 to 36 components total. Clearly these Agile methods are not so lightweight, is this right? Is this truly Agile? I think it was okay for Agile “first generation” but we need something better and lighter today.
Another worrisome aspect is that one of the main Agile methods: Scrum keeps growing year after year, adding more complexity to an already detailed framework. And while even XP revised its methods down to demand a minimum of 13, Scrum demands them all. Add to these growth of the Scrum framework the fact that Scrum practitioners usually use XP programming practices and you start to see the whole picture: a much heavier Agile. And the XP camp is not that light either, many XP practitioners take Scrum practices into their already detailed Agile method. The result is heavier Agile, Agile methods that demand a lot from the developers and teams, no wonder nowadays we have Agile resistance!
Less is More: Lean enters the picture
The best way to understand this phenomenon is by looking at Figure 1 graphic, it shows visually the relative size of the main Agile methods: Scrum, XP and Kanban.
Did you notice something new on Figure 1? Yes! Kanban is much lighter than the other Agile methods, it is one of the few next generation Agile Methods we have today. I call it an Ultra Light method, and it’s Agile, but a different kind of Agile.
So where did Kanban came from? While the West was busy with the Agile Movement, quietly a revolution that started in Japan reached our shores. The movement is called Lean today, but it originated in Toyota as part of their relentless pursuit of zero waste, total quality and more customer value. The result is what Taiichi Ohno called the Toyota Production System or TPS. Even though the system was born with a manufacturing bias, in the late 2000s several Western authors adapted it to Knowledge Work and Software Development. Key among them are Mary and Tom Poppendieck, Bob Charette, Corey Ladas, Jim Benson and David Anderson.
Now why does this Lean movement matter? Mainly because the key ideas of Lean are based upon the principles of Zero Waste, Total Quality, System Thinking and delivering Value. So what happens to a software project that does away with wasteful activities, aims for total quality, looks at the big picture and delivers value to customers? It becomes Agile! And it does so with far less practices than our beloved Agile 1.0 methods!
Kanban takes these ideas from Agile and Lean and combines them into a powerful Agile method. It is the first Ultra Light method, but it is not the only one. Arguably the ideas from Eric Ries’ Lean Startup are also another Ultra Light method, although this time applied to entrepreneurship.
Agile however has not stood still either. Whether you noticed it or not, Agile movements like Scrum have started getting some of the ideas of Lean and Kanban and absorbing them into their own practices. The problem is that as a consequence they have grown more complex, heavier not lighter.
The Ultra-Light Revolution: Agile 2.0
But what if there was a better way? A way to reboot the Agile movement and move it forward to embrace a new generation of Ultra Light Methods? Agile 1.0 was about Light Weight Processes and Methods, but now with Lean we can achieve similar objectives with Ultra-Light methods!
The graphic below summarizes what Agile 2.0 is: the best ideas from Agile and Lean combined to deliver the simplest, most powerful forms of Agility for Software Development and IT. It is not just Lean, it is not just Agile is the best of both worlds.
An added benefit of Agile 2.0 is that because it is so light it can extend beyond Software and IT into a whole company, or even your personal plans and to-do lists!
As of now only Kanban qualifies as an Ultra Light method to achieve Agile 2.0 for IT and software development, but this is just temporary. I believe Scrum, XP and any other Agile method can get the best ideas and principles of Lean, simplify itself and be rebooted into a leaner, faster, lighter form of Agile! It’s up to us to make Agile 2.0 flourish, grow and bring a new revolution of productivity everywhere. The time has come.
If you would like to find out more about Kanban in particular, we recommend you read about Open Kanban, and Kanban Ace. Open Kanban is the first Agile and Lean method that is fully open source. Kanban Ace extends Open Kanban to address the needs of IT, Software Development and business.