– Machiavelli
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 requires 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 was facing some problems. We were not able to deliver the features at the pace we wanted. Simply put, what we were doing was not working very well, and if nothing was 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:
Bad focus
Most of the developers on the team had other commitments outside the project: Other projects, production issues and so forth. We had a taskboard 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 to be a problem for many software teams. Oftentimes, teams deliver too much code too fast, leading to low quality code with high defect rates. Finding defects late is extremely costly…. Furthermore, delivering low quality software will cause disturbances for other projects as well since developers get assigned to look 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. Like so many other teams we were not doing all the things that Scrum specifies, 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. A perfect opportunity for a change. But since I didn’t have any experience with Kanban I really needed some external backing.
