If you talk about "Moving from Scrum to Kanban" you have misunderstood at least one of them!

• Scrum is a process framework for product development. The Scrum Guide says so. And the Scrum Guide pretty much is the official definition of Scrum.
• Kanban is an approach to process control and improvement. David says so. And he is the one literally defined Kanban for knowledge work

Scrum is defined by a specific set of roles, events, artifacts and rules that can make up a software development process when the specifics for your given context are resolved and defined.

Kanban on the other hand, provides mechanisms for controlling your work and improving the way you work together with a set of principles and practices like visualization, limiting work in progress, managing flow making policies explicit and a couple more.

Kanban does not provide counterparts to the things Scrum provides – rather, it is a complementary approach to any product development approach.

You can easily build a Kanban system for any given Scrum implementation - most of the time you just have to model four or five states, identify one to three capacities and define the cadence for the input queue and the output queue. A very simple approach here is to define the

• Stations as "Backlog", "Selected", "Implementation", "Review" and "in production" (and make them visible)
• (bracket) capacity of "Selected" through "Review" := throughput of last iteration
• input cadence := output cadence := iteration size
• iteration size := your sprint size

Of course the real power of the Kanban approach only begins after this stage, when you start to improve the way you work together collaboratively. But that would be another post...

Most of the time the processes inspired by the Kanban approach end up with a much more flow-based solution than typical scrum processes, and that is what a lot of people seem to mean when they talk about their evolution.

But please don't talk about "moving from Scrum to Kanban" – that would be like saying "I don't use a car anymore, I now use a GPS" – and you wouldn't say that, would you?

till next time
  Michael Mahlberg

Self organizing teams: The bad news

TL;DR: Self-organizing teams still need to be one thing to deserve the designation: They have to be organized!

The problem with self organizing teams

They aren't. Self organizing teams are a great thing and work wonderfully. The only problem with this is that most teams are neither. They are neither a team, nor are they organized.

What's a team again?

According to Kevin Grigsby

A team is a group of persons linked together for a common purpose. For the most part, teams consist of persons with complementary skills organized to function cooperatively as a group. (Grigsby, 2008)

Many so-called teams I see nowadays are linked together by the fact that they work for the same company and were available when the project started. Or when the project needed more people-power. Team-members sometimes have complimentary skills in a technical way but rarely in a psychological way.

And the part of "organized to function cooperatively as a group" is more often than not contradicted by personalized rewards, too much work in progress (e.g. 7 people working in 5 different projects and are all present only in one of them) and other elements of corporate dysfunction.

How about organized?

David Allen, famous for his getting things done approach to organization, has written and talked a lot about this, and according to him, basically being organized means knowing what is going on with relevance to you, what are the desired outcomes and what are the next actions.

Yet organization takes time. And sometimes specific personality traits. A lot of the teams that are "self organized by decree" have neither. And very often they don't have any frameworks on how to self-organize.

Self organized is no anarchy

Just to make this abundantly clear: "Do whatever you like" does not make a team self organized! Being mutually accountable for example means that there are ways how team members know what to expect from their peers. Striving for a common goal implies that there is a shared understanding on what that goal is and how to reach it. And of course the teams has to be able to discuss things like schedules and dependent activities with outside parties. So there has to be some knowledge on how far the team has come so far and what is up ahead for the future.

Self organized means you have to do it yourself!

Remember where the whole "self organized teams" stuff came from. It was born out of the knowledge that decisions should be made, where the knowledge resides. And with regard to team organization this knowledge is within the team.
My main point is that we don't want line managers or process specialists who have no insight at all into the dynamics of the team in question. It does /not/ mean that there is no organization inside the team. On the contrary. It's right there in the name: "self organized teams!" And perhaps sometimes it is a smart idea to have people inside the team take care of some organization. According to Grigsby "[…] leadership moves from member to member based on the topic or task assigned and the member’s skills."

till next time
  Michael Mahlberg

Self organizing teams: The bad news

