Kanban in APPPM

From apppm
(Difference between revisions)
Jump to: navigation, search
(The board)
(The board)
Line 75: Line 75:
 
The milestones are explained in detail below:
 
The milestones are explained in detail below:
  
#'''Milestone 1, To-Dos:''' The first phase is the "to do" phase. In this phase, all those activities or processes that have not yet been started are identified. Within this stage, two sub-phases can be distinguished:
+
#'''Milestone 1, To-Dos:''' The first phase is the "to do" phase. In this phase, all those activities or processes that have not yet been started are identified. Within this stage, two sub-phases can be distinguished:The first of these sub-phases is the Backlog. At the beginning of a project, there are high levels of uncertainty that generate complexities. The Backlog includes those tasks that will be carried out in the future, but for which it has not yet been possible to assign a limit or a WIP number. To move a task from the backlog to the next sub-phase, it is necessary to agree on the order of completion according to the urgency determined in meetings.The second sub-phase is the Breakdown. In this phase, the tasks that have been selected from the backlog are divided. Depending on the complexity and resources, a WIP is determined with which the duration of the task and the teams in charge of carrying it out can be visualised. This avoids possible bottlenecks. Once the chart is in this sub-phase, it can be moved to the next major stage, the in-process stage.If you are contemplating a programme or portfolio focused chart, how much a task in a project is divided into should be considered and placed in the same phase also in its major scales.
 
+
The first of these sub-phases is the Backlog. At the beginning of a project, there are high levels of uncertainty that generate complexities. The Backlog includes those tasks that will be carried out in the future, but for which it has not yet been possible to assign a limit or a WIP number. To move a task from the backlog to the next sub-phase, it is necessary to agree on the order of completion according to the urgency determined in meetings.
+
 
+
The second sub-phase is the Breakdown. In this phase, the tasks that have been selected from the backlog are divided. Depending on the complexity and resources, a WIP is determined with which the duration of the task and the teams in charge of carrying it out can be visualised. This avoids possible bottlenecks. Once the chart is in this sub-phase, it can be moved to the next major stage, the in-process stage.
+
 
+
If you are contemplating a programme or portfolio focused chart, how much a task in a project is divided into should be considered and placed in the same phase also in its major scales.
+
  
 
==== The cards ====
 
==== The cards ====

Revision as of 12:08, 20 February 2021

'draft_ by Jesús Gracia Yoldi'


Contents

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[1]. It was introduced in 1947, by Taiichi Ohno, who was an industrial engineer working for Toyota and father of the Toyota production system[2]. It was created to avoid waste, commonly known as Muda[3] 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 [2] . 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.[3].

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:[4]

  • 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. [5]

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:[6]

  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, it is 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.

Applications

The Kanban method consists of cards that are attached to a table or board. The cards serve the function of representing tasks or processes within a project. They move from left to right according to the stage they are in: to do, in progress, testing and finished.The table consists of any structure in which the evolution of the tasks or charts can be captured. Today, everything from sticker boards to virtual platforms is used, all of which are equally valid and effective.

Kanban methodology

The board

Any Kanban board consists of three columns. Each column represents a stage of the project, programme or portfolio process. The columns are used to visually display the workflow. Generally, the columns are divided into further sub-stages to control the WIP, depending on the amount of work or complexity, a higher WIP should be set, and consequently the number of employees to be assigned to that stage.

Any Kanban board consists of three columns. Each column represents a stage of the project, programme or portfolio process. The columns are used to visually display the workflow. Generally, the columns are divided into further sub-stages to control the WIP, depending on the amount of work or complexity, a higher WIP should be set, and consequently the number of employees to be assigned to that stage. To create the Kanban board, the stages must first be discerned and placed at the top of the board. These may contain specific milestones or more general ones depending on the system for which they are being created. The most common are: to do, in progress and completed.

The second step is to divide the project into tasks, taking into account the resources you have to divide them optimally. It should be noted that this procedure is repeated in other projects, program and portfolio management methods.

The third step is to lay out each of the tasks in a charter. These should contain information such as who is performing the task, how long it will take, what previous processes must have been carried out beforehand and a brief description of the task. The content can be freely modified as the workflow progresses or if impediments arise throughout the system.

The milestones are explained in detail below:

  1. Milestone 1, To-Dos: The first phase is the "to do" phase. In this phase, all those activities or processes that have not yet been started are identified. Within this stage, two sub-phases can be distinguished:The first of these sub-phases is the Backlog. At the beginning of a project, there are high levels of uncertainty that generate complexities. The Backlog includes those tasks that will be carried out in the future, but for which it has not yet been possible to assign a limit or a WIP number. To move a task from the backlog to the next sub-phase, it is necessary to agree on the order of completion according to the urgency determined in meetings.The second sub-phase is the Breakdown. In this phase, the tasks that have been selected from the backlog are divided. Depending on the complexity and resources, a WIP is determined with which the duration of the task and the teams in charge of carrying it out can be visualised. This avoids possible bottlenecks. Once the chart is in this sub-phase, it can be moved to the next major stage, the in-process stage.If you are contemplating a programme or portfolio focused chart, how much a task in a project is divided into should be considered and placed in the same phase also in its major scales.

The cards

Benefits

Limitations

References

  1. Rajat B. Wakode Laukik P. Raut Pravin Talmale (2015). Overview on Kanban Methodology and its Implementation . IJSRD - International Journal for Scientific Research & Development| Vol. 3, Issue 02, 2015 | ISSN (online): 2321-0613
  2. Hamzah Alaidaros. Mazni Omar. Rohaida Romli (2020). The state of art of agile Kanban method: Challenges and Opportunities . INDEPENDENT JOURNAL OF MANAGEMENT & PRODUCTION (IJM&P)http://www.ijmp.jor.brv. 12, n. 8, November-December 2021ISSN: 2236-269XDOI: 10.14807/ijmp.v12i8.1482
  3. Project Management Institute, Inc.. (2017). Guide to the Project Management Body of Knowledge (PMBOK® Guide) (6th Edition).(pp. 177).Project Management Institute, Inc. (PMI). Retrieved from [1]
  4. Ohno Taiichi (1988) Toyota Production System: Beyond Large-Scale Production . Productivity Press. p. 176. ISBN 9780915299140.
  5. Ahmad, M. O., Markkula, J., & Oivo, M. (2013, September) Kanban in software development: A systematic literature review. In Software Engineering and Advanced Applications (SEAA), 2013 . 39th EUROMICRO Conference on (pp. 9-16). IEEE.
  6. Gerard Chivas(2020) Kanban Fundamentals, how to start with Kanban at team level . AKTIA Solutions 2020.

Annotated bibliography

Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox