Thursday, October 22, 2009

The Huitale Way - Is it Scrum or is it Kanban?

Last week I was sitting together with Jim Coplien and Karl Scotland in Scan-Agile 2009 "speaker dinner" and talking about various things. One of the topics was the way we do product development in Huitale. Jim thought that our way is "red pill Scrum" but another CST (Petri Heiramo) thought it is not any form of Scrum as it does not have timeboxing. Later on I talked with Karl (both over some beers and in the open space session) and got impression that he would consider this to be Kanban.

I noticed that there was a question in Karl's blog about what was the implementation discussed with Jim hence I thought to share our way.

I would like to know which is it in order to be able to discuss with the community about it. I do not favor Scrum over Kanban nor Kanban over Scrum but I feel both are useful and even complementary tools.

Evolution of our Scrum implementation

We started with "pretty close textbook Scrum" and after 26 sprints we had molded our implementation quite a bit based on the results from internal Kaizen events.

Version 1.0: Release story by story
* Note: Blue box is our Scrum wall. It has columns Not Started, In Progress, Done (todo, IP, Done in the picture). Green arrow is daily standup, red arrow is sprint.

At this stage we did sprint plannings and planned work for two weeks sprints. We had continuous integration and deployment capability so we thought that we would like to release story by story instead wait for the end of the sprint. Demos took place on demand, but plannings and retrospectives were taking place every 2 weeks. Progress was shown with burndowns.

Version 1.1: Introduce explicit Work-in-Progress limit

We dropped sprint backlog and burndowns. We were working one to two backlog items at any given time (this was probably true previously as well, but this time it was explicit), measured cycle time and used that as feedback for planning. We still did sprint plannings and retros every two weeks.

Version 1.2: Planning on demand

We introduced WIP limit also for "Not Started (todo) column". Product owner would prepare planning at any given time when there was less than 7 items in that column. It seems we got "pull system" in place as planning, demos, releases and retrospectives took place on demand and features were pulled from "Not Started to In Progress". Some sizing was put also in place and cycle time for each size was measured. As you can see we did not have any timeboxes any more.

Version 1.3: Ready column and Cadence for retrospectives

We noticed that sometimes the items on In Progress did not progress and they jammed the system. In retrospectives we came up that we need some intermediate stage with rules so that unprepared items would not stop the flow. Ready column was defined with limit of 2 and now that became the "pull signal" for Product owner to start preparing some items from "Not Started" to meet the "Ready" criteria. Interesting that Jeff Sutherland is mentioning that 1% of Scrum teams are having similar "Ready" in his blog (EDIT: link fixed, thanks Anu for noticing that :) ). We also noticed that "on demand" retrospectives could be neglected and decided to set cadence for them.

This is our current implementation of Scrum/Kanban that was discussed in the dinner. Do you think it is Scrum? Do you think it is Kanban? .. or do you think it is both?

Why do I care? I would like to discuss the implementation with the community in order to learn from others and it would help me tremendously if we'd have common terminology :o)


Dave Nicolette said...

A wonderful description of how you have evolved and improved your process through experience. Thanks for sharing!

Unknown said...

I'd say you have followed an example of Corey Ladas' Scrumban approach to evolving Scrum, that is, you employed Kanban WIP limiting as the catalyst of change and evolution.

So what you have now is a process tailored to your unique situation. You started with Scrum and you used Kanban techniques to catalyze that evolution. It's the result that matters most - a process tailored and presumably optimized to your context. How you got there was to use the Scrumban technique. This ought to be repeatable - in other words - others could use the Scrumban approach to evolving textbook Scrum to provide them a tailored and optimized process, unique for their context.

BTW. I do not consider Scrum and Kanban an apples to apples comparison. Scrum is a project management methodology or process. Kanban is an approach to managing change where the WIP limit is used as the source of positive tension that catalyzes evolution of the process.

There is no such thing as Kanban method for software development or project management. There are teams using the Kanban method to evolve a uniquely tailored process optimized for their context.


Jussi Autere said...

I don't think that it's Scrum anymore. It's evolved so far. Then again I don't like to call some process Kanban even when it does have that ingredient. Kanban is just a pull scheduling system and that's only such a small part of a good process. Well Scrum is not a process either, just a framework, but I still think it has a pretty nice cohesive skeleton if it suits your context.

I'd just call this the Huitale process. It has some Scrum and Kanban to it, but in my opinion it is first and foremost a beautiful creation of your own for your own context and needs.

It would be interesting to know how many people you have in this team. Sometimes I get a feeling that explicit WIP limitations are not the best way to go when making software. And that experienced teams self-organize every day to an optimum WIP limit and optimum flow according to the situation at hand.

I understand the value of WIP limits and even the ideal of single piece flow when making car parts on a factory floor organized into workcells. But when it comes to software and all its variation I have some doubts. Even now that we have implemented something Scrumish and Kanbanish in my company, too.

What are your experiences? Maybe I should just study more Corey Ladas stuff or something.

Marko Taipale said...

@all Thanks for your comments.

@Jussi I guess you are working in Finnish company? I could come and pay you a visit in order to talk face-2-face. I am currently visiting (Go-and-Seeing) agile companies and it would be nice to see your implementation & share experiences.

Please contact me (marko dot taipale at huitale dot com) if you feel that would be beneficial.

Ari said...

Marko: Good work explaining how you have evolved! We need more of the same, too many agilists are focused on finding The Best Solution instead of on evolution and kaizen.

Jussi: Could you elaborate a bit on your doubts about WIP limits and single piece flow? What is the "part" we are talking about?

