The Huitale Way - Our Value Stream Map

I previously blogged about The Huitale Way and How we release our product every day. The comments on those encouraged me to share our simplified value stream map with the community. My motivation? 1) get feedback in order to improve and 2) give you some ideas. Here it goes:


The stated cycle times (in green) are averages that we measure and keep updated. Orange icons are the buffers in our system to ensure smooth flow and to have independent cadences for business to figure out WHAT we should build and development to BUILD it. Please keep in mind that all our developers are part timers (we do agile and lean consulting besides the development).

MMF stands for a Minimum Marketable Feature that is the smallest possible set of functionality that, by itself, has value in the marketplace. Read more about MMFs from Karl's blog.

DWT stands for Disneyland Wait Time. It is the expected wait time to get full backlog (7 MMF s) DONE, which is good information for our Product Owner.

Discovering themes

Our product development has several inputs:

• we try to meet users (Finnish) in a brainstorming session every month in our office
• we have done feature voting, surveys and get-together with our community
  
• we try to engage discussions with our users via Facebook group, monthly newsletter (Finnish) and Twitter
  
• we are lucky enough to get feedback from our users via email
  
• we dig into our metrics and business reports (AARRR etc.) to figure our what works (we also look for features that are just waste)
  
• we look into competition and new partnerships
  
• we try to come up with new bright ideas for our product
  

I think we are still learning and improving our ways to do customer development... Anyway, from these inputs we formulate common themes. Once we have the themes formulated we select up to three themes (WIP limit 3) that we should work on next. The selection is based on what direction we want to take as a company. Naturally we can come back to these themes at any given time to steer the product development according our company objectives - in the end of the day product development exists for the business :o)

Figuring out the Minimum Marketable Features (MMFs)

Once the themes are selected, we work on those until we have MMFs to serve the theme in best possible way. We argue the business value of each MMF and figure out the T-shirt size of each MMF (have been thinking of using Story Maps, Kano model etc. here. So far it has been just list of MMFs each having relative value that is based on our business value model, this is definitely an area that we sould also improve) and finally our Product owner chooses up to seven items to "product backlog" (WIP limit 7), which is actually just queue of NOT-STARTED MMFs, not necessarily in prioritized order as real product backlog would be. Why you might ask.. because developers cannot pull items from there as they are not READY yet.

From NOT-STARTED to DONE aka when are we READY and when are we DONE?

Product owner prioritizes the MMFs and starts working together with the team to get top items READY.

So what's our definition for READY?

• No immediate blocker for developing the MMF
• If MMF has impact on language content the content is available. It might not be final.
• If MMF has impact on look & feel the content is available (GUI layouts, graphics..). It might not be final.
• If MMF has impact on emails sent to the users the email templates are available. They might not be final.
  
• If MMF has impact on reports the expected changes are communicated.
• If MMF has impact on third party services/integrations the expected changes are listed. List might (and usually is not) final.

Once the MMF is ready it can be pulled to development. We have WIP limit of 2 for development items in order to keep the cycle time as short as possible. Currently our average development time for a MMF is 6 days.

What does it mean that MMF is DONE according our definition of DONE?

• MMF can be released
• code has unit tests and automated acceptance tests that execute successfully
• code passes tests in CI environment
• code is refactored and the design is simple
  
• code passes automated QA checks (checkstyle, pmd/cpd & whatnot)
• new feature is documented (if applicable, sometimes for third parties)
• peer review is done (if applicable, sometimes for critical paths)

What if there is a bug? We stop the line (no MMF moves from a column to another column) and we work on the bug instead until it is DONE. We tried of having separate swimlane for bugs/ ad-hoc tasks, but then we noticed that we do not really need it.

Our current Kanban board

The bright blue boxes (SMART goals etc.) are kind of rules that we have for items that belong to a column.

You might be wondering how we divide the labor between "biz and tech". The following illustration demonstrates our Problem and Solution "teams":

They are heavily overlapping due that we are doing tons of collaboration in each process step.

Have an idea to share? Please also comment for suggesting a topic for next post - I was thinking of showing what exactly is our MMF (internals) or maybe how we work on GUI as it seems to be hot topic in agile community right now.