Thursday 26 July 2012

The Kanban Coffee Shop

The principles of a Kanban, as defined in David Anderson’s Kanban, are:
  • Visualise work
  • Limit work in process
  • Measure and manage flow
  • Make process policies explicit
  • Use models to recognise improvement opportunities

Kanban barristas


A couple of weeks ago, our team found out how similar a Kanban software team can be to a coffee shop. The guys from Agility in Mind did a great exercise with us where we were suddenly morphed from a development team into a group of (comically terrible) barristas.
 
They set up stations around the room for:
  • Customer orders
  • Coffee shots
  • Milk/foam
With a few constraints in place, we were then set to work on creating a flow for customer orders. Feedback from our coaches was that it was an incredibly painful thing to watch.  

In the first round, orders came in very fast, which rapidly overwhelmed the coffee shot station, creating a backlog. By the time the orders got to the "customer", 75% of them were wrong!

Rather than listening to the customer (who was literally standing in the corner calling out "Hellllooo??"), we instead gathered together to see how we could improve.

We added Quality Assurance as the final step in the process, and we flowed a bit more smoothly the second time around. Again, we ignored the customer's entreaties.

Finally, we gathered together and proposed a radical change: rather than handing the coffee cup from station to station, we would travel with the cup until it was complete. With this change, people went from specialists to very confused generalists, which resulted in the longest round of drinks with very poor quality for the customer. Epic fail!

Comparison of barrista work to software development


In the end, we learned a bit more about creating an efficient flow, as well as the major lesson of listening to our customer.

Ash Moran at Patchspace explains it well...

What happens from the coffee shop’s point of view is this:
  • You, the customer, arrive at the customer queue, and you do so randomly (at this point, you wait)
  • A barista takes your order, a list of random drinks – that is a batch of work to be done, of variable size, complexity and value
  • Your order goes in a queue (at this point, not only are you waiting, but so are the drinks)
  • One or more baristas make your drinks, that is, the batch of work gets processed (you’re still waiting)
  • A barista hands you your order, that is, the completed batch of work
Before we go on, just reflect how similar this is to software:
  • The client / business turns up with a “new idea”
  • The client describes some work they want you to do (which will be of variable size, complexity and value)
  • You put the request in your backlog
  • At some point, one or more developers become free and turn the request into working code (which will take a variable amount of time)
  • You deploy the software/deliver the code, etc
So if you can accept that an index card describing the new feature “View product listings by category” is more or less the same as an empty coffee cup waiting for a drink, the two processes become coherent.

What are your experiences with a shift from scrum to Kanban? Any ideas on how to create a more efficient flow of work?

Friday 20 July 2012

Improvement Experiments Kanban

The team are very keen to always improve their agile practices, with many suggestions coming out of each sprint retrospective. Some of these get implemented, stick, and become part of the new way of doing things. Others fall by the wayside and are forgotten.

Improvements can be things like:
  • Implement pre-dev checks to explain the work that will be done
  • Rotate the scrum master role around the team to keep it fresh and ensure everyone is involved
  • Create a Readiness Board to ensure stories are prepared enough to go into a sprint


We had a few excellent sessions with Matt Wynne and his colleague Rob last week, where they helped us to focus our improvements.





The Kanban board is courtesy of Agility in Mind, and was re-purposed to become an Improvement Experiments board for the team.

The idea behind the Improvements Experiments is that, rather than just a collection of "good things we should be doing", some structure gets added to the process improvement.

Here's the process in a nutshell from Matt & co:



We've already started tracking items on the board, and so far have proven 3 experiments. So it seems that we're onto something here!

Have you had any success with methods of tracking the improvements your Agile team suggests during the sprint retrospective? Please comment and share your experience.

Tuesday 10 July 2012

Impediment Removal Team: Scrum on an Enterprise scale


With a view towards improving our agile implementation on an enterprise level, I recently formed an Impediment Removal team within my department, with the goal of resolving any blockers which can’t otherwise be removed by our teams on their own. The scope is any impediment which the scrum master or scrum-of-scrums has tried to resolve on their own, but is getting no traction. 

The group is the next layer up from the scrum-of-scrums held in each product team and acts as a funnel for issues into and out of the senior management team. 

Our department is made up of 8 product areas which can easily operate in silos if we don't take extra care to communicate and find commonalities in our practices.


The idea here is to resolve any impediments caused by intra-team communications or process difficulties, escalate any impediments we’re unable to resolve, and share any systemic/org-wide impediments with our colleagues in other parts of the organisation, so that we can find a common solution. The group gives scrum masters and project managers a point of escalation in the delivery chain and (hopefully) prevents long moaning sessions where the same topics keep coming up but never gain ownership or traction.


Ground Rules for an Impediment Removal Team

  • Keep it short, sharp, and focused, like a team standup.
  • A fortnightly meeting, time-boxed to 30 min. if possible.
  • Each representative brings the top 3 impediments – they should be showstoppers and apply to more than one team
  • Actions to be agreed, each item has an owner
  • Long discussions to be held offline, items time-boxed to 4 minutes each
  • An initial kick-off session to set the context, agree a communications plan
  • Each fortnight, the prioritised list is published to the department


FURTHER READING
http://agileconsortium.blogspot.co.uk/2011/01/impediments-management-2.html
http://agileconsortium.blogspot.co.uk/2011/10/scrum-team-in-waterfall-land-what-to-do.html
http://agilecoachingforteams.blogspot.co.uk/2012/03/impediment-removal-team-part-i.html