Kanban in 24 Hours

Can a process model be mastered in 24 hours? My answer is No. Then you may ask, why this title? I was thinking of writing a master post, which will link all my posts about Kanban and i thought Kanban in 24 hours could catch people’s eyes. Hence this title. I am sorry, i am not going to give any shortcuts. I sincerely believe there is no shortcuts to a place worth going.

I have summarized my learnings/experience with Kanban in the following posts. Its my attempt to capture what i have learnt/read. I may/may not have captured everything i wanted to. But, i guess its a good start.

There is so much written about Kanban and I have provided the reference URLs which i have referred to while blogging these posts.

Kanban Posts Summary
Introducing Kanban : Post introducing Kanban.
Kanban – What is it all about? – Kanban in a Nutshell
I am currently doing Scrum. What is different in Kanban? – Talks briefly about what is changed in Kanban.
Kanban – Changes : Talks about the changes in Kanban Software Development in detail.
Getting Started with Kanban Software Development : Talks about how to get started with Kanban Software Development.
Kanban Taskboard : Talks in detail about the Kanban Taskboard.
Kanban – FAQ : Summarized my learnings in a FAQ format.
Kanban – Summary: Summarized Kanban as a Software development Process and linked to a post which talked about implementation challenges.

Kanban – Must Read Links
Kanban Development Oversimplified
Kanban System for Software Engineering
Waterfall, Lean/Kanban and Scrum by Ken Schwaber
Kanban Systems
Kanban Applied to Software Development: from Agile to Lean
Visualizing Agile Projects using Kanban Boards
Useful Links about Kanban
Kanban, Flow and Cadence
Kanban in Software Development
The Kanban Story

Road to Mastery
It took me couple of years as a practitioner to master agile/iterative development. I liked the Road to Mastery model which James Shore has Proposed in his book The Art of Agile development.
1. Follow the Rules (Apprentice)
2. Break the Rules (Journeyman)
3. Ignore the Rules (Master)
I guess, when it comes to Kanban, i am at Stage 1 (Apprentice).

Happy Reading!!!


Kanban – Summary

Kanban systems helps in achieving better process control (keep continuous flow while limiting WIP) and
better process improvement (Make the flow visible). A Kanban System manages the flow in a way which allows the Product Backlog, time-boxed Iterations and estimations can be eliminated. Kanban provides transparency into both the work and the process, showing how work is passed from one group to another and thereby improving understanding and teamwork. This helps teams to organize themselves more effectively and provides senior management with the visibility required to govern effectively. Improved flow and quality shortens lead times, which in turn improves performance and predictability.

There are two key things which i definitely like in Kanban.
1. Getting to Done. Since the team will work in one MMF and only one MMF, you will always get to Done stage. Most of the times, the development gets stuck because the requirement is not clear. Such things will be highlighted at a very initial stage of development here.
2. Task board: Even though the Task board concept is not something new, Kanban Task board highlights issues when things are not flowing from one stage to another. You have a way to highlight that something is stuck and you can hope that the management and everyone’s attention will be moved to the task cards that are not flowing.

Challenges in Implementing Kanban
I was thinking about the challenges in implementing this in an offshore setup. I found a related article. I just changed the introduction content a little bit.
Following a Kanban process will force us to challenge some ingrained habits.
The idea of limiting the amount of Work in Process (WIP) in a step may sound good, but actually submitting to limits is challenging the first few times . In an offshore setup, there may be a tendency to focus on how much time is spent working or how many tasks an individual is completing.
Kanban forces us to face these measurement systems and correct some of the flaws they drive into our processes. Rather than measuring how hard an individual is working in a single step, we measure how well we deliver through the entire process.
Rather than measure how many hours an individual is working, we can measure how many hours of work we have removed from the process.
Where the old measurement system is asking why we aren’t piling up more work in between development and QA, Kanban is forcing us to question how we can improve the throughput or decrease the rework rate.
Ingrained habits are difficult to change and if you are not a product house and in a services unit, it requires a change at the organization level.
Reference URL
Applying Kanban
Happy Reading!!!

Kanban – FAQ

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.
Perpetual Multivote
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
Kanban Systems
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)
Happy Reading!!!

Kanban Taskboard

In Kanban everything revolves around the taskboard. Let us look at it in bit more detail.

A Kanban System visualizes some unit of value. This unit of value could be a User Story, Minimal Marketable Feature, Plain Old Requirement or something else.

What does a typical Kanban Task board contain?
1. MMFs
2. Development Process
3. Emergency List

Kanban Planning Board

