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.
Further Reading
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.
Comments
Your style is so unique in comparison to other people I've read stuff from. Thanks for posting when you've got the opportunity, Guess I'll just bookmark this web site.
Great article, I find this truly a breath of fresh air for all of us in IT Project Management. Keep up the good work!
Great article, but given the very small overlap is Kanban necessarily Agile. Surely Lean and Agile are different things?
I totally agree that project manager and other managers are trying to "over process" agile methods. Concentrating on the delivery of value of process...is the way to go.
I have been employing Kanban concepts in our development activities for years now, and will never go back. (Unless, of course, the team really believes Scrum would be better for the team). Scrum is very prescriptive, dogmatic. I've seen It be used to do silly things, like full resets on our progress board, irrespective of the valuable information, or the expectations that one can estimate all tasks during a planning session. Scrum fails to be agile when perturbed. For example, as soon as a critical bug pulls a team member away, the timeline and process falls apart.
Kanban allows us to react to external and internal pressure in an agile manner. My observations indicate that a mature team will naturally adopt Kanban concepts without realizing it is Kanban.
A well written and vibrant article. My only comment - the components that are seen to weigh down XP or Scrum are there for a reason - they introduce discipline for Agile purists, i.e. for people & their interaction, and not meant to weigh down prj management. As JS says, Scrum fails to be agile when perturbed - agree. I'm now going to investigate Kanban / ULM - once again, a good article.
I like the article very much and because I'm a contrary by nature, would like to offer a counter thought. I believe that the big benefit of Agile is that it allows the business to be flexible, change direction and respond to environmental pressures. Scrum (don't know enough @ XP to say) at least allows for a reset of business priorities every 2-4 weeks. To be Agile, it takes a lot of self discipline and the team has to hold itself/each other accountable and having a few more rules can actually make it easier. Kanban, which we use @ Red Hat, has a bunch of'hidden' rules within in it in the form of policies that the team develops to pull from state to state, e.g.from analyzing to developing. So my opinion is that having more constraints in the form of rules can actually make a team more Agile, not less.