Kanban, the cucumber way

Nothing is fixed and any process, any method should be (must be?) flexible enough to take into account its context (without sacrificing its values). Briefly, we must be able to adapt any practices to its environment.

For the project I'm currently working, we needed a better method to track and share tasks. Our team is hybrid and we relied on the Kanban that we sprinkled with a small amount of context.

Here's how we did it

Context

An eBusiness project with an offshore development than a dozen people using the Scrum methodology.

The local team, which we call PO team, manages several aspects and is composed with :

• POs, because this project consist of several sub-projects intimately related;
• infrastructure engineers to manage local infrastructures : integration, pre-production and production. They do not manage the offshore development environment;
• business analysts who help the POs for collecting requirements, user validation, writing user stories etc ...;
• developers in charge of sensitive tasks that can not be performed offshore. They do not do the same tasks as the offshore team does;
• UX and content managers in charge of defining the design and to create objects related to this design.

Consider the BA at the same level as the PO, and then we have 4 channels that make up the PO team. It is managed by a single manager and it is to help him in managing those tasks, their dependencies and sharing with everybody that we decide to try using Kanban.

Why not Scrum ?

Our main task is to ensure that user stories are complete and with the status "Ready" for poker planing.

We do not intend to work according to the same cycles as the dev team does but to move ahead in parallel so they can peacefully work on their sprints.

Practice

We run after several aims :

1. Create a real cohesion between the different channels forming this team;
2. Easily get a good view of the current tasks, upcoming tasks and backlog of these four teams.

Here's what our Kanban looks like :

Some explanations

Our tracking table is divided into 4 zones. Let's start with the end :
In the next schemas "tâche" mean "task". It's french ;-)

Kanban schema

Done (4)

This column corresponds with "Done", all tasks completed during the week. This area is cleaned at the beginning of each week and has no limit.

Rule of entry in this column is that a current task is now complete

In progress (3)

This is the area inventorying tasks currently treated by a person of the team.

This column is divided horizontally by individuals, themselves organized by channels. Those channels are not displayed.

Why such an organization ? Only members of the same channel can share the responsibility for tasks of that channel. Basically, a task belongs to the specifications or to design or to sensitive developments or to infrastructure management, but rarely to several simultaneously.

It goes without saying that in this way, the visual management workflow is greatly facilitated

The names in this column are organized by channel. It also helps to visualize the impending tasks per channel and therefore the amount of work to be done by them.

Rules of entry are:

· A task found in the To do next or high priority AND not started

· No more than two individuals tasks (WIP = 2)

Except case of force majeure, any task in this column must exit with the status "completed". This avoids  to start a lot of tasks but to not finish anyone.

To do next (2)

The column 2 is for tasks to so-called "imminent". They will be the next to be treated by individuals. They are placed there because they correspond to the needs of the moment. This column can be reordered regularly.

If in the next step, the person in charge of the task is clearly identified, it is not here. By cons, at this stage we already know clearly whether it is a task for sensitive development, specification, design or management of infrastructure. Individuals are interchangeable within the same channel so here the one in charge is not yet set. This is during the transition to the next step (3) that someone will become responsible for the task.

The WIP is 2 tasks by individuals. It's not a WIP by channel but it have the same result with keeping some flexibility to assign them to others.

Rules of entries in this stage are:

· The task existed in the backlog and was one of the next according to the timeline (see backlog)

· Emergency

· WIP of 2

The backlog (1)

Organized by activity (infrastructure, development, specification, design), it thus consists of four main areas:

• SYS for "systems" where they enter their tasks about different infrastructures;
• DEV for "development". It's dedicated to sensitive developments (not to be confused with the offshore team);
• DESIGN for ... guess it. All task for UX and CM;
• SPEC for "specifications". This area covers both the PO and BA.

We also try to organize tasks by priorities with a timeline. Basically, the less important tasks are on the left in the backlog and the most important ones are on the right in the backlog.