The Left most corner of the task board will display the backlog queue (list of MMFs) along with current MMF that the team is working. The order of this backlog queue can be changed at any time by the stakeholders. This queue is strictly limited in size. A small backlog is good because it limits the amount of time an MMF can wait, which prevents them from getting stale.

The team only works on the top MMF in the queue. Stakeholders can add, remove, and move the other MMFs in the queue as much as they want, so long as they don’t exceed the queue’s size limit.
In the middle you have the Development Process Area (WIP) (Analysis, Development, Automation, Acceptance, Done) which will have the tasks put up for the current MMF.

What comes here depends on the development process you have. Say for example, you might want to have only 3 columns in your board (Not Done, In Progress, Done) and add tags (Analyze, Test, etc…) to your card. Finally this is completely upto you (how you want to have your process)

Finally, have an Emergency List which will make an entry to Development process.

Reference URL:
Kanban Board Basics
Kanban Kickstart Example
Kanban Systems
Kanban board for Lean Software Development
Completing the Kanban Board with Queues, Order Points and Limits

Happy Reading!!!

Getting Started with Kanban Software Development

We have so far looked at introducing Kanban systems and what are different things that has changed. Ok, now let us get into the actual thing.

I am new team who wants to do Kanban. How do i get started?

Following are the steps which i will do for my teams to get started with the Kanban Process.
Step 0 : Identifcation and Definition of Minimum Marketable Features and building the Backlog queue : Without this, no process or system works. It makes the product owner work. i know, this might look very basic, but i am sure most of us work with that the backlog ready even for some period of time.
Step 1: Define and visualize your process : Kanban is about the Visual Task board. You have to decide how the process will work and how do we move items, what is our SLA at every stage and how do we accept a feature. I am not sure, whether you have used a Task board in Scrum. In my teams we have used a Scrum Task board which helps in Navigating items from one step to other. Kanban Task boards are bit more detailed. It defines a limit of WIP per Stage, SLAs per Stage, Definition of Done per Stage.
Step 2: Limit work in progress (WIP) : This is the most important thing i learnt from Kanban. Just reducing the number of items in progress, will help us get to the done as quickly as possible. Also, the team completes a feature and moves to the next one, which makes sure that we are developing features which are absolutely required and not wasting time. Eventhough, in Scrum it restricts the number of items being developed per sprint, it doesnt restrict how many can be in a workflow state any point of time.
Step 3: Promote the new model. Pull – Don’t Push – Pull model is new to the team (atleast not every team is used to it).
Step 4: Measure the Lead Time : Lead time is the average time to complete one MMF, a.k.a “cycle time”. Measuring the average time to complete one MMF will help in understanding what it takes for the completion (To Avoid Complacency, Set the Right SLAs in Stages)
Step 5: PDCA (Plan Do Check Act): Pay attention to the work that is flowing through your system – or more importantly, the work that is not flowing – and fix the problems in the system. This is perhaps the single most under-utilized principle in just about every agile methodology in existence. So many teams and managers are begging to be told what to do and how to do it, so that they don’t have to think and don’t have to take responsibility for the process and its problems. If the work is not flowing and SLAs are not met, Task board has to become Red and the whole team has to focus their attention on the item which is not flowing before completing any thing else.

In a nutshell, Kanban is just a scheduling system. The way it works is, Team pulls a feature from the Backlog Queue, complete the development, testing, acceptance and ships it as soon as it is done. Then the team moves to the next one, the Backlog Queue, complete the development, testing, acceptance and ships the feature. Work is shipped as soon as it’s ready, and the team only works on one (Queue Length) at a time.
Reference URL:
Kanban Systems
How to get started with Kanban Software Development
Happy Reading!!!

Kanban : Changes

