7 Things to Keep in Mind When Implementing Kanban

There are situations in which Scrum is not the best choice and the most common case are the small projects when the number of team members is less than 4, or when it is impossible to plan even one iteration in advance. It is often the case when teams are dealing with solving bugs, system maintenance or escalation by end users.

These teams usually get new tasks every day, changing the priorities that have been previously installed. We found that in these cases the Kanban approach gives better results and a better control over the process. Kanban has a continuous focus over which are the current priorities. In this way, even very frequent changes in priorities are transparent and clear to the entire team, and problems are quickly observed.

A Brief History

Kanban was first developed in Japan (by Toyota in the 1940s), and the word’s meaning is billboard. Toyota’s employees started using cards (kanbans), to inform the other team members in the production when they needed more parts.

This approach is called JIT (just in time) and it allows the plants to create only as many parts as were needed at the time, not wasting resources by extra production.

Software developers have adopted similar ideas to establish their own practices of the Kanban system as a tool in the agile development process.

Kanban consists of a large backlog of user stories that is need to be accomplished. Business owners/ stakeholders should maintain and prioritize that list dedicatedly, because it is the only source of work for the developers.

When a team member wants to work on a new story, s/he pulls it out from the backlog and into the Progress column on the Kanban board. As the project goes on – it moves across the board until it is completed.

The team should not start any other items from the backlog, until their current project is complete.

1. Kanban Components

Kanban is an Agile methodology, designed to improve the teamwork, and everything that affects your team functioning. Kanban consists of these components:

• Columns / lanes for the user stories. The user stories are put in such a scheme for better representation of the work progress, and this is a crucial part that makes Kanban a great agile option.
• Large working backlog. In the backlog – the new user stories are added by the team leaders, business owners, and anyone who is in charge about the team duties and tasks.
• Regular releases. Kanban doesn’t have sprints that require you to release a new iteration after 15 or 20 days. Instead, agile teams on the Kanban system release software or marketing projects as soon as they are completed.
• Work in Progress (WIP) portions. Each column has its own limit, and once the limit is achieved – no new items will be accepted, until one is removed. E.g., if you have 5 stories that are waiting for review by an editor, and your WIP limit for that column is 5, you cannot enter new function into that column, until one is finished.

2. Kanban usage in the marketing

The Kanban system can effectively be applied in the marketing systems, and its advantage is that it doesn’t require a lot of resources and planning to get started.

You won’t need to change your teams if you plan to introduce Kanban in your environment.

Kanban will assist you to prioritize your duties, will clarify the marketing tasks you are working on, and will assign equal workload to all marketing team members.

3. Prioritize Work with Kanban Backlog

The Kanban system has also some drawbacks that originate from the product owners and from the project leaders, when they are ignoring the backlog.

The pull-driven Kanban model means that team members will get their next assignments from the top of the backlog. If something important has appeared, and it has not been incorporated into the backlog, it will not get the team’s dedication.

4. WIP Limits for consistent Workflow

If you define the size (quantity) of work that you need your team to accomplish with the Kanban board’s columns, you will obtain a consistent flow of work.

The usage of WIP limits will ensure that the team can complete the backlog items fully before inception of a new task.

Scrum methodology issues new releases at the end of the sprints, while Kanban methodology releases are issued when any update or feature is finalized.

Marketing people can start parts of a campaign as they are completed rather than waiting until every single part of the campaign is finished.

5. Advantages of Kanban for Agile Marketing

If you decide to transfer from Scrum to Kanban, you’ll see some improvements in your team’s motivation and efficiency almost instantly.

Introducing WIP limitations instead of sprints – will provide your team the flexibility that is required to perform some important marketing goals.

6. Eliminating Sprints

The advantage of Kanban in the agile marketing is that it doesn’t limit your work into pre-determined sprint duration. In some cases (your team habits) and the market surroundings, this can be more efficient than Scrum-style sprints.

In today’s world, marketing issues are changing permanently. We can’t allow our development team several weeks to do anything they might be able to do, and that means much shorter sprints.

This constant “rush” can create a lot of stress for an agile team, particularly if urgent issues crop up often and derail their focus. Kanban doesn’t need the time frame of a sprint, and some teams will work without this limit. Others will need to keep the constant timing of the sprint clock in place because it helps drive them on.

7. Differences between Scrum and Kanban

There are several differences between Kanban and Scrum (most used Agile methodologies) and the most important are regarding the time frame, and regarding the meetings/ rituals. We will just point out the following differences:

• Scrum is time-limited, while Kanban does not have this type of limitation;
• Scrum does “pull” in iterations, while Kanban does “pull” for each deliverable item;
• Scrum measures the “velocity’, Kanban measures the “Lead time and the Cycle time”;
• Scrum defines roles in the system (SM, PO, Dev), while Kanban does not have roles, and is open to team extension at any time.
• Scrum limits the changes during the iteration, and Kanban is open for scope changes at any time;
• Scrum limits the communication with the “business” and refers to the product owner, while Kanban insist of active participation of the “business”;
• Scrum improves the process at the end of the iteration, while Kanban insist on JIT improvements;
• Scrum insists on estimations (time, story points etc.), and Kanban is goal-oriented, does not insist on estimations.