The teams
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; we’ll call them 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?
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.
Corey Ladas’ Scrumban (Amazon)
I used Balsamiq to represent the team boards in this post
itkanban 