Feature Flow – Increasing velocity using Kanban

A few months ago I was joined a software development team that had some problems getting their process right. The team was doing Scrum by the book, apart from regular production releases they were doing it all: sprints, planning, retrospectives, Scrum board etc. This team didn’t need too much explanation of Scrum so I could dive into development straight away, or so I thought. They struggled with getting the sprints right, their velocity was decreasing and spirits were low. Luckily we managed to change our process by changing some basic Scrum practices and replacing some of them with Lean practices, inspired by the new Kanban articles and presentations. Productivity is now higher than ever and we can now focus on what really matters: product quality and customer satisfaction.

Work In Progress
When I started at this team, they had one major issue: getting things done. The major symptom was the frustration of management and the team with the project. The first 3-week time box (sprint) ending with about 30% (!) of all features still in progress, when, of course, they should all have been done and ready for shipment.
Their existing solution to this problem was to lower the expected velocity each sprint, so the next sprint would be on-time. But at the end of next sprint, the same problem occurred, so the velocity was going down sprint after sprint. The sprint planning meetings weren’t very pleasant, as the failed commitment hang heavily on the team and there was still the pressure of the rest of the organisation for the team to keep up their tempo. This pressure from both sides was crushing morale.
The way this team reacted to pressure was to work harder. Most people would have 2 or 3 tasks in progress at the same time. When a developer would finish a task, the testers were too busy testing something else, so they could give the developer direct feedback. When the tester found an issue with a new feature, the developers were already working on something else, so the tester had to wait. Simply put, there was too much focus on working long and hard, not on cooperation and the stuff that actually matters: features.
I’m believe most dysfunctional behaviour comes from the system people are in, so I first addressed the biggest struggle of this team: pressure & predictability. Most Scrum masters challenge the team to reach the same (or higher) velocity each sprint. This pressure should give a team focus to perform at its best. However, it can also go haywire if the team doesn’t deliver. No focus, no pride, no happy customer. The effect on this team was that retrospectives were dismal and planning meetings were a huge burden. The teams’ productivity dropped in the days after the sprint, finding new courage to start the next one. Because they had an ineffective work-process, the only outcome of each sprint was to lower the expected velocity, to make sure we would be predictable. Estimation and predictability are only a means to an end and since they were getting in the way of fixing the root cause (and were bringing down the team’s spirit) I opted to cut out the planning sessions and sprint deadlines.
Kanban
The solution was inspired by Corey Ladas’ presentation at Agile2008 about Kanban. One of the tools Corey adds to his project is a limit of ‘work in process’. This was exactly what the team was struggling with (remember the big pile of unfinished tasks?). So the first change we made was to set a limit of 8 tasks on the ‘in progress’ column.
We spent 3 weeks bringing the numbers of open tasks from 21 to 8, without picking up any new work. Of course the team struggled with this new limit. They were used to pick up new work whenever they were blocked somehow, this wasn’t allowed any more. It took some time for the team to really learn that picking up too much work would mean regression to the swamped way of working. Resisting the impulse of increasing WIP is still a discipline, but we now keep each other in check. This gave a stronger team focus on getting stuff to done and recognizing the systemic issues (impediments) with the flow of features.
We used the term Feature Flow to describe the goal of the team: to let features flow through the team without interruptions. Any feature that is in a state of waiting, or is simply taking more than a few days is analysed. It’s moved to done as quickly as possible by scrambling more team members. When we encounter features getting stuck, we don’t pick up more work, we try to find the root-cause of the stickiness and solve that. We increased the quality and capabilities of our build environment a few times for that very reason: to prevent future blockage in our flow of features.
When we introduced the ‘work-in-progress’ limit, we also temporarily stopped doing planning meetings, as our first target was getting the w.i.p. down to 8. The interesting side effect was, that we were working for a few weeks without the need for a planning session. So we stopped the fixed-date planning session and replaced it with an ad-hoc planning session whenever the ‘sprint-backlog’ was drying up. From our coarsely estimated product backlog our product owner introduced a couple of days worth of features each planning session. The great thing was that the priorities could change at the last moment, as long as the team hadn’t started working on a feature. As the Sprint planning meetings were always quite strenuous, the just-in-time one-hour planning sessions kept the teams energy at a constant.
This simple Kanban process worked pretty well and our velocity increased back to a decent level. In my next blog I’ll explain some extra improvements we’ve made, how we got the testers and developers to stay in sync and why we’ve introduced some lightweight planning again.