Kanban in APPPM

'draft_ by Jesús Gracia Yoldi'

Abstract

In any successful project, programme or portfolio, the weight of planning and management is vital to deal with the various types of complexities whether seen from technical, time, goal, social, organisational or legal perspectives. When establishing a complexity management plan to treat a time issue, the team should be under the guidance of a schedule, which allows clarification for issues such as when tasks have to be carried out. For this purpose, various methodologies are used, among them the Kanban methodology.

Kanban, translated to "visual cards" or "billboard" from Japanese, is a scheduling methodology in which you can maximise the productivity of a team by the optimisation of idle time of each process that results in the completion of a unit or project. It was introduced in 1947, by Taiichi Ohno, who was an industrial engineer working for Toyota and father of the Toyota production system[1]. It was created to avoid waste, commonly known as Muda[2] in project management terminology, consequently increasing efficiency in product manufacturing chains. Kanban allows the team to visually target and remove bottlenecks, identified by avoiding these wastes, to reduce queuing times and increase throughput . It was conceived in such a way that its use was directly related to Lean Manufacturing systems and the achievement of JIT (just-in-time) delivery approach.

This article will first provide an introduction and context to the concept of the Kanban methodology. This is followed by an explanation of its use and applications. Thirdly and finally, it will address its limitations, establishing its strengths and weaknesses.

Context

Origins

In its beginnings, Kanban emerged as a scheduling system, primarily for lean manufacturing. It was implemented in 1953 as a new approach in the Toyota Production System. The key distinguishing factor was that the principle was based on a pull system, meaning that production is driven by customer demand, as opposed to pushing systems in which production attempts to integrate products into the market.

The Kanban idea was originated from the observation of the product flow in supermarkets. The customer buys what is sufficient and necessary, knowing that his future supply is guaranteed. Consequently, the supermarket has in stock only what is expected to run out within a certain period. This phenomenon made it possible to extrapolate the idea from supermarkets to Toyota's production plants, making the following statements:

• Anticipation:It implies de concept of demand- forecasting. Consists of aligning inventory according to the consumption of its products. Set up a signal with which to keep track of consumption, so that if it fluctuates, there is a margin for manoeuvre.

• Communication: Establish an inter-departmental communication system that allows cohesion of processes, to avoid misunderstandings. Every process needs a requirement to be able to perform its task. Once the task has been completed, one department hands over the card to the next, so that the other can start its own.

• Procurement: Any re-provisioning of resources between departments must be notified by handing over the cards.

Agile software developing teams in 2000s

Throughout the years, the Kanban methodology has remained a popular tool in production lines and is very common even today. Simultaneously, in 2004, the first case of Kanban being used in software development occurred. David J. Anderson noticed that a team of Microsoft professionals was not working optimally.

The Kanban method in software brought a new perspective to visualise the workflow, in which all developers were able to identify bottlenecks within the process. This insight led to a reduction in the number of workstations, converting them into charts with notes attached to them.

Kanban: principles & practices

Kanban methodology prompts teams to be far more tolerant, coping with unforeseeable disruptions or issues. The flexibility of the framework facilitates monitoring the workflow without putting too much strain on the actuators. To understand how this interaction is achieved, it is important to be clear about its pillars:

• Start with what is familiar: The strategy is visual and comprehensible so that it can be implemented on top of an existing work system, improving the current one. Subsequently, continuous improvement, so prominent in the Kaizen method, can be applied. However, this is often the most difficult principle to implement. It must be considered whether the system is well designed from the start, to avoid future major problems.
• Improvement through evolution: Kanban discourages drastic structural system changes, which are those that create complexities and uncertainties. It attaches value and importance to smaller ones that generate constant development and evolution. By focusing on a smaller level of complexity, a large number of opportunities can be discerned, which can lead to drawbacks when deciding which processes need to be improved in the first instance.
• Leadership: Fostering leadership within all members of a team or company is an essential element of the Kanban methodology. It consists of ceasing to focus on the management of people and organising the management of the tasks themselves, where the main role is held by the workflow. With continuous improvement and evolution, it is necessary that decision making does not rely entirely and only on the Project Manager, but that the idea of organisational growth is extended to all levels.

To realise the Kanban methodology it is required to apply, check and enhance the following practices:

1. Visualise: You cannot record inventory other than tangibly. Thus, it is necessary to visualise the output, classifying it. Kanban uses a board and stickers. The board would act as the inventory and the cards would be the visual cues to limit the work in process.
2. Limit work in progress (WIPs): To avoid wasting resources and to be aware of the capacity of the system it is important to clarify work boundaries.
3. Manage flow: Bottlenecks or waiting times in systems are a major concern, as they will ultimately dictate the efficiency and effectiveness of the project. It is necessary to have monitoring of work in progress to predicting potential failures.
4. Transparency: Make transparent policies to constrain attitudes and actions throughout the system. These should be modified and improved where necessary. Encourage constructive critical thinking. Respect roles and responsibilities.
5. Feedback: This is what keeps the flow of information alive and allows working boundaries to be re-established. To obtain feedback, meetings are arranged in which evidence is exchanged.
6. Collaborate and evolve: By implementing the Kanban methodology within an already founded system, a progressive evolutionary process is experienced. It is a collaborative process between team members.

Levels of Kanban in APPPM

Under the extent of the scope, Kanban can be adapted to be able to establish correlations across processes. If Kanban is to be implemented at a high magnitude, i.e. portfolio, it has to be considered that any below-scope changes, either at programme or project level, will affect the workflow in the larger one.

Project

While deploying Kanban within a project context, project managers will assume the responsibility of monitoring the tasks of the team. They are also in charge of positioning the project within a programme. Team members have a very relevant role as they should tackle large areas of the project by breaking them down into subtasks so that the workflow can be easily tracked, whilst performing the assigned tasks. When seeking maximum efficiency within a team, the major focus is often lost, which is why project Kanbans are placed in the first layer. A hierarchical sticker system needs to be created. The cards in a Kanban board are the "children" of the programme cards, the programme being the consequently "parents". When a "child" is started the parents should be placed in the in-process stage.

Program

The programme level is the one that governs the rhythm of work and evaluates the efficiency of the processes carried out at the first level. At the same time, they are the ones that set the tasks to be carried out in the teams. This level is limited by the decisions made at a higher level, which is the portfolio tier.

Portfolio

This would be the third layer or tier. At this level, generally governed by high-ranking and responsible positions, are expected to monitor and analyse the whole system being in charge of making small investments, limiting the workflow and identifying the critical chain or possible bottlenecks. This third level manages the strategic initiatives that encompass all programmes and projects. The capacity of the system must be constantly assessed based on feedback from the lower tiers. The cards employed at this level are the parents of those appearing in the lower tiers.