Implementing the Kanban Method using Scrum (a.k.a Scrum with a Kanban spirit)

If my last postrattled your cage, let’s see how you like this one… This post is a thought experiment. This hasn’t been tried in the field, and might be the worst idea in the world. But at a minimum it might be a way to understand better Scrum and Kanban. Let me know what you think.

Let’s assume a client or stakeholder in the organization wants to go agile and Scrum has been dictated to us - something like “Hey - I heard Scrum is a good thing. I want one of that please. I don’t care about other kinds of approaches. I want Agile. Agile==Scrum. Give me Scrum. Scrum. Scrum. Scrum.” (only SLIGHT exaggeration of real life…) Let’s also say we like the Kanban Method of evolutionary change management towards Lean/Agile and we actually believe it is a better approach to change management in the discussed context. So basically it might be a nice idea to give the organization what it wants - Scrum, while giving the organization what it needs - an evolutionary approach to change management. Is that possible? Let’s try to use the Kanban Method thinking and principles while implementing them using Scrum practices and building blocks. Here we go, enjoy the ride…

Well, Kanban says to start with your current way of doing things. Scrum is perceived as a revolution, so let’s see along the way whether we are able to minimize the changes to the current way of doing things.

This is actually quite easy to live with since Scrum is also an Inspect and Adapt framework that seeks to look for incremental evolutionary change using Scrum as a baseline.

Here comes a tough one. Scrum comes with roles, responsibilities and some might say even job titles. Let’s see how we deal with those. One way is to say forget it. I know you’ve read about Scrum Masters, Product Owners and the Scrum Team. But we believe there is no need to change roles & responsibilities up front not to say define new job titles in the organizational structure. This might work and is a reasonable approach but is quite a “cop out”. Lets try to go a bit deeper …

Scrum Team

