Kanban for Dev projects? How exactly?

“Kanban is good for support projects only. For dev projects, one must use Scrum.”

The above statement is the most prevalent myth about Kanban. The truth is:

“Kanban can be used for support projects as well as dev projects.”

We can possibly refine it further:

“Kanban is excellent for support projects as well as development projects.”

Please note: Kanban in the above statement means ‘Kanban Method’. If you are new to Kanban, you may familiarize yourself with different kanban terms here.

To understand how Kanban could be used for a development project, let us consider a real life situation:

A service organization has a team of about 10 developers working on one client’s project. The client expects a delivery cycle of three months. The team has been using a waterfall-ish approach where the dev team starts with design and development while the testing team (shared resources) is busy supporting other teams. Around one and half months later, when development is about two-thirds done, the testing resources join the project. The next few weeks go by in finishing the pending development work and fixing QA defects. About three weeks before the release date, UAT starts and everyone gets fully engaged in finishing the release on time. Somewhere around this time, the plan begins to fall apart. The team slowly transitions from a ‘sense of urgency’ state to ‘sense of panic’ as the release date approaches – the two primary culprit being the delayed feedback and new urgent requirements that land from nowhere.

Some team members have been pushing for adoption of Agile to end this mess release after release, and finally the management has agreed to explore their options. The first question facing them is ‘To Scrum or not?’ While the experts recommend “Agile=Scrum”, management is feeling anxious adopting a big-bang change approach that begins with defining new roles and responsibilities. “Would we be able to witness improved results within one to three months’ timeframe?” they wonder.

“What about Kanban?” someone proposes a new possibility that raises quite a few eyebrows.

After a few rounds of discussions, the team finally decides to go ahead with using Kanban Method for their development project.

Let us see how the team progresses in their Agile journey using Kanban Method.

Prep work:

1. Committed Resources – like any other agile implementation, the team decides to use five full-time testers, rather than ten part-time testers, to enable faster feedback cycle.
2. Visualize Work – The team decides to adopt a simple Kanban board that has two primary activities – Dev and Test.
3. Defer commitment – There are about forty work items in the backlog, of varying sizes. While the team respects all work items (stories) in the backlog, they know they cannot finish it all in one go. So, why not focus on the top most priority items that will keep them busy for next one week. From experience, they know that given some collaboration among developers (frontend vs backend), ten developers can work on no more five items at any given time. Assuming some items may be done before the next replenishment meeting, they decide to pick the top eight work items.

Notice that the team has defined only one WIP limit on their board to begin with – on the Input Queue. This WIP limit will help the team defer commitment as discussed above.

Getting started

With all the resources on-boarded, Kanban board set and top priority stories selected, the new Kanban team gets started with the work, with a focus on following practices:

1. Stop starting, start finishing – Once work has been started, the team pays special attention to not starting more and more work. First they must finish what is already in progress.
2. Faster Feedback Cycle – With the testers fully committed to the project, they now wait eagerly for work items to be ready for testing. In the meantime, they busy themselves with preparing test cases for the work in progress. They also engage developers in quick discussions to ensure they share a common understanding of requirements. As the first week progresses, on day three (Wed), dev team finishes two items. The testers pair up in testing the finished items, developers pull two new items from the Input Queue. Seeing the possibility of an empty Input Queue, the Team Lead engages the team in a quick meeting where they review the backlog and pull two more items into the Input Queue, based on priority.

Managing the flow

Fast forward to Monday, one item is completely done, four items are in testing and five are in development. One item is blocked in testing due to defects. Being the first week, it is too early to evaluate the pace of development.

With a list of prioritized backlog items, the Team Lead calls the team for their regular Replenishment Meeting where they discuss and pull the next eight items into the Input Queue. The normal flow of work resumes – developers get busy in dev and bug fixing while the testers continue providing timely feedback to developers.

Over the next 3-4 weeks, the team focuses on the following key aspects:

1. Enable the Continuous Flow – While new work flows in every Monday, work is delivered at the end of the queue on an ongoing basis. Remember – there is no strict time-boxing!
2. Avoid being bitten by the ‘complacency bug’ – To facilitate a high performance team environment, the Team Lead has been measuring the flow since day one using Cumulative Flow Diagram (CFD) and Lead Time Distribution curve. He is keeping things simple and transparent for now, drawing them manually on a chart, right next to the Kanban board.
3. Inspect and Adapt – The team uses Daily Kanban meeting (standup) every morning as an opportunity to come together and realign their efforts with team goals. Run slightly different than Daily Scrum, the focus in Daily Kanban is less on worker, and more on work – special attention is given on higher priority items or items that are blocked.

The Early Results

Sustainable Pace: By the end of fourth week, enabled by deferred commitment and faster feedback cycle, the team is progressing towards a sustainable pace – they are finishing about 4-5 items every week, including testing. The cycle time looks quite predictable too – less than 8 days (dev+test), with 85% confidence.

Customer Feedback: The team did their first demo to customer at the end of third week and another one is planned at the end of fifth week. While the customer liked the demo, it gave them some fresh new ideas that them want to prioritize over the rest of the backlog. After some brainstorming, the new requirements make their way into the Input Queue – as top three items in the queue. There are good chances some low priority items in the backlog will be pushed out to the next release.

Team Dynamics: The team likes the new development process:

• Minimally intrusive change approach – The developers feel like the world around them magically transformed for the better, without them changing much. They still do the development the same way as before, with the key difference of faster feedback and tighter collaboration with testers.
• The testers like it too! – The testers like the new ‘one project focus’ for a sustained period of time. They feel this improved focus has improved their productivity as well as quality of testing. They expect to see a reduced number of escaped defects.
• ‘One Team’ feeling – A closer interaction among developers and testers, coupled with a sharper focus on getting things done have removed the “we vs them” mindset that was prevalent before. The developers and testers now feel part of one single team.

The Next Steps

The above case is an example of a quick start with agility that does not require new roles or other heavyweight processes. But, this is only a beginning and improvement possibilities are endless. Below are some options that may provide the next steps towards better agility:

Refine the Continuous Flow: Based on the cumulative flow diagram, the team may define WIP limits that will help the team improve cycle time further. Define explicit process policies may be another enhancement that will bring process transparency and consistency.

Define Classes of Service: The team may define different classes of service to help them segregate work into different categories based on ‘cost of delay’ so they can pay special attention to higher class of service without causing a sense of chaos for the entire team.

Extend Faster Feedback Cycle: Withtesting having moved closer to development, the work will now begin to accumulate at the end of the flow – with items being ready for UAT. It may be good idea to add a new column “Ready for UAT” and start engaging the UAT team sooner, possibly on the board. Few weeks or months later, it will be time to engage Operations team in a similar fashion, so end to end delivery follows a smoother, continuous flow.

Implement the Feedback Loops: While Daily Kanban provides an ‘inspect and adapt’ opportunity on a daily basis, the team may want to conduct a Retrospective or Service Delivery review to ‘inspect and adapt’ on a fortnightly or monthly basis – so the team can continuously improve their processes.

Thank you for reading a relatively longer post! I hope you found some value in the ideas presented above. For question, clarification or critique, please use the comments section below.

Cheers!