In Huitale's case one part is a marketable feature of their Web portal which, if I recall Marko correctly, takes from few calendar days to couple of weeks to develop. I am not an expert of TPS nor car manufacturing but currently their batch size is two and if you'd reduce that to one they would effectively have single piece flow. There is quite a bit of variation since features come in various sizes and software development has it's surprises, but those are managed by relative estimates and tracking cycle times.

Contexts vary but it seems to me that managing WIP and aiming for single piece flow fit software development quite nicely.

Jussi Autere said...

First, one clarification: I'm not generally opposing the ideal of single piece flow. I'm just wondering if there are certain contexts in software development that are not a good fit for it.

Let's say you have an agile team of 5-7 people. You are happy enough to have great developers and a couple of skilled specialists in your team. Let's say that those specialists are an interaction designer and a data warehouse architect with expertise in reporting cubes, integration tools etc. And maybe some of your developers are business analysts as well, having knowledge on some specific part of the business domain of your product.

Software features/user stories differ in size but there are other things to consider, too. Some features need more UI work, some need intensive work on some other aspect of the system. They are prioritized so that you get maximum business value as soon as possible. When an experienced team self-organizes to solve these challenges things should flow pretty nicely. The team figures out when to work on a single large feature at a time or when to divide the team between several features so that everyone can contribute according to their best abilities.

Why to force a single piece flow on such a team? Sometimes I feel that the answers I get are a bit clumsy attempts to show how software product development has the same problems that manufacturing does. Oh, the horror of having to store and manage an inventory of a couple of extra backlog items specified in detail! :-)

I think that the productivity decrease when replacing a natural team self-organization with a single piece flow is significant in some situations, and it isn't a great morale booster either. So from my point of view the best ideal is to teach teams how to self-organize better instead of always aiming for a single piece flow.

Marko Taipale said...

@Jussi Obviously in your case WIP limits does not seem to make sense. I wonder if you do Scrum either as UI stuff and timeboxes don't go well together based on my experience. We for instance do most the the UI related work as part of "Ready" state for any given feature.

Rgarding WIP limits.. What I feel more important is to visualize the value stream (value stream mapping) and limit WIP (on higher abstraction level) in order to optimize the whole.

I have one excellent customer case about that so lets meet if you are interested to hear about it.

Marko Taipale said...

@Jussi Oh, one more thing.. I (or Ari even) is not saying that "single piece flow" should be a goal as such. The goal is to reduce lead times from "concept" to "cash" :o) If WIP limits are constraining that goal then the limits should be increased/removed.

Our team size is 5 (+ some subcontractors time to time) and we have found the limit of 2 ready items, 2 in progress items, 7 as number of items in backlog as quite optimum limits for getting stuff out. Note that our item is Minimum marketable feature.

I could write a blog entry about our value stream map...

Ari said...

Agreed. :) I don't think single-piece flow should be a goal or something to strive for, it is just a concept to describe an ideal solution to ideal circumstances. In a software team like you described a WIP limit of one makes no sense at all.

Few agile or lean practices have inherent value, they all need a context and business drivers. In this case the driver would be reduced lead time, and if too strict a WIP limit constrains lead time, time to increase the limit.

About explicit WIP limits. It might be beneficial to differentiate between team-internal WIP limits and team-level WIP limits. Explicit team-internal limits might not always be useful but team-level WIP limits are almost essential for a pull-system.

A multi-step multi-team/department organization (read: value stream) needs some mechanisms to keep it a pull system. Without that mechanism what prevents overloading the system? Overloading leads into inventory build-up, increased variation cycle times and everything slowing down.

Scrum offers cross-functional feature teams and meta-Scrums, but those already require a level of organizational maturity and probably changes in the organization. A value stream map, kanban board and some WIP limits require very little (and are good tools for effecting change).

Even if you would have a pure pull-system where work beings only when downstream requests it (for example: customer requests feature from sales rep, who requests it from release team, who request components from other teams, who request designs from user experience teams etc.) you would still need tools to manage it. An opaque black box pull system that you cannot change - including increasing throughput - is not very useful.

A value stream backed by a kanban board with WIP limits is a pretty good management tool.

SD said...

Great Informative post

Pawel Brodzinski said...

I don't think it is important to find the name for the approach. You definitely use parts of Scrum and (parts of) Kanban but labels don't make you software higher quality and you team better.

Personally I don't think Kanban alone is enough to deal with software development ( and you need to use more best practices. It doesn't matter whether you take them from Scrum or from somewhere else. After all techniques which are ascribed to Scrum or Kanban weren't invented along with these methods. They were around for a while already and some wise folks just grouped them, coined cool name and started consulting shops selling their ideas how to make our work better.

Anyway, the idea of experimenting and crafting your process is the one which is deeply implemented in Kanban and the one I really like. I believe every team, if given time, would be able to find their own flavor of software development/project management method as there's no silver bullet which suits us all fine.

Anonymous said...

Very useful since it shows a step-wise evolution of a scrum-like process to a pull system. Since we never use a big-bang approach, we always got something like this.
At the retros every two weeks I would pay attention to discuss the motivations of the team member, to make sure that you’ve got not only a more efficient flow, but also a team that feels more in control of it. So it’s sustainable.
Thanks for sharing!

Rob van Lanen said...

Hi Marko,

Great post, inspiring to read your teams' path to what works best for them!

The answer to your question is easy, you have the Huitale process up and running! :)

Regards, Rob

Kenley said...

Project managers prefer Scrum better than Kanban. It is more oriented toward systems while Scrum has a close affinity with project managers and stakeholders due to their presentation of processes and events. Both their workflows are alike, with the only exception of Scrum having their deadlines better demarcated.