Liberation through Kanban

[Stephen Murphy]

It is just over a year since my team began its transition away from Scrum using Kanban. It has seen many rewards and in my opinion it has been an unheralded success.
Seeing the successes and gains that my department has had in this transition, I frequently question why it is still a minority of software teams that even attempt this transition.
Obviously a lot of Scrum teams are getting a lot of value and producing a lot of value at high quality, so it deserved a closer look.

The first element we tried to change was the removal of the sprint planning meetings. This was often quite painful for us as first of all we had to rush to prepare enough stories to at least fill our sprint, and second of all we would spend quite a lot of time deliberating exactly what had to be built and then trying to debate how many story points a card should be.
After over a year of these planning meetings, there was a growing feeling in the team that there was very little value in these estimates, as we attempted to match them against a velocity that is also set against estimates. We felt it was flawed scenario that was of no benefit - it didn't help us get more done and it didn't help us understand how close we were towards completing our epics, as these epics were too big to have any sense of accuracy.

Furthermore, by having variable sized stories we were able to mask the immaturity in our story refinement.
After a number of weeks into our transition away from this planning session, I noticed that we missed something from our Scrum days - there was more confusion around what the team were supposed to build.

The planning meetings were creating a by-product of valuable discussion about the teams work.
In the wider group we had started to move to bring in acceptance test driven development, with a huge emphasis placed on a discussion that should take place for story.*
Using specification by example we also gave extra clarity on what was the changing behaviour. This encouraged collaboration with the business at a feature level for the sake of the feature and not for the sake of a plan. Furthermore this healthy Collaborative discussion helped increase questioning of WHY and allow value to be scrutinised. We ended up with a far more effective story to allow us deliver business value.

This breakthrough became a huge lesson for me. I took two key points from it.

1. We could always define our own way to work through problems, without resorting to a defined process in order to solve our problems
2. By removing a set of rules, it empowered the team to be more creative in finding solutions.

Work through problems without defined process
Another example of where the team lost from abandoning scrum was through the loss of a sprint goal. I always liked this idea in Scrum. We would set the goal and it helped the team to focus on a milestone for the sprint. By going completely scattergun with the set of live priorities for the team it meant that there were times when team members were silos each working on unrelated work items.
Was there another way to maintain this? Well, one of my colleagues on another team set out goals for his team. We defined Business driven goals and to deliver these goals we defined stories that released the value of these goals. and would attempt to limit the team to 2 rolling concurrent goals at a time. It was a simple yet elegant solution which gave us back the benefit of scrum goals without needing to enforce the iteration.

No rules = more creativity towards solutions
After investigating the second point I came across Douglas McGregor's Theory X and Theory Y. Theory X is based on the idea that workers do not want to work and need to be controlled. Managers that subscribe to this belief adopt a command and control style. Theory Y assumes that workers are self motivated and gladly take on responsibility. My experience is that in knowledge based work, the participants are overwhelmingly Theory Y based.
It is my opinion that by holding the prescriptive set of rules regarding planning, estimation, artificial sprint deadlines, the enforced sprint review and sprint retrospective, it stifles the stifles theory Y based worker. Our planning meetings were so painful, the result was the plan - not about creating value for the company. Our sprint was about standing over our plan and an artificial deadline emerged as we tried to justify our commitment.

The ominous looming of a deadline reduces options and causes people to panic - this effects quality

By freeing ourselves from rules and by visualising where we had bottlenecks and blockers, the energy in the department became focused towards creating flow for the work and eliminating waste.

Conclusion

I understand that people can be quite partisan towards the way they work. People are emotionally attached to the way they work because they have invested so much. I don't believe this is the case here. I am a Certified scrum master, and received a lot of Scrum training and read a number of books about Scrum. When my team practiced Scrum it was far from being a flawless process.
Some people will argue that we weren't doing Scrum right so no wonder we had problems. But this is the crux of my problem with it - so much effort goes to doing scrum instead of channelling that focus to building better software, faster.
For my team, using Kanban to liberate us from a prescribed process and visualising the way we worked allowed us to have this focus.
I think there is a misconception that Kanban is a process and directly comparable to scrum. I don't see it like that. I see Kanban as a set of practices which helps teams define their own way to work with absolute freedom. It wraps around your way of working and helps you refine it.

Certainly the results were powerful for my department.

In February 2013 A single card averaged 29 days to get acceptance from the Client

By August 2013 that average dropped to 5 days.

In the same period the average days days to production went from 53 days to 19 days

(These measurements were made on a legacy application, beginning a few months after already starting to use Kanban, and stop using Scrum. Some of these improvements had already started to manifest in lower cycle times. We stopped measuring these particular values after September 2013 as we had stopped getting value from them, but on newer applications I have seen regular stories drop to prod in one or two days.)

Teams will use what works for them, and rightly so as change for the sake of it is not good. I completely understand successful Scrum teams not attempting this approach, however I think I have shown that there is a lot to gain by making this transition, and would urge them to experiment.
With Kanban the ethos of continuing to strive to improve is one of its most valuable attributes. Liberating workers from a set of rules regardless of how light they might appear can have a big impact.

*Gojko Adzic describes a story as a promise for a conversation - a beautiful way to open up potential for every desired deliverable.