Should I start with scrum, or kanban?

or, Should I transition from scrum to kanban?

Tellurian Post Apocalypse Roleplay
Adventure lies EVERYWHERE! Image by Daniel Voyager

We’ve been doing scrum at Affiliate Window for a couple of years now. We go through the inspect and adapt cycle regularly and we’ve made few, if any, changes to our process, only our engineering practices. Recently, however, we’ve been working on a couple of projects which have required some groundwork and lots of backend work. This kind of work doesn’t really lend itself to the ideal of having something to show the stakeholders at the end of every iteration. We still have the review, describe what we’ve done and then take a look at the backlog with the stakeholders to decide what the priorities are for the next iteration.

This has raised a question from one of the teams about moving over to kanban and it got me thinking about what organisations can do to start on an agile journey, should they start with scrum, or kanban? What about established teams? Can they transition from scrum to kanban, or vice versa? Why should they? Should they even do it?

Now, there’s no reason why you can’t continue doing scrum (which is what we’ve decided to do), even with backend heavy work. Afterall, it’s simply a framework designed to offer constraints in order to create fast feedback (amongst other benefits), but kanban is attractive in that it allows you to decide when you demo/review and so gives you the benefit of time in order to actually have something tangible to show the stakeholders. Kanban is also attractive for those coming to agile afresh. It allows you to start integrating some agile practices and get a view of your issues (in order to solve them) without changing your heirarchy or existing process.

For Kanban to really work, you need to make sure you’re setting up a pull system that describes your entire process, from inception to delivery – not just a column based todo board (which, unfortunately, you see a lot described as ‘kanban’). To be able to do kanban well and retain the holistic view of your work required by the product team to make educated guesses on delivery and suchlike, the team needs to be mature enough to do kanban well. This means; mapping out the different states in your system, working out WIP limits and, importantly, deriving cycle time (how long it takes an item on the board to get from left to right) in order to estimate delivery/scope/cost etc. Herein lies the rub (I’ve always wanted to put that in a blogpost!).

If you’re not able to use scrum to help you deliver backend-heavy, large work items, then it’s unlikely that kanban can help either. The constraints of scrum help you stay on target and be accountable for what you have or haven’t done and make tweaks and adjustments to perform better in the coming iterations. Once you’ve nailed scrum and you have a product backlog with well defined stories, which are easily estimatable, then you’re ready to mature to a really valuable, efficient and data-driven kanban implementation. Eventually, when you’re able to size your stories all the same, you can do away with estimating as your cycle time will remain constant. Allowing you to set regular reviews and inspect/adapt cycles. You’re one step closer to programmer anarchy!

So, should you start with scrum, or kanban? Kanban allows you to start your agile journey without upsetting the status quo; you don’t change any names, or add/remove roles. You simply illustrate your process on a big visible board and become accountable, as a team and a company for the work you do. You can implement any agile practise you like (standups, backlogs, user stories, etc) and see how they work for you without rocking the boat. Scrum, on the other hand, requires a reboot and an installation of a new process, one with constraints *built in*, but the benefits are numerous and valuable right off the bat.

Should you start with scrum, or kanban? The answer, I think, is ‘it depends’. If your organisation, including those at the top are comfortable with scrapping your current process and starting something new, even with it’s inevitable lead time, then go for it. Use scrum and the constraints will help you become agile. If your organisation is reticent to start, or you have buy-in from teams, but not the business, then start with kanban. It’s lightweight and non-intrusive and will still allow you to raise your impediments and issues (but solving them often requires bold and honest action, beware!).

Should teams transation from scrum to kanban? Probably, but make sure it is for the right reasons and that your team is mature enough to make the most of it, if you’re not sure, then try transitioning via scrum-ban, it’ll help you see the benefits and enable you to get better at the things which make kaban most useful, without changing more than you are comfortable with.

I’d be interested to know how others started their agile journey, or whether many transition from scrum to kanban (or the other way). Drop me a mail, tweet or leave a note in the comments!

Advertisements

3 thoughts on “Should I start with scrum, or kanban?

  1. My team started with Scrum, but looking at where our processes have evolved, we’re pretty close to kanban. We haven’t fully embraced kanban, but I don’t think it would be much of a stretch for us to go there. We already have a continuously groomed and prioritized backlog. Our individual user stories have a notion of “state” similar to a swim lane. We too-frequently have to shuffle a story or two into our out of a sprint to make way for a task that needs to be expedited.

    I’m not well versed in kanban from a management and release planning standpoint. What are some of the highlights between Scrum and kanban if you are not in a continuous deployment mode?

    1. I think it’s all a question of cycle-time. Knowing how long a story takes to get from one side of the board to the other means you can make coarse estimates on delivery dates and dates for other things like reviews or demos. You should still retrospect regularly; either when you’ve completed n number of stories, or on a certain regular day. Kanban compared to scrum? I think it depends on the kind of work you do and the way your teams are structured. If you’ve got fully cross functional teams which can take a story and complete it, I don’t think there’s much in it, other than the flexibility of demoing when there’s something to demo. But if you’ve got specialist teams that are component teams and feature teams for example, kanban (well, a pull-system) allows you to see your system working and make refinements from there.

  2. Hi Mike,

    I have published a few articles on Kanban and Scrum, lately this one. I think your article examines an issue that most companies think about right now, which framework should I follow to manage my projects?

    I would like to republish your post on PM Hut, please either email me or contact me through the “Contact Us” form on the PM Hut website in case you agree with this…

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s