Scrum to Scurmban Experience Report - Chris Pitts

My notes from Confessions of a Kanban Virgin - Chris Pitts - Thirsty Bear Software - principle consultant and M.D.

Chris was coaching a team that was using scrum towards a leaner approach using Kanban.  At the time Chris had no experience with Kanban and learned to see the potential of the team as they tried it out.

When Chris arrived, something was not quite working right with the teams Scrum approach and kanban seemed a more relevant approach. Here is what Chris did to try support the team in their efforts.

How things were working

Team implemented scrum using the usual practices and routine:

• product backlog, weekly sprint, iteration weekly so that issues could be identified quickly, daily stand-ups, potentially shippable product increments

Three cooperating teams were working on the same code base, all with different delivery schedules

Weekly

• stakeholder demo
• retrospective
• planning game

The scrum board

Identified technical debt cards, bugs, 3rd party bug fixes (from external teams), avatars, business stories

Story being worked on - Developer takes card away - leaving avatar in its place

Done is ready for demo

Avatars - not allowed to generate your own avatar

Something was not quite right

The team was not delivering the full velocity each week, as time went by the total points and planned points diverged wider. For all there efforts, it seemed unlikely to get a constant velocity

The team had a massive dependency on a third party product, which had a lot of bugs.  There was a great deal of  legacy code. 

Developers were not taking responsibility on what they promised (something that is all to common for developers new to agile, usually because they have been abused in the past)

Discussed Kanban with colleague

First question: What will the kanban board look like, what are the phases going to be?

To do, In Dev, QA, Done

The team was very curious about limiting the amount of work in the first few phases

Team

6 developers, 1 qa

Interested in limited pairing

Need to find the goldilocks value for the work in progress for each phase

Option 1: 7 stories in flight

No room to manoeuvre and the QA role would be swamped with work, causing a big constraint in getting the work done.

Option 2: 4 stories in flight

Created a work in progress limit (WIP limit) of 4 across the dev and qa phases.

Pairing helped the team minimise rework and reduced the number of bugs being introduced into the software.

This gave more scope for the QA to do exploritory testing, doing random things to the software that no one else is thinking of.

Pairing was introduced gently and now all team is happy to pair as they dont have to pair all the time

The initial Kanban board

3 story limite in the todo list, a rough estimate to keep everyone busy should they all finish at once.

The todo wip is added to by the product owner and the team will raise a request to priorities with the product owner if the todo become empty / has only 1 story left

Time boxing / pomederio

Work is organised into time boxes of 25 mins of work and 5 mins break.  This helps people focus on the task at hand and any other pieces of work can be evaluated every half hour.

At the end of each timebox, the 5 minute break can be used for planning, giving a more on demand approach.  This means that the team focuses on small pieces of work that they can get done, leaving less unfinished work and less task switching.

The team, with the help of the product owner pull work out of the backlog as and when required.

What about epics

Stories that are of a larger size, often termed Epics, are split down as part of the on-deman planning - or discussed earlier and split down, eg t-shirt sizes

Problem: WIP validation

Someone comes in after the weekend and starts a new card without realising they still have work to do on an exiting card.

This was solved by each person having a magnet to represent themselves on the kanban board.  As each person has only one magnet, they can put it on only one piece of work at a time.

Problem: Blocked cards

The team had an immense dependency on 3rd party layer, causing them a lot of grief (a valid reason to not be completely scrum if the team is not in charge of the stack)

A common kanban approach is to say that a blocked card stays where they are until they are unblocked.  This helps highlight where issues are and helps with root cause analysis.

If something genuinely blocked and the team have no ability to fix it, then the blocked card goes in the sin bin.  The sin bin must be kept visible so blocked cards are not forgotten.  The sin bin has been used by product manager to escalate issues with third party software company

Cycle time - story time from todo to done phase

The team had a cycle time (iteration) of 5 days.  They wanted to keep physical cards, but wanted stats too.  By using a date stamp on cards the progress could be tracked and the product owner had control of stamp so real progress was tracked.

It really helped the team really understand what the product owner wanted as they had to demo to ba / product owner.  The stamp was a great visual sign off of the card.

Side effects

the weekly stakeolder demos retained as the demos showed progress and highlighted they were well ahead of perceived progress.

The weekly retrospectives retained.  The team did have problems to start with and wanted to see if kanban was actually helping.  Because the people in the team were now talking about all aspects of the work they became more open an honest and more amenable to code changes and design improvements.  The team and product owner conversations also happened naturally and frequently

There was initial confusion over how to explain to external Gant chart fetishists what was going on.  The team were still dealing with people who thought a Gant chart was right as it was written before the the project and must be right all the way through.

One final step that the team was encouraged to do

A weekly retrospective could have been turned into kaizen, encouraging the team to have a mini retrospective and fix problems as they happen.  A Kaizen approach would be the next logical step.

Where are they now

The team no longer make rapid changes, they allow things to bed in before evaluating. Unfortunately external pressures forced the team back into scrum velocity and much of the good progress was undone.

Main take away is the WIP limits

Even thought the team have reverted to a scrum approach, they still stick to 4 cards at a time and maintain the pairing approach.

No story points

As the story cards are broken down to a more uniform size, with a card having a 5 day cycle then there is no need for story points.  All the cards would have about the same point.s

If a card is not going to be finished on time then the team should recognise that and deal with it appropriately

The full session of this event was recorded by SkillsMatter and available exclusively via http://skillsmatter.com website.

Thank you.
@jr0cket

---

This work is licensed under a Creative Commons Attribution 4.0 ShareAlike License, including custom images & stylesheets. Permissions beyond the scope of this license may be available at @jr0cket