Lean as the solution to scale agile methodologies

Agile Methodologies have already proven how efficient they are when applied on small teams to deliver software with great quality, predictability while nurturing team spirit and fostering people engagement. There are tons of literature on that very subject out there and, in 2010, Gartner predicted that by 2012 80% of software development project will be carried out using Agile methodologies.

As these methodologies have proven their value and became industry standards for small projects (PMI added the PMI Agile Certified Practictioner as a new certification which says a lot about how well this methodological toolbox has been integrated into corporatica), the detractor voices became less and less audible but for one point : scalability. The official anti-agile persona (usually not comfortable with the change of culture related to the implementation of Agile methodologies) know they have a point here : how to scale agile on large projects with many teams ?

Henrik Kniberg’s book Lean From the Trenches : Managing Large Scale projects with Kanban is the definite answer to this last question…

The scalability conundrum

Up until lately, I could not find any clear answer on that very question that makes agilists somehow feel uncomfortable. Thanks to the remarkable effort started by Tom & Mary Poppendieck with their first book in 2003, Lean Software Development has slowly became the de-facto solution.  There have been many books written on the topic : Poppendieck’s series (1, 2 and 3), Scaling Lean and Agile Development by Bas Vodde and Craig Larmann or Lean Agile Software Development by Alan Shalloway.

We also have witnessed the emergence of new concepts mixing Scrum and Kanban : Henrik Kniberg wrote a small essay on the topic. And here he comes now with a full book.

Henrik’s pragmatic answer

I have nothing but huge respect for his work. Together with Kathy Sierra, Scott Berkun, Danah Boyd or Hugh McLeod he was amongst the people who inspired me and get my blogging starting 5 years ago. His book Scrum and XP From the Trenches (a book I blogged about not once but twice) is probably one of the most important essay about the Scrum software development agile method.

The great thing about Henrik pragmatic approach is that he never pretends to teach the perfect theory. His goal rather is to provide feedback on the way he did it, what worked and what didn’t. This is the same perspective at work in this new book.

In his very clear style, with humility and tongue-in-cheek humor, Henrik makes it look so simple to implement Lean to scale Agile methodologies to large projects.

The case study is a 15 months software development project involving up to 60 people  for a public organisation (Swedish Police). As usual, #hypertextual has collected 10 main takeaways.

Lean From The Trenches in 10 points

1. In order to control risks, the project has been sliced alongside both the functional dimension (small increment of features) and the audience axis with gradual geographic deployment.
2. Welcome the flow and bye bye iteration. While mixed with Kanban, Scrum loses some artefacts. There is no such things as a backlog of User Stories to plan during a long Scrum planning session : planning is done on a user story and regular basis.
3. Welcome Lead Time and bye Story points. While story points are a perfect metric for a couple of agile team it just does not scale up to large projects since the actual value of story point is not consistent between different teams. Besides, Lead Time is a much more appropriate metric to drive the flow and provides a more meaningful visibility on the predictability of the process in this context. Interestingly enough, regardless of the side, the lead time of different features tends to be consistent.
4. Teams are cross-functional with developers analysts and testers. There still is a system test team dedicated to integration testing
5. If they are not to start with, teams naturally become cross-functional when the stream of activities is driven by a Kanban. When an item is blocked down the process flow and no other items can progress from one state to the next, the whole team work to fix the problem and ensure the flow is back on a running state.
6. There are 3 levels of morning sprints (ouch !). One for the team then one for the team leaders / analysts across all teams and then one per discipline (developers, analysts, testers).
7. Forget the tools : the whole project is driven by a Kanban as a good old board with post-its. Great advantage of the board approach on the online tool is that it takes about 2 mns to change the format of the Kanban – you don’t have to change the customisation of your software for the change to be implemented. And it’s all there for people to see. Same with bugs : tracked on post-its !
8. Collaboration is drastically improved when the rules are clear and simple. Spending time to clearly define the Done status (“Ready to Development” for user story and “Ready for system Test” for software) made collaboration between teams much smoother. Indeed, unclear and /or complicated rules make collaboration more difficult.
9. Continuous improvement is based on clarity (with physical boards), close communication (process improvement on a weekly basis) and data (simple metrics – see points #3). There are two levels of retrospective : at team level and, cross-team, at leaders level
10. Making impediment clearly illustrated on the board is the best way in making sure it will be tackled as it become everybody’s problem

An impressive thing with Lean is general and this book in particular is how simple it looks. It almost seems deceptive. But as 37signals said : “Simple requires deep thought, discipline, and patience – things that many companies lack.”

So let’s be disciplined, patient and thoughtful and implement Lean as a mean to scale Agile methodologies.

PS : Pour les lecteurs français, cf cette vidéo de @hervelourdin à la conférence  USI 2011 : La règle de Trois n’aura lieu. Un autre pays, un autre métier, un projet de dimensionnement semblable, une approche identique et des résultats qui semblent tout autant positifs. Extrêmement instructif.