In a recent thread on the kanbandev list, Tim Uttormark asked about how Kanban handles teams with different dysfunctions without the Sprint timebox and associated meetings.  He gave the following example:

In Scrum, all tasks for the iteration are estimated by the team in sprint planning. Tasks assignments are not known at the time of sprint planning. The task estimate results from a team consensus, so the one doing the work on a task is not (solely) responsible for creating the estimate.

In my example, Harry (due to his incompetence) and Bill (due to his laziness) would fall short of the standard set by the team’s task estimates. Jeff’s behavior will not point as clearly to him as the problem, but will still be manifested as a team issue. Since he is highly skilled, he is probably able to produce at a higher rate than the average team member, and he can finish his tasks on time despite overengineering them. The team however would be better off if he stopped at “good enough”, finished early and moved on to other tasks. Jeff’s dysfunction would likely be manifested as the team missing their sprint commitments — the team needs the above average performers to complete more than their share of tasks to compensate for the lesser performers. In this case the team’s estimate of how much work they can commit to completing in an iteration provides a standard for comparison of team performance. Of course this can be gamed too, but requires more of a team conspiracy than just individual efforts to undermine it.

I responded by trying to map the Scrum process onto a Kanban process in order to show how a kanban system might deal with the same situation.

Sprint Planning is where the team collectively and collaboratively plans and commits to a small increment of work. As you say, this meeting will highlight any mismatches in understanding of the problem or solution by generating the Sprint Backlog with tasks and estimates, such that the whole team has a common understanding of what needs doing and how long it should take. Harry’s incompetence can be mitigated because he should have a better understanding of the solution. Bill’s laziness can be mitigated because he has been part of the estimation process, and Jeff’s over-enthusiasm can be mitigated because scope has been clearly discussed.

The Sprint Review is where the team are accountable for their Sprint commitment. This accountability should again mitigate for Harry, Bill and Jeff, because they have to demonstrate their progress and explain variation from the plan.

The Sprint Retrospective is where the team can explore reasons behind variations from the plan (and strengths and weaknesses in general) and can inspect and adapt in order to learn and improve. Over time, this can also mitigate individual weaknesses.

So for Kanban…

Sprint Planning becomes Feature Planning. Rather than planning a timeboxes worth of product increment, the team plans a single valuable increment at a time – sometimes referred to as a Minimal Marketable Feature (MMF). The team limits the amount of work in progress in order to minimise the cycle time of these MMFs. Once they have completed and released an MMF, the pick up a new one and start by planning it. The Planning can happens as a team, and break down into tasks and estimates as per Scrum, thus bring the same benefits and mitigating weaknesses in the same way. A possible downside is the break in flow that may happen when you bring the team together. A solution to this could be to keep a prioritisation and planning cadence – e.g. a weekly meeting to decide what the team will be working on next, and to plan it out. The frequency of this meeting will probably depend on throughput. The more frequently the team is able to complete and release work, the more frequently this meeting can be scheduled. A difference between this planning cadence meeting and a sprint planning meeting, is that the planning is ‘de-coupled’ from the release. In other words, whatever is planned does not have to be completed and released before the next planning meeting. In an ideal world, however, the MMFs are able to be small enough such that they can be completed and released within a week. In this case, Scrum with weekly Sprints can look very similar to Kanban.

Because of this ‘de-coupling’ of planning and release, a commit and deadline is made per MMF. This is sometimes referred to as a Service Level Agreement (SLA) between the team and business. The SLA says that the team will deliver features X days from when they are prioritised in the planning cadence, and is usually derived from past measurement of cycle-time. Where there is variability in the size of MMFs, different SLAs can be set for different sizes. Standard Scrum story point estimating can be used to classify the MMFs into different SLAs. A Due Date Performance (DDP) metric can also be measured, which is the percentage of MMFs delivered within their SLA. This SLA and DDP is what creates the equivalent team accountability in Kanban. I blogged some more about this here.

Sprint Review can still happen as part of the Release cadence. However, as we have de-coupled planning from release, this can happen as frequently as necessary, depending on the cost associated with a release. In the ideal world, this cost is zero, and you could release small MMFs daily. In this case, a small review of each MMF as it is completed might be appropriate. If there is a small release process the team needs to go through, then a weekly release cadence might be better, with a weekly Review. Whatever the frequency, the release cadence brings the same accountability for what has been delivered, and how long it has taken.

Sprint Retrospectives, similarly, can still happen with their own cadence. Kanban does try and shift the emphasis on the improvement to be as continuous and ‘kaizen’ as possible, but a fortnightly or monthly retrospective would certainly be a good thing to start with. Again, the retrospective brings the same benefits as in Scrum. I blogged some more about this here.

So I’d say in summary that a kanban approach includes all the elements of Scrum (including stand ups as well), but decouples them from all being tied to the Sprint. This can create a more natural process. On the other hand, it can also be less clear what to do when as its not so defined.