Archive for September, 2011

Kanban improves self-organization

September 23, 2011

Today I’m very excited to share with you an incredible side effect that I’m observing in all Kanban implementations that I’m coaching: all teams are improving their self-organization skills! Teams that already had some self-organization are improving it. Teams where their managers were still doing command-and-control are now becoming self-organized, leaving more time for their managers to focus on more important things than scheduling each and every task to their team members.

For instance, before Kanban, a team member wasn’t ever concerned with his colleagues’ work if it didn’t interfere with his own, because his objective was to finish his work only. After Kanban, his objective became to shorten the team’s cycle-time, which is a team-wide metric. With this in mind, all team members started to help each other, which improved their overall delivery rate. This is a very clear example of self-organization improvement!

Another very interesting example is a team where their manager was still doing command-and-control. With the Kanban board he started to focus on the tasks entrance queue only, leaving to the team the job to pull their work. The thing is that this “simple” change is the turning point from command-and-control to self-organization! Which means that now his team is self-organizing itself! This change also freed him much more time to focus on impediments resolution and process improvements with his team, which means that now he and his team are talking more about higher level things, smarter things, things that can really improve the way they work. Amazing!


Kanban improves self-organization in two very clear ways: by forcing a pull workflow instead of push, which breaks command-and-control on its roots, and by setting the team-wide objective of shortening cycle-time, which induces all team members to be more collaborative, efficient and effective.


Experimenting with Kanban: the work is flowing!

September 13, 2011

One thing that I teach during a Kanban implementation is that the entire team should clap when they make a work item go through their entire workflow. This helps the team understand and internalize that their work has value only when it reaches the final step of their workflow, which for software teams its usually a deployment in a production environment.

There was a team, in particular, that was struggling to complete their work items and no one could understand where the problem was. After I helped them implement Kanban, the two main problems appeared on day ONE:

  1. The acceptance step was taking too long, accumulating many work items. Everytime this happened, the team started new work, which was causing a lot of context switching when they had to fix bugs or deploy the accepted work to production.
  2. New work items were arriving very poorly defined and with many pre-requisites missing, which caused a lot of work items to halt in the middle of the workflow, causing high traffic on their wall board and many context switching between work items.

To solve the first problem, the team stopped accepting new work if the work already at the acceptance step didn’t get approved (WIP limits!), which forced the business guys to focus on accepting the work already done before asking for new work. To solve the second problem, the team started to refuse work that was poorly defined or with pre-requisites missing (explicit transition rules!), which drastically diminished the halting problem.

At the beginning, this team seldom clapped, at most once each 15 days. Today, this team claps every single day, and I’m not kidding! Today we can say that the work is flowing!


People really want to deliver and improve the way they work, sometimes they just don’t know how. Kanban, with its visualization, flow and explicit rules, helps any team find their bottlenecks and solve it, starting at day one!

One great advantage of Kanban over other agile frameworks: no disruption

September 5, 2011

The Kanban method practices can be resumed in: Visualization, Flow and Explicit Rules (WIP limits + state transition rules). The interesting point here is that none of these practices implies that you will need to change how you work today. You can start a Kanban implementation simply by:

  1. Drawing your actual workflow, understanding it and mapping it to a Kanban board, to achieve visualization;
  2. Paying attention to your actual flow, measuring it and assessing its efficiency, so that you can start to track and improve it;
  3. Turning your rules explicit by writing them on your Kanban board, so that you can understand how your workflow steps relate to each other;

After you do that, you will start to understand your actual process more deeply, and as a consequence you will be able (and willing!) to improve it. Not just you, but all the people involved in your workflow! You will also start to question if some steps in your workflow are really necessary. Better yet, you will start to question why some steps are taking so long to complete and why some activities always accumulate at some steps.

Relating to your flow, you will be able to track the time needed to complete your work items and how many items your team can deliver at any given period. With this information at hand, you will even start to know your real capacity! As a consequence, your team will enjoy splitting and scheduling their tasks so that they can deliver their work items as fast as possible.

By turning your rules explicit, all the people involved in your workflow will start to behave better, because they will clearly understand what each other needs to do their tasks more efficiently and effectively. Better yet, you will be able to improve those rules, now that you know them explicitly, resulting in a faster delivery rate of the work items on your Kanban board.


A Kanban implementation can always start with no disruption: as simple as a map to help your company understand how it is operating today. This map will show three things: today’s workflow steps, today’s flow and today’s rules. Once you and your team understand how your company is operating today, you all can start to improve it. And believe me, people really wan’t to improve and deliver faster, they just don’t know how… but this is the subject for another post.