Liberation through Kanban

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;
First of all we had to rush to prepare at least enough stories to fill our sprint.
Second of all we would spend quite a lot of time deliberating exactly what and how something had to be built in order 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. We attempted to fit our story points into a velocity of Story points, which is calculated based on the number of story points achieved in previous sprints. (a made up number that matched a made up number – seems self fulfilling)
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 goals.

Furthermore, by having variable sized stories we were able to mask the immaturity in our story refinement, and in breaking down the goals we were working on.
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 a separate initiative, we had started to move to bring in acceptance test driven development, with a huge emphasis placed on a discussion of the behavioral change that was being introduced with each 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 initially lost out by abandoning scrum was through the absence 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
A short time after we transitioned away from Scrum, I began to read about 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 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.


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 the measurements, 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. Change for the sake of it is not good. I completely understand successful Scrum teams not attempting this approach, however I believe there should always be a focus on improvement. We have gained  a lot by making this transition, and would urge other teams 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 cracking way to open up potential for every desired deliverable.

3 thoughts on “Liberation through Kanban

  1. Nice post, thanks for sharing. I’m particularly intrigued by: “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.” – I’d counter it with 2 things: creativity thrives on constraints, Scrum’s constraints provide boundaries within which the team can work freely without interference. I never experienced that with Kanban and although I initially thought we were freer we soon lost that freedom. Every org is different though. It sounds like there is some great things happening on your team. I’m really interested to hear how its going in another year or so.

  2. I haven’t used Scrum or Kanban properly, but I am aware of both and I found your experience very interesting, and aligned with what my instincts tell me. I can see the benefit of Scrum for certain kinds of development. In the (Theory Y) product team I work in, we know that our first production release is a year or so away, and so knowing exactly how much we can develop in a two-week period wouldn’t give us much value. My other big worry is that to do sprints we would need to break down what we have now, large (as in multi-month) “developer responsibilities”, into small pieces – I want that to be left to the responsible developer’s discretion, not just for the sake of efficiency or a sense of ownership, but also to avoid implicit premature design.
    I also want to pick up on your point about freedom and creativity. Glass and DeMarco’s Software Creativity 2.0 talks about a study which showed that developers who had no deadline delivered sooner than developers who had chosen their own deadline. I do agree with looking for opportunities to deliver value early, but I think I’m more likely to see these opportunities when I’m in the code (or lying in bed …) than when I’m in a planning meeting.
    We do, however, need something: something to help us to communicate and negotiate expectations with the layers of management above and around us (a mix of people who understand software engineering and people who don’t, and not all of whom know the long history of our team.) Ideally we would arrange things so that we have all the creative freedom that comes with near-anarchy but the rest of the world sees an investment in safe hands and feels confident in our ability to deliver. I’m pretty sure Scrum’s not the answer; Kanban probably isn’t either, but I’m hoping it might help us to get there.

  3. I would say that it’s all about people that you work with and the kind of work/projects that you are doing. I personally find Scrum adding rhythm to our development and a lot of transparency into it. I also think that constraints that Scrum enforces are in fact good and allow you to keep the rhythm.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s