Having some free time this summer I did a SCRUM reading. I am in the midst of my Scrum Master Certification and I found out about KANBAN!!
It seems a lot of people are reading / practicing Kanban recently. I will try to describe (briefly) how I understand it.
The origin of Kanban is the Toyota Production System:
“The two pillars of the Toyota production system are just-in-time and automation with a human touch, or autonomation. The tool used to operate the system is kanban.” (Taiichi Ohno, Toyota Production System book)
Kanban actual translation is “signboard”, it is a scheduling system for lean and just-in-time (JIT) production.
Kanban System and software development
Kanban has a queue of work, which goes through a number of stages of development until it is done. When work is completed in a stage, it goes into a downstream queue for the next stage. Do you need work to do? Just pull from the upstream queue.
One of the most important Kanban features though is limits! There are two basic limits – Queue limits and WIP limits.
Limiting work-in-progress (WIP) is the cornerstone of Kanban. Each state (or the most important) in the workflow is limited and new work is “pulled” into the next step when there is available capacity within the local WIP limit. If a state is below its limit then it may receive a work item from upstream. If a state is at its limit, it must wait for one of its own items to be complete, and pulled downstream. WIP limit sizes can depend on type of work and size of the team and can be adjusted.
A queue distinguishes work that is eligible to be pulled, from work that is still in process. A queue (or buffer) between states absorbs variation. The queue itself has a limit, so that if the queue fills up, the upstream producer will halt.
The board below shows a situation where the developers and analysts are being prevented from taking on any more work until the testers free up a slot and pull in the next work item. At this point the developers and analysts should be looking at ways they can help relieve the burden on the testers.
Some columns are split in two, to indicate items being worked on and those finished and ready to be pulled by the downsteam process. There are several different ways you can layout out the board. This is a fairly simple way. The limits at the top of the split columns cover both the “doing” and “done” columns.
Once the testers have finished testing a feature, they move the card and free up a slot in the “Test” column.
Now the empty slot in the “Test” column can be filled by one of the cards in the development “done” column. That frees up a slot under “Development” and the next card can be pulled from the “Analysis” column and so on.
Kanban & minimal marketable feature (MMF)
“A minimal marketable feature is a chunk of functionality that delivers a subset of the customerʼs requirements, and that is capable of returning value to the customer when released as an independent entity”
MMF’s can range from very small to very large, depending on context and the stage of the application’s life in the market.
- Stories focus on the customer, with business value secondary.
- The MMF focuses on the businesses value first, which drives identification of the stories.
Software products can be deconstructed into units of marketable value. Typically value is not perceivable as a monolithic whole, but as a series of features. What is unique about software products is, that features are often separately deliverable. A complex software product can deliver value even if it isn’t complete.
Lets assume we have an Epic – “Build an airplane. Value is getting from a to b.”
- MMF1 – Take off
- MMF2 – Fly
- MMF3 – Land
Each MMF gives customer value and would have a lot of stories within them to complete. The thing to note here is that overall none of them released independently will be of value to the customer, only once all three are complete could we release as its no good being able to take off if you cant land. Therefore the three together are classed as a Minimally Useful Feature Set. We can release each independently for testing and to mitigate risk but its important to be aware that not every MMF will give instant value to the customer.
Carry Passengers and Carry Bagage MMFs are not necessary but the customer might demand them before they sign-off.
“A regular cadence, or ʻheartbeat,ʼ establishes the capability of a team to reliably deliver working software at a dependable velocity. An organisation that delivers at a regular cadence has established its process capability and can easily measure its capacity.”
The time-boxed iteration is one form of cadence, which couples planning, review and release together. A kanban system de-couples these events and allows them to have separate cadences, as well as adding two additional ones. Throughput is the amount of output of a process in a given period of time, and Cycle Time is the length of time to complete a process.
Kanban Team Examples
- Kanban team #1 (single cadence): “We do Scrum iterations”
- Kanban team #2 (three cadences): “We have three difference cadences. Every week we release whatever is ready for release. Every second week we have a planning meeting and update our priorities and release plans. Every fourth week we have a retrospective meeting to tweak and improve our process”
- Kanban team #3 (mostly event-driven): “We trigger a planning meeting whenever we start running out of stuff to do. We trigger a release whenever there is a MMF 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.”
Do I like it?
I think yes, it is clean, quick and not prescriptive. You can customise it to your own measures. There is a Personal Kanban version which brings kanban power to your everyday work. Does it work for me? Yes until now. Remains to be seen if it is a hype or it will evolve to something revolutionary.
Sourceshttp://www.kanbanblog.com/explained/ http://availagility.co.uk/2008/10/28/kanban-flow-and-cadence/ www.everydaykanban.com/what-is-kanban/ http://leanandkanban.wordpress.com/
I love technology and working with people. That is why I am trying to offer as much as I can at the local startup ecosystem and at the same time building Apirise. A platform to reduce time and effort required to integrate and maintain APIs. Simply, fast and efficiently!
I am co-organizer of the Agile Greece and API Athens meetups and I contribute at the Developer Economics Blog.