Toyota QC Circle Example

Imagine having this on A3.

I like it and I do not see too many companies doing this even with their fancy "improvement processes".

Huitale Kanban

First I want to thank Henrik for publishing ScrumVsKanban as it helps me to describe our way of writing software and getting stuff done. Hopefully we can co-operate at some point to make this all a bit clearer to the community as there obviously is some interest.

I need to stress that I am no way saying that Scrum is bad or you should not do it; I have seen Scrum working in various teams already but found Kanban more appropriate for Huitale internal development :)

We stopped sprinting and doing Scrum after 26 sprints in Huitale. Here is some of the "whys":

• We felt that splitting stories is artificial
  
• Estimating sucks, even though it is 20% correct
• What we need iterations for?
• We can release every day, the process needs to serve us, not vice a versa
• What if we have subcontractors and things take just more than 2 weeks?*
• Stories are a bit weak, all the teams that I have worked with have trouble with stories (sure you can do something else in Scrum aswell..)
  
• Splitting is about focusing but it is also about loosing some information (see pitfall)

Iterations

• YES, we need them for reflective improvement (do we need to wait?)
  
• NO, we do not need them for demo (why wait?)
• NO, we do not need them to split stories (leads to problems)

So we do Kanban instead. By Henrik's description we are "Kanban team #3".

“We trigger a planning meeting whenever we start running out of stuff to do. We trigger a release whenever there is a MMF (minimum marketable feature set) ready for release. We trigger a spontaneous quality circle whenever we bump into the same problem the second time. We also do a more in-depth retrospective every fourth week.”

In practice it means that

• No sprints nor iterations
• No sprint planning
• No complexity estimation (no story points)
• Flow is more important than iterations

We value more getting a Minimum Marketable Feature out than having multiple stories that have no meaning (as they are parts of something more meaningful) for the business out

Huitale Way

Here is a picture demonstrating our way.



Some acronyms explained
PBL = Product backlog
NS = Not Started
IP = In Progress

As you see, we take 7 items from the backlog to our Kanban board. Why 7? Because that is the amount of items we can keep in our heads at any given time.

Here is a picture of our actual Kanban board


Red numbers are our queue size limits and as you see we allow two items to be In Progress. We have also defined a way how we cope with bugs, how we track waste etc. but I have left them out for simplicity.

Here is (imaginary) example of a Minimum Marketable Feature (yellow card on the previous Kanban board).


We add data to the MMF as it moves in the board. In addition to the board and the item itself we have so called Engineering Board where we keep all the relevant data per In Progress item.

How do we demo?

We have applied scrum-like demos, but we do demonstration per story. If the story is accepted by the Product Owner it will be deployed to production next day thanks to our capability to release every day.

What metrics we follow?

We gather the following metrics

• Kanban board cycle time (from Not Started to Done per MMF)
  
• Overall cycle time (From Idea to Done)
  
• Number of defects
  
• Waste
  

How do we plan or even roadmap?

Based on our cycle times we get average wait times per MMF (we call it Disneyland Wait Time as it won't be precise) . From there we can tell how long it takes to get stuff done. In order to get something done faster our Product Owner simply repriotizes. All data is naturally empirical and currently our wait time is 3 weeks. So 7 items in Not Started means that 7th item will be done after 21 weeks (7 x 3) if In Progress is empty.

Previously we have also tried some sizing based on t-shirt sizes (S, M, L, XL). Each size has been tracked (cycle time for each size adjusted based on empirical data) and they have been relative (3xS = M, 3xM = L, 3xL = XL). I would recommend new teams to start with sizing and then seeing if it works for them.

How do we retrospect?

I think cadence is good for reflective improvement so we have kept the "iterations" for retrospectives. Naturally the team members are actively improving "on the spot" any practice as there is no reason to wait for the retrospective to take place in order to reflect. However, I feel that we need the pulse for retropectives - it reminds us in case we may forget to do it.


Do not hesitate to contact me (marko.taipale at huitale.com) in case this raised some questions or you have similar experiences to share. You can also drop by our office to see it yourself - we have already had some ;)

Fastest Agile Certificate

Too busy to sit down for 2 days to get certified? No worries, get yours at
http://www.agilecertificationnow.com/

Scandinavian Agile Conference 2009

I am proud to be member of the organizers also this year. Check the status of the conference or go and do a submission at http://confluence.agilefinland.com/display/af/Scandinavian+Agile+Conference+2009

Is business value model overrated?

I often get asked how do we calculate business value for our backlog items. We have a (relative based) way to do it, but more importantly I have been wondering how much estimation is actually needed.

James blogged about "Maximizing Value with Agile.." and came out the following:

1. Work on One Project at a Time
2. Release Early and Often
3. Adapt Your Plans
4. Keep Your Options Open
5. Plan at the Last Responsible Moment

If your company has clear vision where it wants to go ("we want to have more users for our website"), then your prioritization should be pretty easy.

Is your company just missing the focus and hiding it with a complex business value model?

Exposing Huitale Way - take 2

Again we are getting visitors from companies to see how we do agile. This time the guests are from Accenture and Leonidas.

Exposing Huitale Way

Today we're having a group of visitors from Houston Inc. to see how we do agile.

So cool to share some findings with other agilists :)