Friday, 12 March 2010


On Thurs 11th March I went to a Skillsmatter talk by Chris Pitts called 'Scrum to Scrumban'. The presentation was based around his experience in moving a dev team away from Scrum and towards a more Kanban style approach. It's actually an evolution I'd been involved with before but it was really interesting to see his take on the process.

(Skillsmatter are excellent at uploading videos you can find
Scrum to Scrumban here.)

There were a few points that really jumped out at me especially as I'm part of a new team that are keen to try more of a lean approach. We've rejigged our wall board which helped make each story go through a pull system but there are still some things that need to be straightened out. Chris suggested a few good ideas and I'm keen to try some to see if it helps our new team settle into 'Scrumban':
  1. Pomodoro planning - Once your work is coming through as part of a pull system there is no need to hold huge planning meetings for upcoming work. When you feel the team needs more stories for the 'Backlog' or 'To do' column hold a 25min planning session with the business to get the next stories onto the board.

  2. What about future Epics? A question I asked! By giving them an initial t-shirt size the business will know if they should be broken down. Any large epics need be broken down but everything else can then be brought up in the Pomodoro planning sessions when the team have run out of stories.

  3. Dealing with too much WIP - Some teams use post-its to stick stories on their wall board but if you're finding too much WIP is going on try switching to cards which can be added to the board with magnets. Want to limit the WIP to say... 5 stories. Make sure you only have 5 magnets! A story can't make it to WIP if there isn't a free magnet. Brilliant.

  4. Dealing with stories blocked by a third party - This is something that seems to happen a lot and it's always difficult to deal with. In such cases Chris suggested that it helps to introduce a new section on the board called a 'Sin bin'. The concept being the issues remain visible to the team and the devs constantly review the stories in the 'Sin bin' to make sure they haven't been unblocked by the third party. This is strictly for stories that are blocked by third parties though, other blocks should remain on the board until the team have resolved them.

  5. Using date stamping (effectively) - My previous attempts at date stamping proved unsuccessful. As a team we tried to stamp each story as soon as it made it to a new column on the board. Unfortunately this wasn't a great approach as devs would often forget and stories would get through unstamped. On the other side of that we had loads of stamped stories and no idea how to use the information it gave us.

    Chris had a fresh take on this concept - ask your product owner to date stamp a story when it's first picked up by a dev and then once again when the story is has been demoed and verified by the product owner. In effect you only have 2 dates, one for the time the story was started and one for the date it was business verified. So what does this give you? Well first of all you can start to work out approximate cycle times for similar sized stories. Perhaps medium stories are going through at a maximum of 3 days. Now the product owner knows that any medium stories can be expected to arrive back at his desk in approx 3 days. Ok not bad but there is also an added benefit here. It pushes the devs to communicate early with the product owner and also forces them to demo the story at the earliest opportunity. All in all everyone wins!

  6. Weekly retrospectives - The process to move towards a more lean approach can be very intense. Even small changes in the wall board or planning sessions can introduce concerns within the team. To assist the evolution towards lean it's a good idea to hold weekly retrospectives. Chris suggests that he found them very helpful as concerns or problems were caught early and resolved without spiralling out of control. Even months into the new process Chris made sure the team held weekly retrospectives just to make sure the team was happy.

  7. Next evolution? Try Kaizen - Although I've got a long way to go before I can call myself a true Kanban disciple I've often wondered what the step after Kanban will look like. This is the first time I've heard of the word Kaizen and the concept appears to be - continuous incremental improvement. From what I can gather it introduces the ability for teams to retrospect and fix on demand without the need to sit down and plan at all. It sounds interesting although one guy at the talk suggested he is using Kaizen and implied that he has added several new columns to the board. Hmmm unconvinced, part of my liking for Kanban is the way it simplifies the wall board and increases clarity of throughput. Then again maybe this guy found this was the best way to implement Kaizen and my experience (once I get there) may be different. Anyway something to think about I'm definitely not writing it off yet!
One final point - towards the end of the talk Chris bought up the subject of headphones. He indicated that developers on the team he helped were asked not to use them and the team found it improved communication dramatically. One pair might be talking about something and then another dev might overhear and say 'Oh you're doing that, I'm glad I heard you mention it, etc'.

At first I wasn't convinced but our team has paired up a lot more recently which kind of forces you to abandon your headphones. I have to agree things are a lot more enjoyable and the team has gelled really well. Although I don't think you can enforce a headphone ban I'd hate to go back to those bad old days when each of us stuck on our headphones and banged out stories with our heads down.


Blogger Bealer said...

Was gonna go to this but had to duck out. We're doing Scrumban, currently do most of those points already. The no headpones suggestion is an interesting one. And one I quite like, although I don't think it would be accepted here, or result in moody/unhappy devs. Nice blog.

15 March 2010 at 15:39  

Post a Comment

Subscribe to Post Comments [Atom]

<< Home