Experience: Moving From Scrum To Kanban – Getting Started

starting_blocks_lrg

Moving From Scrum to Kanban

My last post touched on some of the organisational changes that form the background to the events I’ll describe here, but this series is really about two teams in our department.

The teams

Let’s call the teams One & Two. Both have successfully used Scrum for some time (years in fact). However, other teams in the department have been using Kanban and our teams were curious.Not wanting to miss an opportunity they wanted to hear more about Kanban and to see whether working that way might help them finally fix some problems they’d been having.

I’m the scrum master on a couple of those other teams, so these guys invited me to a workshop to talk about the problems they saw and to share my experiences of Kanban.

The workshops

There were too many of us for a single session so the teams organised separate workshops, each of which followed the same pattern.  We started by talking about what everyone wanted to achieve, wrote a few words to describe the themes that emerged on sticky notes and posted them for everyone to see.  We grouped together similar items to give us a coherent set of topics to cover, then plunged right in with a discussion about what Kanban actually is.

Our workshop backlog

We talked about how people have defined Kanban and Scrum-ban, whether a Kanban team would still have a backlog, how you might track progress, what this might mean for estimation and for planning, and what to do about getting sign-off.

The guys spent some time talking about the problems they felt they were having with their existing process.  The teams were having similar problems to some degree, they were finding it difficult to commit to the right amount of work to fill a sprint and found that stories routinely rolled over into the next one.

Team One had been finding it hard to get the right balance between stories that required front-end and back-end development so their front-end guy wasn’t either bored or swamped (there’s only one UI developer in the team, and not enough work to warrant another).  Team One also felt that they were spending an awful lot of time in pre-planning and planning meetings and not really getting enough value out of them for the hours invested. Team Two felt that they “weren’t really doing Scrum anyway”, and both teams found it difficult not to end the sprint (and start the next one) with a load of work in test.

This is how Team One’s scrum board looked the day we had the workshop:

And here’s an image of Team Two’s board the day of their workshop:

It’s clear from the boards that both teams had a lot going on at once.  Testing tasks formed the bulk of the outstanding work, and it turns out this was a common situation.  Both teams were having difficulty finding work for the developers to do that wasn’t ploughing ahead writing more code (giving the testers even more work to do, and adding to the problem).  The developers were helping with testing, trying to plan new stories, picking up refactoring or other maintenance tasks where they could, but the problem wasn’t going away and everyone felt a little frustrated.

Both teams were really keen to stop pushing too much work onto the testers.  Everyone seemed to agree it was a problem that occurred too often, with the developers working very quickly on stories where testing was lengthy and complex, leaving the testers overwhelmed with work.

From what I’d seen so far, it was clear these were both good teams, the guys worked well together, and they had a strong desire to keep improving.  They were aware that Kanban wouldn’t magically solve all their problems, felt like the Scrum ceremonies they were using were already heading down the path of continuous flow and wanted to make that explicit – to use this period of organisational change to look at the way they’re working and address some of those concerns once and for all.

So what happened next?

Towards the end of the session Team One decided they liked the sound of Kanban enough to give it a shot.  They discussed what Kanban states they might have on their board, how big their team was and what sensible WIP limits might be.  We talked a lot about exit criteria, the team decided to use entry criteria instead to help reinforce the idea of Kanban as a pull rather than a push system.

For the next few months Team Two are working closely with Team One on a shared backlog.  They decided initially to adopt the same layout of board, WIP limits and entry criteria as Team One, agreeing to review things and see whether this was still the right approach after a week or two.

Our next steps at the end of the workshop

There’s a lot of talk about Kanban in our department at the moment but interestingly, neither team was sold on Kanban as the next big thing and they were very aware they would need to be “more rigorous than we have before” if the changes they’re making are to be successful.  They knew they would need to think about the level of ceremony they’d adopt carefully.

Next up we’ll look at the first few days where the teams started using their new boards and had their first Kanban-style standups.  In the meantime though, I’d love to hear more about your experiences.  Do the problems I described sound familiar?  What are you doing to overcome them?  Is Kanban your impediment-busting weapon of choice or are you trying a different approach?

More on moving from Scrum to Kanban:

Kanban Kickstart Example from those nice folks at Crisp

Do you feel like you’re “not really doing Scrum”?  This checklist is one way to start the discussion.

Kanban 101

Corey Ladas’ Scrumban (Amazon)

I used Balsamiq to represent the team boards in this post

About the Author

Karen has 11 years commercial experience in the software development industry, specialising in project management, team leadership and analysis. She provides consultancy on agile and lean practices including SCRUM and Kanban, on project delivery, and on stakeholder and customer relationship management at all levels. She’s particularly interested in building and coaching cross-functional teams, and in what it takes to get people collaborating across the whole organisation, to the point that they’re excited to come to work, and consistently producing outstanding results.

4 Responses

  1. bcowgillft Mar 22, 2012 - Reply

    We saw the same symptoms trying to get a distributed scrum team to finally release a project live and have it stay there. We switched to kanban for visualisation and put developers ended up helping the testers when they got blocked. Developers also took more care to ensure the code worked when released to the next testing environment so that the testers wouldn’t be blocked.

  2. Dan Mason Apr 26, 2012 - Reply

    Hi Karen,

    Thanks for the post. The problems sound absolutely familiar! I think there are two themes in particular that recur throughout the industry: 1 – poor upstream regulation of work flowing into the team, and 2 – bottlenecks in testing.

    These issues are persistent because they require behavior change that is difficult to effect. I think Kanban can help IN THEORY because it tends to make the capacity of the team more clear, and limiting WIP forces constant upstream prioritization and sizing. Kanban also promotes swarming wherever there is a bottleneck, thus smoothing out the workflow. Again, in theory.

    The other thing that might help your test problem is TDD or ATDD, where a lot of the up-front test work is done in a dev/test team approach rather than putting the entire burden on the QA guys. Are you using some kind of TDD approach?

    Dan

  3. Thomas Schranz Apr 26, 2012 - Reply

    Hey Karen,

    thanks for sharing real world experiences with all of us.

    Personally I see the main benefits of Kanban during standup meetings/tea times. Just having a visual representation of what is going on and talking about it extremely improved the quality of the meetings.

    There is a great tutorial about standups on Martin Fowler’s website:
    http://martinfowler.com/articles/itsNotJustStandingUp.html

    Another thing that really helps a lot are the Work In Progress limits you mentioned. It helps to decrease busywork and increase focus on the most important things at the time.

    Also we found that just writing down the reason ‘WHY’ you expect the change to be beneficial makes it easier to re-prioritize and provides a good context for trade-offs.

    cheers,
    Thomas

  4. Karen Rodgers Apr 27, 2012 - Reply

    Thanks for your comments, guys. It’s great to get some feedback and hear what other people are doing.

    Dan – Yes, pretty much all the teams in the department are TTD-ing to some extent . We can always do better though. To now we haven’t had as much focus on ATDD as we would like but that’s starting to change. Mostly though, we need to stop going after the exciting stuff all the time and make sure we complete the work we have in progress (“dev done” != “really done”).

    Thomas – Great tips, thanks – we too found that visual representation made a huge difference, agree with you about WIP limits and “Why” too. More on this in the later posts :)

    Karen

Leave a Reply