Agile software development is not about whether you do Scrum, XP or Kanban. It is about finding a process that works in the environment you’re in. Finding this can be hard, and doing so certainly require reflection about what you are doing, how you’re doing it and why. One thing’s for sure, if you are doing something and it doesn’t work: Stop doing it!
About three months ago, the project I was working on were facing some problems. We were not able to deliver features at the pace we wanted. Simply put, what we were doing was not working very well, and if nothing were done we risked missing our end date. Failure is never fun, so we decided to do something about the situation. The following were our main problems:
Most of the developers on the team had other commitments outside the project: Other projects, production issues and so forth. We had a task board but the team members were sloppy with the updates. As a consequence, visibility was low and focus was taken away from what was really important: Delivering value for the customer.
Quality of code delivered
This was not a problem unique for our project. Rather, I believe this too be a problem for many software teams. Oftentimes, teams deliver too much code too fast, leading to low quality code with high defect rates (see Kanban – the next step in the agile evolution?). Finding defects late is extremely costly…. Furthermore, delivering crappy software will cause disturbances for other projects as well since developers get assigned to looking at production issues. A very destructive cycle indeed.
Planning and estimation
Scrum prescribes a sprint planning meeting where the goal is to establish the goal of the sprint and commit to a set of user stories or tasks. In our case, the project had inherited the habit of doing detailed task break-down and estimation of each of the tasks. I had long questioned the value of this kind of detailed estimation,
there’s just too much micro management going on. I
Like so many other teams we were not doing all the things that Scrum prescribes, I guess we had a ScrumBut implementation. More importantly, the process did not work. So a change was definitely needed…
How Kanban was introduced
I had read Corey Ladas Scrumban book and my interest for Kanban was definitely rising. The ideas of just in time, limiting work in progress and small batch sizes to reduce code in inventory (to name but a few), seemed very appealing indeed. And here we were, with a project of reasonable size and complexity, failing to deliver at the required pace. The perfect opportunity for a change. But since I didn’t have any experience with Kanban I really needed some external backing.
Getting External confirmation
The external backing was found in the Scrum vs Kanban article written by Henrik Kniberg. It is an excellent article, easy to read and it explains the fundamental aspects of the process in a clear and precise manner. The article was distributed to the project manager and the the domain expert on the team in order to test the water. They liked what they read and hence, we decided to talk to the rest of the team about applying such a change.
When selling the change to the rest of the team we emphasized that moving towards Kanban was not a revolution, applying a few changes to our existing process would do for a start.
(The external confirmation is a pattern from Linda Rising and Mary Lynn Manns Fearless change book.)
People fear change. Change disrupt peoples lives. It means learning new things, or doing things differently than they’re used to. Quoting the great Italian philosopher/writer Machiavelli
“And let it be noted that there is no more delicate matter to take in hand, nor more dangerous to conduct, nor more doubtful in its success, than to set up as a leader in the introduction of changes. For he who innovates will have for his enemies all those who are well off under the existing order of things, and only the lukewarm supporters in those who might be better off under the new. This lukewarm temper arises partly from the fear of adversaries who have the laws on their side and partly from the incredulity of mankind, who will never admit the merit of anything new, until they have seen it proved by the event.”
People need to experience for themselves that a change has a positive effect in their work environment. This is more likely to happen if you do small incremental changes. Also, do to many things at once and it’s going to be hard to determine which change had what affect. With this in mind our decision was to make the following 2 changes:
- Limit work in progress
- Introduce test (system test and acceptance test) as stations in the workflow
The observed effect of applying these changes were:
- Improved visibility
- Better focus
- Fewer bugs because of increased test focus
- Renewed enthusiasm in the team
Reflect and improve
We avoided the trap of doing too many changes too quickly, letting the effect of the first changes appear. Oftentimes, changes to one part of the system will reveal potential problems in other parts. So to in our case. After adding WIP limits and adding system test as a separate station, we observed that if the tasks in progress were truly testable, then this would make it much easier for the testers on the team. A pleasant side effect of this decision was that tasks were now focused on business value and less on technical details (which in many occasions can generate waste)
Change is emergent
The move towards Kanban turned out to be a happy move for us. The project delivered on time and under budget. It is my opinion that applying small changes to the process were an important factor. Changing the process using small steps without turning the world upside down, made the effect of the changes highly visible, thereby gaining faith in the new process.
“One change always leaves the way open for the establishment of others. “