We looked at what has changed in Kanban in the previous post. Let us look at those changes and viewpoints in detail.
#1. Time-Boxed Development is Out
When i transitioned from a Traditional approach to an agile approach (Scrum), the most important thing we all learnt is following Time-boxed iterations.
Let us look at the benefits of Time-boxed iterations.
1. Shorter Feedback Cycle. Other than feedback, In an outsourced environment, demos at the end of every 2 weeks (my iteration cycles were 2 weeks) provided lot of value adds. My clients saw the productivity every 2 weeks which gave them confidence, which in return helped us build the trust.
2. Software Development is also like music (based on Rhythm). When we all know how much we could achieve in a specific period (we will have our Rhythm).
3. Estimating items for a short period of time was easier than for a longer period.
And now you are saying Time-boxed Development is out? You must be crazy.
You’d still find the “heartbeat” of regular cycles in a team following Kanban — at least if they’re doing agile right you should. The only difference is the cycles aren’t used to plan and commit to stories any longer.
Why so?
1. First, there are quite of bit of overheads (as seen by people) for every sprints.
2. The other thing which i found is a problem is that writing stories which can be estimated. Atleast to my knowledge, i have not seen Product Owners following all the INVEST principles and writing stories.
In reality, Kanban introduces the term cycle periods (instead of sprints/iterations).
Differences between Iterations and Cycle Periods:
1. You do not use the cycle period for planning, estimating and committing stories.
2. Cycle Times are Scope Bound (similar to the Spiral Development Model) rather than Time Bound (XP/Scrum).
#2. Stories are Larger and Fewer
Scrum recommeded us to write smaller Stories (i am sure most of us has read this book User Stories Applied from Mike Cohn which talked about the Invest Principles).
There’s a lot of good reasons for wanting to write smaller stories.
1. It’s a lot easier to estimate a story that’s small — which can lead to more accurate estimates, and better predictability.
2. It’s easier to plan with smaller stories.
With big stories
a. Stories that might take weeks for a developer to implement
b. It becomes difficult to plan a development time-box — particularly when the iterations are only a couple of weeks.
c. It seems that only a couple stories fit
d. There’s often room for half a story, but how do you build half a story? Splitting them into smaller stories makes it easier to plan those time-boxes.
But nothing comes free in this world. If you write smaller stories, product backlogs become bigger and more difficult to manage. If you analyze the Product Backlog, it can easily be into the range of hundreds of stories. Prioritizing, managing, and planning with this sort of backlog will become very difficult.
Product owners are often asked to break down stories to a level where a single story becomes meaningless (Business Stories -> Developer Stories -> Tasks). To keep track of what’s meaningful (to them and other stakeholders), one often need to build a track of how many stories per feature etc which becomes a maintenance nightmare.
Hence, the notion of stories are larger in Kanban.
This works well if you are not having distributed development teams. But if the teams are distributed, having an Epic Story has its own disadvantage (Requirements understanding, communication overhead etc..)
#3. No Estimation
Agile methodologies (Scrum) introduced a new way of estimation using Story Points and new way of communicating how much can be achieved via Velocity.
If we go back to the basics, the main reason why we estimate is to be able to plan releases and to be able to prioritize.
1. When we know the size of a feature, it’s far easier to prioritize based on how much one can accommodate.
2. Velocity helps in planning how much can be delivered in a Release.
3. Task based estimation at the sprint level helps in deciding the appropriate load (Resource Levelling) and helps the teams to commit on what’s possible.
Now, we are saying that there will be no estimation.
I was talking to a colleague (who moved to Kanban) sometime back about the estimation and he mentioned that most of the times we were not able to meet our own estimates and sprint planning every 2 weeks is not helping them scale.
One reason, for the above is that the features or stories are not estimable. Team is not able to exactly decide. And since, we do not have a time bound sprints in Kanban (Its Scope bound), there is no point in estimating. It works in a Pull model, where the team members completes the task and moves to the next one.
So, the next question comes is do we still need to plan releases and prioritize? Well, yes of course. So Estimating the product backlog with a size will definitely help the release planning team to decide how much can be achieved. We may not use the velocity, but like use some estimation principles to know what can be achieved.
How about task level estimates? No. Since there is no commitment on the tasks in a specific duration (Iterations), there is no need to do this.
Okay, will there be any disadvantages? Well, we will look at it at a different section
#4. Velocity is replaced by cycle time
I am not going to spend talking too much about this. I will talk about the reasons later in a different post.

Reference URL:
Kanban Development Oversimplified
Kanban Estimates
What will Kanban bring to your offshore Projects?
Happy Reading!!!

I’m currently doing (or trying to do) Scrum. What is different in Kanban?

In my previous posts, we looked at an overview of Kanban. When i first heard about Kanban (6-9 months back) the first thing which came into my mind is what is different in Kanban? We’ve been following Scrum for the last 5 years or so and what could be different in this?

In the article Kanban Development Oversimplified, author has mentioned the following will change in Kanban.
1. Time-boxed development is out
2. Stories are larger and fewer
3. Estimation is optional or out completely
4. Velocity is replaced by cycle time

When i first read this, following are the things which came into my mind.
1. We do not have Iterations (Time-boxed). What the heck?
2. Stories are Larger (Epic). Wait, in Scrum we wanted stories to be broken down into smaller stories. What will you do with Larger stories?
3. No Estimation : You must be crazy

Why in the world we need to do all this? I started doing more research and found answers for the above.
I’ll share them in the next post.

Reference URL
Kanban Development Oversimplified
Happy Reading!!!