This blog entry is an attempt to summarize my learnings in a FAQ format. There are certain questions for which i do not have an answer and may be i will learn as we do more and more of this development.
Can Kanban solve all my development problems?
In reality, no process model will solve all your development problems. It depends on how you structure your development. Kanban is no silver bullet.
In my opinion, the most important value Kanban Process model adds is the Taskboard. If something is not flowing from one stage to other, the cards becomes RED and everyone has to attend this. Your management (if at all they look at, will also come to know that something is not moving). If your management (Senior, Program, Project and Product) teams are insensitive to this, then i do not think its going to help.
Do i need write requirements in detail?
My answer is you need to definitely write requirements. Level of detail depends on your teams. Any Process model (whether its traditional or agile) requires the product management team to write requirements. If your Product owners are busy doing things other than writing requirements, then no process model in the world can help.
Also, its very important to write the Acceptance Criteria for the specific feature.
Should the requirements be in a User Story Format?
In Kanban, we call the requirements as Minimum Marketable Feature. It can be in User Story Format or Use Case Format or Plain Old Reqsuirements Format. The thing which you should take care is completing this feature/story should add some business value.
How do i bring Technical Stories in the Backlog Queue?
I do not have a straight forward answer as i am still learning. What i assume is that, you will be developing the technical functionality to achieve some business functionality. So whenever you are working on the specific feature, the technical story will be broken down into tasks and taken for development.
Why cant we have the Technical Story as a MMF?
Since completing this will not add any specific business value, i do not see a reason why it needs to be developed seperately.
In scrum, we used to break a user story into smaller stories. What happened to that concept?
If we break the stories into smaller pieces, there are couple of issues which we need to handle.
1. The Backlog becomes very big and it becomes very difficult to maintain
2. Completion of the smaller stories itself doesn’t add any value. You need to have a track to complete all the smaller stories which would make the full version.
How do i Prioritize and Schedule MMFs from the Backlog Queue?
At any point of time, the team is going to work on only one item. If that is the case, we have to have a reliable method of picking the next item. Sometimes the work has a natural order and more-or-less picks itself. Other times, we have a backlog of things to choose from and have to make a decision.
I found an interesting link where he talks about the prioritization of MMFs.
What kind of projects are best suited for Kanban?
With my current knowledge, i feel that the ongoing development work will be right one for Kanban. In an Ongoing Development, we are not developing anything from scratch. You will be working on next version releases and hot fixes and i feel Kanban will perfectly fit this.
I was talking to a client sometime back, where he mentioned that they release every 2 weeks. Since their application work on Click Once based Deployment, everytime there is a new version every one using their system is going to get the new version. In my opinion, Kanban will perfectly fit here where you develop something, complete the acceptance and release it.
SaaS/PaaS Models could be another place where this could work perfectly where you will be running one single code base for multiple instances.
Why do you think Kanban may not be the right for a new development?
Well, i have my own reasons for it. I work in a Offshore development setting, where i do not see dedicated engineering team very often. New Projects will always come in a Fixed Cost mode and i am not sure how we could map this development process to the new development. May be we could, but at this point i am not really sure about this.
Do we still have a Product Owner in Kanban?
Yes, I do not think it will change. We will have one Product Owner.
Do we still conduct standup meetings?
Yes. We still conduct Standup Meetings. Standup meetings are not status meetings. The team will be asked if the board accurately reflects what is been under development. The team will be asked if there is anything that is slowing down or stopping throughput (impediments). After these two questions are answered by the team, the stand-up is over.
Ok, In Kanban, People say there are no estimates. Then how do you really track? Do i have to wait till the development team shows some mercy on me?
Cycle Time, is the time between when the team starts working on an item and when the item is delivered. This metric becomes a key management metric to reduce variability in the system, make reliable commitments, and provide insight into whether improvement efforts are delivering expected results. Cycle Time is easy to capture. When a card is pulled into the first work queue – enter the date on the card next to Start. When the card is moved to the last queue, enter the date on the card next to Finish. Cycle time is Finish Date – Start Date. At the end of the week, when you pull cards off the board, capture the cycle time for each card into a spreadsheet or whatever tool you are using for tracking.
In other words, you measure the typical time it takes to complete an MMF (“Your wait from this point will be XXX days.”), from start to finish, and extrapolate to various points in the queue. Since MMFs can vary in size, this is a rough projection, not a commitment.
Total Cycle Time = Number of Things in Progress / Average Completion Rate
Some useful references
Kanban and When will this be done
If the team isn’t estimating or planning with fixed time-boxes, how can it make reliable commitments?
I found the answer for this question in this blog entry Kanban, Flow and Cadence.
A regular cadence, or ‘heartbeat,’ establishes the capability of a team to reliably deliver working software at a dependable velocity. An organization 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. The relationship between the two is:
Throughput = WIP / Cycle Time
Throughput allows forecasting of future capability, without needing to specify what might be delivered. Cycle Time allows commitment by becoming an SLA with the business (see Kanban Commitment). Where the size of work varies, from large new features to small fixes and change requests, then a classification of MMFs can enable a range of cycle-times. Both Throughput and Cycle Time can be charted and trended, in a similar way to XP’s Velocity, as a means to encourage the team to improve. A Cumulative Flow Diagram can also make visible how the work is flowing through the system and highlight bottlenecks.
For longer term forecasting, a quarterly planning cadence focusses on quarterly goals and objectives. MMFs can subsequently prioritised to meet those goals and objectives. A regular release cadence will build up trust that the team will work to its full capacity and throughput.
Other cadences, are daily stand-up meetings, and regular retrospectives and Operations Reviews as described by David Anderson. Some teams are using a Retrospective Kanban to signal when a retrospective is necessary, and I have already blogged briefly about Kanban and Retrospectives.
The consequence of Cadence is that commitment and reliability is achieved though measurement as opposed to planning.
How do i handle bugs?
If you are following agile, then you have to complete the bugs, before you call the feature as done. Incase, if the bug is found after the feature is marked complete/or from the production house, then it has to be scheduled as a new MMF. If its Critical issue that needs to be fixed immediately, then it goes into the Emergency List Queue and takes the highest priority.
What goes into the Emergency List Queue?
Typically, any fixes that goes as part of the Hot fixes, any Production issues will be part of this. The team strives to finish urgent items quickly, and they try to keep the slot empty and available at all times.
Why does typically everyone suggests to have the backlog queue limit as Seven?
Basically, the idea is that any human being can remember only a maximum of seven items. So, its suggested that you have only Seven as the Queue Limit.
How many items can be under Work in Progress?
When i started i had this confusion of how many features can be under WIP. If you are following Kanban, then you can have only 1 MMF under WIP. There could be multiple development tasks for the current MMF under development. Set the WIP Limits for these tasks at different stages.
We used have something like Definition of Done in Scrum. Does Kanban also suggests the same?
Yes, In Kanban you have DoD (Definition of Done) defined at every stage and you verify that before pulling it to the next stage.
When will a Task card become RED and why does it have to become RED?
When a task is not flowing from one stage to another within the SLA defined, the Task card becomes RED. When its RED, the objective is that there is an impediment (Items are not flowing) and everyone will have their focus there.
If you are using the manual task board, then its very important for the Leader/Manager to keep a track of all this. In our teams, we have automated this, so if the task is not moving then the Task Card becomes RED automatically.
What are measures of success in Kanban?
1. Increase in throughput
2. Decrease in cycle time
3. Work in Progress does not include defects
What are the Metrics captured?
I am still exploring this area. I do not have much information at this point. Following are the items which came into my mind immediately.
1. Average Cycle Time
2. Median Cycle Time
3. Touch Time : Amount of time spent working on any one thing.
4. Weekly Throughput = TIP/cycle time
5. Cost Per Feature
6. # of Critical and Blocker bugs not resolved
7. # of bugs not verified
What is ideal Queue Size for each stage?
Queue sizes are subjectively derived based upon team size, and Median cycle time. Each queue has one slot for signaling a thing is finished and ready to be pulled in to another queue.
Its upto the team to decide what is the ideal queue size at each stage.
Example: MMF Could be 7; Development could be 5 and QA could be 2
I am still exploring this aspect. Will update as soon as i have more information.
We used to Sprint Demos at the end of every Sprint. In Kanban, there is no fixed iteration length. Do we still do Demos?
We call it as Tradeshow. Could be scheduled every month.A Place to demo what features have been released since the last tradeshow. This is to celebrate success of working software in production. People may wander through the area, getting demonstrations from the Developers who are responsible for completing the features. Its an opportunity to view the accomplishments of other team members, stakeholders, and anyone else who cares to look at the great things being produced by the team.
How do you handle Retrospectives in Kanban?
There is no hard fast rule on when to do a retrospective in Kanban. Typically once in a month, the team will analyze this process and determine if improvements need to be made. Example of items to be reviewed are operations, teamwork, and product development process.
How do you Visualize Work in Progress?
Using Cummulative Flow diagram. Cumulative Flow Diagrams show the relative amount of Work in Progress for each stage (or queue) over time. Variations in the gap or bands represent bottleneck situations and typically occur due to overrides in the work in process limits. The amount of work in process is also a predictor of the remaining cycle time.
Reference URL : Cummulative Flow Diagram
Following are some of items which i am still finding answer.
1. UI Designers in my company are shared across projects. How do you reserve time from shared resources and handle them in Kanban?
2. What are the work in progress limits for each step of your process flow? (Eventhough i had posted my answer for this, still have some more work to do in this)