The Lean Agile Sandwich
Adopting agile is a hard exercise, especially in larger organizations. All to often agile adoption initiatives come to a stop after a while and things return to the way they were before but now with some new terminology and ceremonies like a daily standup.
There are two causes that I encounter at my customers when this happens.
In the first one there has been this bottom up movement driven by XP practices and Scrum. Teams are working in iterations, are having fun and making progress, but the business does not really see any benefits or even care. “It’s their problem how they do things, this is what I need you figure it out how to deliver it”. In these situations you typically see that requirements are still written upfront but then translated into user stories by the teams, business does not accept or reject anything at the end of a sprint, prioritized backlog is development’s problem and definition of done…. not really. You also see that teams are broken up regularly, new work and change of requirements during the sprint is common practice, other departments e.g. the test department are not really participating and management keeps commanding and controlling the teams. Ever seen a situation like this?
Then there is the second scenario. Management decided to do Scrum or Lean. A book or two is bought, people are send to Scrum master trainings, …. and that’s it! What you encounter is a situation where management behaves just as before “Lean is just a new name to things we already know from classical management theorie”, scrum terminology is used, the daily standup is done and maybe there is even an estimated product backlog. But sprint after sprint no working software, teams spent lots of time on architecture, design and philosophical discussions, no automated testing, mini waterfalls in a sprint, no common understanding of quality code and maybe most importantly no team self organization and commitment. I have even seen a team have a scrum board with stickies but during the whole sprint nobody even looked at the board let alone move a sticky!
I concluded that there must be something fundamentally wrong with the common agile adoption initiatives. When I started guiding teams about 8 years ago it was good enough to ‘just start somewhere’. The idea was and for many still is ‘just start and see where it leads’. I think that we can do much better then that. This naive approach reminds me of a quote of Yogi Berra “If you don’t know where you are going, you will wind up somewhere else.”
The approach I found successful over time I is a approach where you use Agile bottom up and Lean top down. I call this the Lean Agile Sandwhich. Agile bottom up because Scrum, XP, self organizing, trust and openness appeals to many developers. Lean top down because management easily relates to things like waste removal, making full use of people’s potential, continues improvement and optimize the whole. This obviously does not mean that Lean is understood, but it helps get a very good start!
The approach I use differs from situation to situation but the main things I always plan to do are the following
Lean top down
0. Lean awareness workshops with management to discuss the change from command and control to supporting and coaching of people. These are multiple day workshops with home work and exercises to do in their own working environment.
1. Establish a change team, of people from management, that support and promote Lean over departments and solve impediments that are out of the scope of the individual teams. Ideally some people that participated in the Lean awareness workshops become part of this team.
2. Define what KPI’s you need to measure progress on adoption. Let management answer the question “when are you satisfied?”.
3. Establish Product Owner teams consisting of people from the business with support from IT people. This team prioritizes and streamlines and “evens out” work going into their development teams.
4. Make retrospectives or “Kaizen events” part of the ritual of management.
5. Provide hands-on coaching for product owners and management on leadership and lean management.
Agile Bottom up
0. Realize optimizations teams on topics like agile testing, Scrum, agile architecture and agile requirements consisting of people from IT to promote and improve their specific craft across the departments.
1. Establish a common understanding of software quality and agile development practices through leading workshops, programming kata’s, trainings and discussion.
2. Agree upon a minimal definition of done that Scrum teams can extend as they wish. (A Scrum team being the product owner, Scrum master and the team)
3. Define measures that give management insights into the capacity and performance of the IT department as a whole and performance of the individual teams. Things I often propose are, tested features delivered, WIP, code quality and variation in velocity.
4. Provide hands-on coaching for scrum masters on team building and Scrum.
A key point in all this is that you start with what is already there. No big changes at once, encourage change only when things become an obvious waste and people understand it themselves. Let people ‘remember’ what’s best to do.
In order to see how things are going I use the following ‘indicators of progress’ in addition to e.g. the Scrumbutt test.
1. Is management having productive retrospectives regularly on impediments raised by the teams?
2. Does management focus on flow instead of utilization?
3. Does management use visual management tools like a board?
5. Is management working on interactions between departments and people instead of the departments and people themselves?
6. Are there KPI’s that force cooperation among department managers to optimize globally?
If I can answer all the above questions with YES then this gives me a good indication that lasting change is taking place.
In following blog posts I will discuss more on how I do these things.