At least the Scrum Team is quite core to how scrum works so we can probably say that we will define Scrum Teams that will not make any change to existing organizational structure. If we want to play strictly to “start with what you have” we can map Scrum Teams to the current functional teams whatever size they currently are and whatever skills (or lack of cross-functional skills) they currently have. A major alternative here is to start with “Managers Scrum”. See [“Managers Kanban”](https://yuvalyeret.com/2012/09/20/starting-with-managers-kanban-also-called-product-stream-representative-kanban/ the general idea. Applied to Scrum this means leaving the individuals/actual teams alone for the moment. Just create a “Scrum Team” that is comprised of the managers of the relevant functional teams. These managers will run Scrum together for a while until they learn the ropes and are able to go sell and deploy Scrum with their teams, or alternatively decide that different teams might be needed before deploying Scrum fully… I will probably elaborate on this approach in a separate post. Let me know if it interests you to push it up the priority rank…

Product Owner

I would ask the organization who decides priorities or align priorities amongst multiple stakeholders at the moment, teach the “Product Owner” role and responsibilities and start with the people currently involved in the prioritization and backlog grooming activities wearing the “Product Ownership” hat. If needed, they will do it as a team. It is far from being the strong Product Owner that Scrum advocates, but we will evolve in a direction that deals with product ownership issues if we see that there’s a problem and that the Product Owner is the right solution. Some in the Kanban community have a strong case against the Scrum Product Owner. I have to say I’m on the fence on that one.

Scrum Master

Oh the Scrum Master… Well recently even in pure Scrum implementations we talk about the Scrum Master being a management style that should be undertaken by the individual leading the team (yes yes we believe that even self-organizing teams should have a leader that enables this self-organization). So I find it quite plausible here to talk about Scrum Master being a very good description of the coaching style of management that teams need in order to gel and perform better and better over time. And then I say we don’t need to define any specific role like that but the people leading the teams should be inspired. For sure we don’t define Scrum Masters as a position in the HR system. What we might do is find a great coach/practitioner candidate and ask him to play the “Scrum Master”/“Kanban Practitioner” role for the organizational unit (several teams)

This is quite orthogonal to the actual flow framework we are using. But since Scrum is notoriously exclusive of managers (at least the perception is that it is…) lets make sure that managers understand they need to lead their teams to better and better performance, better and better alignment with what users/customers value. Of course Scrum Teams should show leadership by self-organizing to perform better and better. Those leading teams should show leadership by investing energy in team building and performance, decentralizing control while ensuring alignment with the organizational initiatives and values.

First actual step is decide which teams comprise the flow of work and visualize the work flowing in and out of those teams using Kanban Boards and work in the teams using the same Kanban Boards or Scrum Task Boards if someone finds a very good reason to do that. Note in this step there aren’t any sprints or ceremonies yet.

We will use a Product Backlog with Product Backlog Items to visualize the “incoming”/“future” work. A Release Backlog can be used to visualize the subset of that work that is targeted for the current release. Work already in progress or done in this release will also be in the Release Backlog but with a status indication of the work state. Based on this information we can understand how far along in the Release Backlog we are and how the Release is doing. A Release level Cumulative Flow Diagram or Burnup can also help us visualize Project/Release state and help us feel safe and aware of what is going on.

Now that we have the flow visualized we need to manage the work with the concept of flow. Here Scrum gives us some clear guidance that is helpful.

Iterations

We will work in Iterations of 1-4w (Also called Sprints although that is a horrible name. Sprinting should mean short-term acceleration to deal with a special situation. Iteration pace should be sustainable). Let’s assume a cadence of 2w here as that is a reasonable iteration length that many times use successfully and also allows a good frequency of flow management activities. So every 2w we will have a “Business Day” in which we hold :

• Iteration Demo - review the completed work of the last iteration and get product-level feedback on it with relevant stakeholders. The completed iteration should be available as an increment of Potentially Shippable Product which means all items completed are working tested software and the relevant build is a candidate for shipping after no more than a short (few days) hardening.
• Iteration Retrospective - review and adjust our processes based on the last iteration
• Iteration Planning - based on what’s next on the product backlog,  product-level feedback from the Demo and process-level feedback and decisions from the Retrospective, We pull backlog items into the next Iteration. Pull = We take in the right amount of items to have an effective iteration. Not too few to avoid being bored. Not too many to avoid too much multi-tasking and context switches and the danger of not completing anything. Another meaning of Pull is that the team working on the iteration does this planning and makes those decisions. It is important to have a couple of more product backlog items queued up in case we are able to accomplish more than the amount we pulled. The purpose of the planning to is to establish this focused “Iteration Backlog”/Forecast and verify everyone on the team and in product ownership on the same page regarding what the relevant product backlog items mean, the priorities between them, how they will be demonstrated in the Demo, and the level of quality/functionality expected to say they are done (Definition of Done / Acceptance Criteria).

Every day of the iteration we will hold a short (10-15min) “Daily Scrum” standup meeting in which we manage the flow within the Iteration. In this meeting the Team and Product Ownership meet in front of their visibility board (Kanban / Taskboard). They talk about flow since last meeting (What I did last day, what cards I moved), expected flow until the next meeting (What I intend to work on today, cards I’m about to Pull/Complete) and mainly impediments. Impediments can be work item specific or flow problems (bored waiting for devs to deliver something, seeing too many defects in what was delivered feeling uneffective, etc.) Impediments can be solved quickly in this meeting or taken offline by identifying an owner that will deal with them until the next meeting. Items with impediments/blockers can be marked using a special indication on the visibility board. Systemic Flow impediments can also be marked (e.g. mark the interface lane between Dev & Test with a red post-it saying “Nothing ready for testing 23/9”.

Note that since we implemented Scrum ceremonies we are already deep into Kanban Method’s “Implement Feedback Loops”. The Iteration ceremonies provide feedback loops about Product and Process. The “Daily Scrum” provides a tactical feedback loop. Some teams learn to use the “Daily Scrum” to have a tight light-weight process feedback loop as well and add “Kaizen Moments” as necessary when dealing with what appear to be systemic impediments.

We also made some of the process policies explicit by setting the “Definition of Done” of items to be declared Done at the end of the iteration.

Now’s the time to make more of our current policies explicit. Use your current de-facto ways of operating. You will have a chance to change/improve them in your process adaptation feedback loops:

• What is the level of readiness of a product backlog item before the team is ready to pull it?
• Any definitions for the interfaces between roles in the team?
• Any other clear policies governing the work of the team, relations to product ownership, etc.? Estimation policies? Defect Fixing? Release Criteria?

The Iteration ceremonies we defined are also explicit process policies. They answer questions like how do we replenish the system, how do we deliver, etc.

Now after we have a flow system working, it is time to apply the real pressure. We need to constrain the system to guide it towards better flow. In Kanban we do this by limiting Work in Progress. Applied to Scrum this translates to constraining ourselves to work just on items pulled into the Iteration. We will not start working on any other item unless the Iteration is safely done. This sounds trivial, but when there are several people with different specialties on the team it is not trivial at all. It drives people to collaborate. It drives different pains/inefficiencies to the surface and requires us to deal with them.

Note that the Iteration focus is not the ideal way to limit WIP. It is not that clear and explicit and it is harder to go on a diet that tightens the WIP limit from iteration to iteration since the Iteration focus is based on velocity which might not improve so fast even if our focus is improving. Also note that in order for the Iteration Forecast/Backlog to be effective WIP limits we need to plan carefully our capacity and capabilities for the whole iteration to avoid taking on too much (and not challenging ourselves to focus) or too little (and straining our focus to an unrealistic and unhelpful level).

We can always later apply classic Kanban per-lane WIP limits of course. And since many people that want Scrum don’t really understand that the Sprint Forecast/Backlog is a way to constrain and guide improvement we can just skip to the easier and clearer approach of per-lane WIP limits. This will also make it easier to get across the end of sprint inefficiency.

A remaining but important feedback loop is the Ops Review which is a data-driven feedback mechanism that increases accountability to improvement results and accelerates improvement activity. We will add this routine later on typically. There is nothing like that in Scrum but there is nothing saying it shouldn’t be done. Just add it on top of Scrum when the organization is mature enough for it. (I would say after a few months of managing flow and limiting WIP so the systems are stable, clear problems have been solved using Retrospectives, and it is time to seek more pervasive improvement opportunities. )

At this point we try to decentralize the improvement activity to the teams/people. We give them different models to use like Variability / Positive Deviants / Queuing Theory / Principles of Flow / etc. and expect them to suggest and execute improvement experiments and share successful conclusions for reuse by other teams.

I hope this article conveys the message that the Kanban Method can be applied using Scrum as the process framework. This can be useful in case Scrum is chosen by the organization due to various reasons but we believe an evolutionary guided change approach is a good fit for the context or we would like to complement Scrum with the useful change management ideas in the Kanban Method.

I’ve yet to try this in the field but the biggest risk I see in this approach is that Scrum IS focused on flow at the team level and there’s the danger of localized focus when using it as the main process framework. I also have an hypothesis that starting with “Manager’s Scrum” looking at the end to end flow rather than work at the team level this might be overcome.

Improving flow means fewer bottlenecks, faster feedback, and less wasted capacity. Explore flow advisory or let’s talk.