Over the past year I have noticed an increase in the number of candidate profiles that register Kanban (not just Scrum) as an approach their project team has adopted within an Agile environment. From a recruitment perspective, it’s important to keep abreast of such intelligence so I decided to investigate.
I approached Victoria Morgan-Smith who works at the Financial Times as a Programme Lead and Scrum Master. The Financial Times they have been delivering projects within an agile framework for 10 years. After 4 years of delivering projects with Scrum, she has recently started to use Kanban, so I wanted to use understand how this has worked out. Victoria is well placed to give her insightful views on the popular “Scrum vs. Kanban” topic.
1. Are there any official certifications for Kanban?
There aren’t any official certifications that I know of but there are several external training courses on offer. Real world experience is always the most meaningful qualification anyway.
2. Why doesn’t the Financial Times adopt the Scrum practice throughout all the current work streams?
We recognise that not every team is the same. We aim to be the best at what we do, to deliver the right thing in the right way, and whatever process can help a specific team to do this – that's the right process for them.
3. Why did you decide to run Kanban in your work stream?
I'm always looking for ways to improve the team's working practices. Continuous improvement lies right at the heart of Kanban, so it made sense to explore it.
I had been using a sort of Scrum-ban with previous teams, by limiting Work In Progress, but what motivated my new team to fully adopt Kanban was the pull mechanism - it's all about getting a work item all the way through to delivery, so if anything blocks or impedes the progress of that work item, the team will all focus on removing it. That's been great for team-cohesion.
4. What have you found to be the main differences of both agile approaches?
Scrum has its process pretty well defined. It's easy to adopt and to follow on a day to day basis. It gives you nice regular review points, with lots of mini-goals to keep you motivated. However, it can become a bit constrained, and you can find that the work is re-shaped to fit the process, rather than the other way around. It can also make you a bit lazy, and some teams will fail to address problems with the way they work because they can just blame the process.
In Kanban, you define your own process. This means that the team “own” that definition and feel more motivated to follow it, and therefore take more responsibility for addressing any problems it highlights. It works because it really visualises the whole story – you see the whole pipeline of your work, from idea, through to release, with any external dependencies on the way, so bottlenecks and blockers that might otherwise have been hidden come to light. You can (and should) still put regular review points and milestones in place...
5. Why did you decide to use Kanban?
First off, I'd read a lot of case studies and background (e.g. David Anderson, Henrik Kniberg at Crisp and any number of other blogs on the subject). Then a couple of the teams at the Financial Times adopted Kanban so I looked at what they were doing, asked the Scrum Masters why they used it, and the teams what they got out of it other than it being “cool”, and generally it sounded positive. So I put it to the team and we decided it was worth a go.
6. What were your preconceptions of Kanban?
Generally, I was prepared for a lot more work in implementing it. Scrum is easy, as it's all laid out for you. In Kanban you need to apply your own structure, your own queues, and if you don't get it right, then you can just end up with chaos.
7. It has now been 4 weeks since you established the Kanban approach. How is the team coping?
So far so good. The team are not only new to Kanban, but also new to the project, so there's a lot going on right now. They are feeling their way, getting to know each other, getting to understand the work and coming to “feel the flow” of getting it delivered.
They have so far adapted their process 3 times, but each change has been small, so we're taking incremental steps towards getting the right policies, and the right level of ceremony.
They are discovering that the work is complex, so working with the Product Owner to break it down into smaller, well understood pieces, and working closely together is the best way to get through it.
Most importantly though, they “get it”. Work is being delivered, at a high level of quality, and our PO is fully supportive of their journey.
8. What do you miss most about the Scrum approach?
The mini mile-stones & time boxed iterations. The planning out of work and commitment that comes with it is less obvious in Kanban. People often feel galvanised to meet deadlines but this is more difficult to get when working in a continuous flow.
9. Will you continue to set up teams that could benefit from Kanban in the future?
Yes. I still believe in the principles of focusing on an actual deliverable rather than talking about general “busy-ness”. And it’s paid dividends in visualising issues and dealing with them straight away.
10. Do you have a clear favourite now? Scrum or Kanban?
The jury is out as we’ve not been using Kanban enough to see if it stands the test of time. So far, the team are enjoying it and it seems to be working but I would always consider both approaches.
One thing that can be an issue is that Kanban relies on people (eg the Product Owner) being available more of the time to allow for flexibility in planning and feedback. You can work around this though.
At the very least, if I were to implement Scrum again, there are lots I've learnt from using Kanban that I would take back into that approach.
11. What’s worked really well and what hasn’t?
Consciously devising a process to suit what fits means the team respects it and there is an enthusiasm to stick to policies in place e.g. entry criteria, WIP limits. Scrum can feel more like a management thing where you have to commit to something arbitrary.
12. Can you share some hard-earned lessons?
The user stories must be small otherwise they just stick around too long and people get lost in the complexity. The point is to get work to flow through the system but this doesn’t work if the stories are too big.
You have to stick to your own limits. It's tempting to be lazy and slip back into Scrum mode and ignore WIP limits to get past a sticky problem, but you just need to force yourselves – there's a reason you set those limits!
The team have to be prepared for the time they will need to put into defining and revising the process. This includes being given the time by an appreciative Product Owner and Scrum Master.
You might also like
Great intro to Kanban - http://www.kanban101.com/
Henrik Kniberg - http://www.slideshare.net/RossC0/kanban-vs-scrum
Crisp - http://www.crisp.se/kanban
David Anderson's Kanban book - http://www.amazon.co.uk/Kanban-David-J-Anderson/dp/0984521402/ref=sr_1_1?s=books&ie=UTF8&qid=1331124632&sr=1-1