TL;DR: Self-organizing teams still need to be one thing to deserve the designation: They have to be organized!

The problem with self organizing teams

They aren't. Self organizing teams are a great thing and work wonderfully. The only problem with this is that most teams are neither. They are neither a team, nor are they organized.

What's a team again?

According to Kevin Grigsby

A team is a group of persons linked together for a common purpose. For the most part, teams consist of persons with complementary skills organized to function cooperatively as a group. (Grigsby, 2008)

Many so-called teams I see nowadays are linked together by the fact that they work for the same company and were available when the project started. Or when the project needed more people-power. Team-members sometimes have complimentary skills in a technical way but rarely in a psychological way.

And the part of "organized to function cooperatively as a group" is more often than not contradicted by personalized rewards, too much work in progress (e.g. 7 people working in 5 different projects and are all present only in one of them) and other elements of corporate dysfunction.

How about organized?

David Allen, famous for his [getting things done][gtd] approach to organization, has written and talked a lot about this, and according to him, basically being organized means knowing what is going on with relevance to you, what are the desired outcomes and what are the next actions.

Yet organization takes time. And sometimes specific personality traits. A lot of the teams that are "self organized by decree" have neither. And very often they don't have any frameworks on how to self-organize.

Self organized is no anarchy

Just to make this abundantly clear: "Do whatever you like" does not make a team self organized! Being mutually accountable for example means that there are ways how team members know what to expect from their peers. Striving for a common goal implies that there is a shared understanding on what that goal is and how to reach it. And of course the teams has to be able to discuss things like schedules and dependent activities with outside parties. So there has to be some knowledge on how far the team has come so far and what is up ahead for the future.

Self organized means you have to do it yourself!

Remember where the whole "self organized teams" stuff came from. It was born out of the knowledge that decisions should be made, where the knowledge resides. And with regard to team organization this knowledge is within the team.
My main point is that we don't want line managers or process specialists who have no insight at all into the dynamics of the team in question. It does /not/ mean that there is no organization inside the team. On the contrary. It's right there in the name: "self organized teams!" And perhaps sometimes it is a smart idea to have people inside the team take care of some organization. According to Grigsby "[…] leadership moves from member to member based on the topic or task assigned and the member’s skills."

till next time
  Michael Mahlberg

Yes, you do need a “Dashboard” (a.k.a. Andon - Board)

And no, I don‘t like the terms “Project Dashboard”, “Lean Dashboard” or “Agile Dashboard”. I do like the concept of the andon-boards

But what is a(n agile) dashboard, and why do you need it?

Speed is nothing without control

Most lean and agile approaches include some kind of feedback mechanism to enable informed decisions. In Scrum for example some information is fed back into the loop in the sprint planning as the capacity for the next sprint. In flow based approaches the feedback is often build into the work organization. When a kanban approach to process control is in place it can at least be found in the capacity of the stations (a.k.a. WIP-Limits per column).

This may be enough for a while, but it is not enough for the long run.

How often is an autopilot ‘on course’?

Actually not much at all - if it would be possible to set the course once and then ‘just let go’ you wouldn’t need an autopilot. The main reason to have an autopilot is to counteract the little deviations off the course caused by internal or external disturbances. So the autopilot constantly correct to the target, but the target is only reached for very short periods of time.

You’ve got to know that you’re off course to make adjustments

To be able to auto-correct your course, you have to know wether you’re on or off course. And that is what a dashboard can tell you. By making the actual ‘course’ visible as early as possible. On a dashboard. That is updated as soon as the information is available. And this is where an automated dashboard can come in handy.

What should go on the dashboard?

Whatever you’re aiming for!

• You want to spend a certain amount of your capacity on a specific project? Then the actually spent time per project has to go on the dashboard.
  
• You want to increase the test coverage? Then the current test coverage has to be displayed.
  
• You want to spend at least x% of your time on improvements? Then the time spent on diferent types of work has to go on the dash.
• etc.

So, how do you navigate your project?

’till next time
  Michael Mahlberg