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)