Benjamin Mitchell from BNP Paribas presented an experience report on moving from Scrum to Lean and Kanban yesterday at XPDay 2009 in London. During the initial phases of the project, before he joined, consultants were called in to help implement Scrum. Soon after the consultants left there was a backlash on anything labelled “agile” among business users. Mitchell gave the example of a trader that got furious after his 50-page requirements document was thrown in the bin. From what I could make out from the presentation, there was a general distrust between the business and development team. At the point where Mitchell took over the project, it was so “politically toxic” that the only way to run it was to make everything very visible to mitigate political risks.
Making things more visible
The first thing Mitchell did is reorganising the task board from a classic scrum board to something that gives stakeholders much more visibility. The new board had a much more detailed breakdown of work phases on the horisontal axis and people on the vertical axis and work tasks placed on the grid with post-it notes. Mitchell took a picture of the board to the eXtreme Tuesday club to get feedback, which pointed to several problems. Developers were hoarding tasks with one particular developer completely overloaded with tasks he started. Things were also being batched up in the testing column, which pointed to a problem that most testing was done at the end. The redesigned board also made it visible that starting a new task is easy but that finishing a task was hard.
Moving away from scheduled meetings
Mitchell said that “in an environment where politically you can’t say No, the idea you have to stop and re-plan didn’t work”, so the typical scrum concept wasn’t really working for them. Wanting to “have some benefits of Scrum without running scrums”, they set up several rules for a task to move from one column on the board to another. Once a piece of work is ready for development, a developer was supposed to talk to at least one other developer about the intended changes. The team was responsible for deciding whether to organise a design meeting if they needed it. Before finishing a task, developers were required to write a how-to-test document. The testers were asked to spend one hour a day doing acceptance testing for tasks in development even if they are doing release regression testing that day. This improved the feedback after development and made things move quicker across the board.
Limiting work in progress
With the improved visibility they realised that “the more things you try to do at once, the slower it goes”, but it was hard to find the exact point where to cut it. In order to improve visibility even more, they reorganised the task board again. Instead of swim-laning by people, they started using swim-lanes for tasks in progress. They also had a date stamp to mark the start and the end of development on a task, helping to track how long things took to get through the flow. They extended the task board more upstream, adding analysis. Perhaps the most important change at this point was using stickers to represent developers so that a developer could work on only one task at a time and tasks weren’t assigned to developers until they are ready. This resulted in establishing a task queue for things that were analysed but not yet being developed.
Moving to a pull system
The next step was to sort out things piling up in the analysis queue. “What you really want to do as a project manager is not let the stuff start”, said Mitchell, adding that “specifications are like bananas, you can warehouse them but not for long”. Analysis was moved closer to development in the process and developers were allowed to pull tasks to analysis. By this time, it seems that the trust was restored and that the team was delivering things quicker. According to Mitchell, his team was no longer the bottleneck so they shifted the responsibility for slow deliveries to other teams. Seeing the analysis queue and understanding what goes on, traders started to realise that there is a limit to how much work can be done. “[They] stopped telling us about low order stuff”, said Mitchell. The board was changed again, and a limit of four swim-lanes for tasks in progress was imposed. The entire team started swarming on a feature. This helped reduce the queueing even more.
Giving up on time-boxed iterations
After a release with critical bugs, they stopped doing anything that wasn’t directly aimed at solving the problems. This resulted in six weeks without scrums or estimations or any other process overheads. After this, the team realised that the development works just fine with the flow and they kept it like that. Instead of time based iterations, they now had work-based cycles. Two week releases were still kept as a heart-beat.
Kanban to reduce political dangers?
This experience report was very interesting for me because all the changes were largely driven by political dangers. The need to increase visibility to mitigate political risks led to interesting discoveries about process flaws and improvements which help rebuild trust and improve the team’s capacity for delivering. It is also interesting that a quality crisis made them move from time based to work based iterations, which reminded me of the story of migration to lean and kanban at uSwitch.com.
