AWB - 10 - Kanban

337 Agile White Book – AXA Emerging Markets EMEA-LATAM

Chapter 10 KANBAN

V1.0


Contents WHAT WILL I GET TO KNOW FROM THE CHAPTER? ...................................................................................................................................................... 340 THE KANBAN PRINCIPLES ..................................................................................................................................................................................... 341

PRINCIPLES OF THE KANBAN METHOD .................................................................................................................................... 342

GENERAL PRACTICES OF THE KANBAN METHOD ........................................................................................................................ 344

WHERE TO USE IT ................................................................................................................................................................ 347

WHAT IT TRIES TO SOLVE ...................................................................................................................................................... 348

WHAT IT IMPLEMENTS ......................................................................................................................................................... 349 WHERE TO START ............................................................................................................................................................................................ 350

HOW TO CREATE A KANBAN BOARD ........................................................................................................................................ 351

KNOW LEAD TIME AND CYCLE TIME ....................................................................................................................................... 353

SET A LIMIT ON WORK IN PROCESS .......................................................................................................................................... 354

MEASURE YOUR LEAD TIME AND CYCLE TIME .......................................................................................................................... 357

DEFINE EXPLICIT PROCESS POLICIES ......................................................................................................................................... 359

MANAGE THE DIFFERENT KINDS OF WORK ................................................................................................................................ 361 UNDERSTAND THE KANBAN, SCRUM & SCRUMBAN DIFFERENCES ............................................................................................................................... 362

PLANNING .......................................................................................................................................................................... 362

ESTIMATION ....................................................................................................................................................................... 363

PRIORITISATION .................................................................................................................................................................. 363

ITERATIONS ........................................................................................................................................................................ 364

TEAM SYNCHRONIZATION ..................................................................................................................................................... 364

RETROSPECTIVES ................................................................................................................................................................. 364

ROLES ............................................................................................................................................................................... 364

VISIBILITY ........................................................................................................................................................................... 365 EXAMPLES .................................................................................................................................................................................................... 366 TAKE AWAY .................................................................................................................................................................................................. 368


Kanban

Kanban is a management method for improving

service delivery in an evolutionary approach. It uses

boards to visualise the products creation flow

through its different stages. It is oriented to

continuous delivery and Just-In-Time production.

Kanban implements a “pull” system based on each

stage capacity and it increases flow by limiting work

in progress.

Kanban enables people to collaborate in a more

efficient way and emphasises on improving the

process by continuous learning. It enables you to

identify the areas that need improving to focus your

efforts, applying small changes (evolutionary

change).


What will I get to know from the chapter?

KANBAN TECHNIQUES

I know the benefits of visualising processes in a Kanban.

I know how to use the Kanban techniques.

I know what to do to improve the system.

LEARN TO

VISUALISE THE

CURRENT

PROCESSES FLOW

KNOW HOW TO

IMPLEMENT A

KANBAN

KNOW

HOW TO

ESTABLISH

RULES

LEARN HOW TO

IMPROVE & USE

WITH OTHER

FRAMEWORKS


The Kanban principles Kanban uses a set of Visual Management techniques that help you see, “touch” the process flow and define a set of rules to improve the way that work is done. It uses a physical board plus cards that are moved -following some clear policies- across the columns in order to reach a result.

Kanban is not a development life cycle or project/service management methodology but a method that can assist you with product development.

It is a widely used tool for incremental, evolutionary maintenance and systems changes; many times used when things cannot be predicted but must be solved as soon as possible.


The Kanban principles

PRINCIPLES OF THE KANBAN METHOD

I have found that Kanban allows people work better as they agree on 4 principles:

1. Start with what you have

2. Agree to pursue incremental, evolutionary change

3. Respect the current process, roles, responsibilities & titles

4. Encourage acts of leadership at all levels in your organization

Start with what you do now

This method does not require you to change your current process. It is the only method from the Agile community that takes this non-disruptive, evolutionary approach. There is no engineered change to a new process but an evolution of the current process based on collaborative improvement.

Agree to pursue incremental, evolutionary change

Everyone agrees on a slow, gentle, evolutionary, iterative approach. Maybe because the context or the politics make it too risky to try a more disruptive change; or maybe another approach has already failed or encountered resistance.


THE Kanban principles

Respect the current process, roles, responsibilities and job titles

Preserve everything the organization does that already works. We eliminate

initial fears by agreeing to respect current processes, roles and responsibilities. This

agreement often facilitates obtaining support to the Kanban initiative.

Encourage acts of leadership at all levels in the your organization

Improvement requires strong leadership. This leadership can come from every

level in the organization. A culture of safety must exist to encourage individuals to

push change.


THE KANBAN principles

GENERAL PRACTICES OF THE KANBAN METHOD

I have found that Kanban allows people work better as they agree on 6 core practices that also you can follow:

1. Visualize the workflow

2. Limit WIP

3. Manage Flow

4. Make Process Policies Explicit

5. Implement feedback loops

6. Improve Collaboratively

Visualize the workflow

Representation of the current process. Teams use a Kanban board (often a whiteboard or electronic board) organized into columns, each one representing a stage in the process; and optional rows for splitting among different types of work, for example Classes of Service (to be managed under different priorities).

Visualization and understanding of the work, workflow and business risks by everyone involved. The Kanban board indicates where each piece of work is in the process in context of each other, and let the team identify queues, bottlenecks, business risks and even lack of workload promoting collaboration. It seeks to make the invisible, visible. When something is seen, it is easier to identify a problem and come up with a solution. This is especially true with a process that cross different specialities or areas; everyone can have a slightly different idea about what it entails and what are the current cross impacts and dependencies if flow is not visually represented.

Real-time depiction. The board is updated by team members as work proceeds, and blocking issues are identified during daily meetings.



Limit WIP

Work in Progress (WIP) limitation. People should focus on finishing things and understand and agree on it, instead of starting many things or committing to too much work at once. By limiting unfinished items in the process stages, you can reduce the time it takes for them to travel through the system and increase overall productivity of the team. As queues are visualised, people start identifying the roadblocks and proactively working on them. In this way you also avoid inefficiencies caused by task switching and reduce the need to constantly reprioritize items.

Single-piece-flow. Continuous delivery and Just-In-Time is achieved by implementing a pull system. When an item is finished, the next highest priority item is pulled (instead of pulling batches as would be a Sprint Backlog) if there is available capacity within the stage WIP limit.

Manage Flow

Flow analysis based on Lead Time (LT) and Throughput. Lead time measures the duration from the moment something is conceptualised or enters the system until it is delivered. Improving the system from an overall and shared perspective, in order to reduce the Lead Time, increase throughput and smooth the flow, increases the ability to frequently deliver value as well as predictability, which is minimizing risks by expectations misalignment and helps build trust with stakeholders.

Make Process Policies Explicit

Explicit rules are followed for moving a card. Strict “process policies” are established in order to objectively define which things are expected or should happen when moving a card. Explicit understanding enables discussions about how process improvement to be rational, empirical and objective rather than emotional anecdotal or subjective. This approach often leads to consensus around improvement suggestions.



Implement feedback loops

An evolutionary process requires feedback loops. A feedback loop takes the outcome of the process into consideration and routes it back as an input forming a circuit. The purpose of these loops is to compare the expected outcome to the actual ones and make adjustments to the process. When Kanban is implemented at an organization level four specific practices for feedback are used: the standup meeting; the service delivery review; the operations review; and the risk review.

Improve Collaboratively

Collaborative continuous improvement process is carried out. People identify impediments and perturbations that uneven flow and challenge WIP limits. They try new approaches and adopt them if they are successful. That is a continuous process and not a one-off, in which also the explicit process policies are expected to be changed for the better. When using Kanban, everyone needs to be fostering a culture of continuous improvement to reach the optimal performance as a Team/department/company, in terms of lead time, throughput, quality, etc.



WHERE TO USE IT

Kanban particularly supports services and projects where the most important thing is continuous

delivery and the time resolution of every single request. And is especially suited for

environments where disruptive change is not desired:

Organizations not allowing disruptive change. Since it is the only method from

the Agile community not requiring changes to current process, roles and

responsibilities it is very convenient for organizations where such a change would be

too risky or where a more disruptive approach is not possible or desired.

Non-easily schedulable environments - Places where there is no defined scope

and there is no anticipation of the work coming. Each day brings a new challenge.

For example: operations, systems changes and evolutionary maintenance.

Environments where priorities change very frequently or where is a need to

put order in a chaotic environment- Places where deferred commitment is

desirable because early commitment is causing excessive re-work and wasted effort.

Nevertheless this can be is a signal of lack of good product management before

setting up priorities and it should be improved.

Places where maximum delivery flexibility is required – For example when

you can’t wait to specific times to "package" requests (if that was the case, Scrum

would be more suitable). In these places, the development start of a request and its

release are initiated as soon as possible (but always considering Kanban principles

and rules as pull, WIP limits, explicit process policies, etc.).

The workflow system (and its workers) are overburdened – There is too

much WIP, multi-tasking, task switching and queues of requests waiting to be

serviced which lead to stressed workers, poor quality as well as long and

unpredictable lead times.


Three threats are generally found in systems

which erode productivity: blockings,

concurrence and unordered activities.


WHAT IT TRIES TO SOLVE

Kanban as a pull system tries to solve the following things:

o New request are taken only when there is capacity for working on them (not overburdening workers), by priority order of the requests signalled as ready to be pulled.

o In this way it minimises overproduction and waiting time of not finished items as well as rework of systematic defects.

o It also defers to take prioritization decisions until the last responsible moment (Just-In-Time).

Kanban helps maximizing the Team’s productivity by reducing queues in a workflow and

makes sure that everyone is focused. A Kanban board easily communicates priorities, flow information and blocks in a visual way, the board indicates the work to be done.

Kanban uses visual management to make it easy to identify blocks and queues and to reduce them.

In order to reduce concurrency and multitasking (which increase effort and time), Kanban limits the number of items that can be in a process stage. That supports the idea of helping maximise productivity and efficiency by focusing on the current thing to do.

Clear process policies are defined and made explicit, often by writing them next to the Kanban board. This enables work standardisation and enables a rational and objective approach to continuous improvement that eases reaching consensus.

As you can see, Kanban facilitates collaboration and teamwork, encouraging all people work following the same goals and inspiring others to move in the same direction.


The Kanban principles

WHAT IT IMPLEMENTS

A good thing about adopting Kanban is that it doesn´t mean refitting your existing methods and processes. Kanban provides a way of visualising what you are already doing –without changing it- and then identifying which parts of the current approach impact efficiency and change them. This is way team empowerment and involvement for this identification and solution are key, as they are knowledge workers who struggle everyday with the problems in the trenches.

When using Kanban, we get progressively closer to the Agile approach without any radical change; this facilitates transformation and gradually improves the production process. Kanban enables you to identify the areas that need improving to focus your efforts, applying small changes. It is incremental, evolutionary change.

Kanban is generally adopted with little resistance as it is seen more as a tool for inspecting the current workflow rather than a change itself.

Kanban does not require a change in the processes and the first step is simply by start viewing the current situation and mirroring it in the board. We can use the Deming circle to represent this and the next steps.

The main objective is the continuous learning in order to keep improving the way that work is done and thus provide better and faster service. Kanban unlike Scrum, does not impose a change in the beginning but eventually may be doing something very similar in the end.


WHERE to start

This is what I suggest you when implementing Kanban:

1. Start with the current process. Kanban is based on the concept of evolving the current

process, without radical changes or redesign the initial method of work, so, one way to start would be in compliance with the current process, roles and responsibilities.

2. Follow a gradual and evolutionary change. Continue with those aspects of the

work process that work well and ensure an evolutionary improvement. Do not worry about doing the perfect thing the first time and keep continually experimenting. Remember to truly consolidate what was learnt to avoid a bouncing effect.

3. Assure process transparency. Make sure Teams have all they need to foster self-

organisation and continuous improvement. Kanban provides transparency regarding the process and workflow, queues, blockages even lack of workload.

4. Make sure everyone have the same vision of the overall workflow status (queues,

waiting, lack of workload), inefficiencies and impediments roots to make the work more collaboratively. Discussion of improvements, the consensus and the implementation of actions that lead to the reduction of WIP and thus the Lead Time should be encouraged.


WHERE to start

HOW TO CREATE A KANBAN BOARD

You start by identifying the major stages to be used and draw them in columns. A typical Development Kanban board should look like this:

The Backlog column for example, contains elements to be developed; they can vary but are always in a prioritised state. The one at the top is the next to be developed and cards flow through each column as the different jobs are done. One important thing for you to have in mind is that items are always pulled by a person when she is effectively ready to commit the job. This is known as “pull system” or “on demand”.

Remember that a pull system brings the following advantages:

- The person takes the job on board when is ready (last responsible moment). This allows you to have the best possible and known priority and detailed requirement for the elements.

- Minimise waiting. People can plan on realistic scenarios where no more than the current capacity is used.

- Minimise re-work. As it is taken at the very responsible moment, possibility for things to change or jobs that “are not needed anymore” is reduced.


There is something very clear now which is

that it doesn’t make any sense to

continue sending tasks to a blocked

column! and instead work on unblocking

it in order to create flow (fixing the

current issue and/or improving the system

using causal analysis).

WHERE to start

In order to have an effective Pull System, we advise you split the board in “In Progress” and “Ready” status for each stage to clearly mark the boundaries of when something is prepared to be taken to the next stage or it is still incomplete.

As you would be able to see in the Estimation chapter, the human brain has a fantastic ability to analyse visual information but struggles analysing the data. Placing a Kanban on the wall helps people know what is going on, makes sure nobody forgets important things and finally assists making decisions and keeping everyone aligned.


WHERE to start

KNOW LEAD TIME AND CYCLE TIME

There are two very important concepts to understand in Kanban which are Lead Time (LT) and Cycle Time (CT). Lead Time clock starts when the request is made and ends when it is delivered.

Cycle Time (CT) clock instead starts when commits to work on the request and ends when the item is ready for delivery. As you can see, this is a more technical measure of process capability. Remember that Lead Time is what the customer sees.


The most effective way to deliver faster is to limit work to capacity in order to maintain a continuous flow.

WHERE to start

SET A LIMIT ON WORK IN PROCESS

Once you have drawn the columns, it’s time to set the limits.

Limiting the maximum number of work items in progress at each stage encourages finishing the requests and allows elements flow well as they gain speed and predictability in the global system.

When a good limit is established Lead Time (LT) is reduced. Note that we are pursuing flow efficiency with this method and not resource occupation. A balance between cost of the delay and cost of idle time should be evaluated.

You can also set limits on each sub-state, i.e. the columns from where elements are pulled ("Ready", etc.).


When the right Work In Progress is chosen, you will notice that elements flow smoothly as if they were no limit.

WHERE to start

The "ideal" WIP limit (one that produces the best flow) depends on the project, stage, composition of teams, etc. People generally try a certain WIP limit and go raising or lowering it until finding the right value; an Agile Coach can assist you with this task.

Consequences of high WIP limit

Lead Time (LT) high.

Lead Time (LT) variability.

Increase on "Idle" requests.

Long waiting queues.

Reaction time to blockings increases.

Loss of focus.

Creates more relationships and dependencies (complexity) that finally reduces productivity.

Consequences of small WIP limit

Lead Time (LT) small.

Increase on "Idle" People.

You can start with a WIP limit per stage = 2n-1, where n is the number of full time people working on that stage. The -1 is the reserved capacity to help remove blockages in other stages. This limit also applies to the WIP of the entire system in the event of having a Team where everyone can do almost anything at any stage.


WHERE to start

There is another scenario where a Work in Progress is set but there are urgent jobs that need to be taken on board. In this case, a special emergency swimline can be created to prioritise over the normal flow.

In this case, everyone should understand its impact and what happens when something is added to this row (i.e. high emergency, everyone should stop whatever is doing and solve it, etc.).

This starts to introduce the concept of “classes of service” that will be described in a while.

Emergencies

swimline


WHERE to start

MEASURE YOUR LEAD TIME AND CYCLE TIME

Measuring Lead Time helps predict and plan deliveries and compromising on certain requests. It will also tell the Team and Management how much time they need to finish a certain request. In this way, everybody can understand the measurement of the time spent and there is no need for complicated equations. One chart which is especially useful is a Cumulative Flow Diagram (CFD).

Extract from Kanban vs Scrum. How to make the most of both (Free book) - Henrik Kniber and Mattias Skarin.

On this, the vertical axis contains the number of items/ requests and the horizontal the timeline. The idea is that information is shown cumulatively; the line goes up every time an item is finished in each stage (Test, Development, etc.).

The horizontal space between the blue (Backlog) and the purple (Production) lines represents an approximation to the Lead Time (LT) while the vertical represents how many items not started or finished (Work In Progress) are in the Kanban. This chart can give you important information as it can roughly help you estimate a delivery date.

As a result of that, we can have 3 very important pieces of information:

An approximate idea of how long an item takes or Lead Time(LT).

The number of items that are not finished/started in the system.

An idea of a finishing date if scope is not highly changed.

http://www.infoq.com/minibooks/kanban-scrum-minibook


WHERE to start

We could also triangulate this information with other data, such as team size, changes in the Team, etc., in order to get more valuable information.

In the context of product maintenance, there is often a SLA (Service Level Agreement) in place that defines in which time frame you have, for example, to fix a bug; that time is the same as the Lead Time.


WHERE to start

DEFINE EXPLICIT PROCESS POLICIES

When people are working together, a lot of implicit assumptions and policies are at play. It is normal for individuals have different ideas about what a process involves. This kind of things leads to misunderstandings and ineffective Teamwork, conflicts and more expensive processes.

When using explicit process policies, all actors know and share the same ideas (i.e., “I can add or move a card if certain conditions are met”). This allows people discuss the problems and obstacles and establish a common language and knowledge based on empirical concepts and tangible things.

An example of these policies is the Definition of Done (Read Chapter 4, Agile Requirements for more information) where a list of things needs to be fully checked in order for a requirement to be considered finished. Another is the Definition of Ready which specifies what is needed for an item to be included into the Backlog column (i.e. “all requirements clearly listed”, “clear acceptance criteria”, etc.).


You can start by writing the developer’s Definition of Done and mapping it to a stage on the board.

WHERE to start

As you begin to post policies, Team members generally become curious and open the door to discussion. Remember that explicit policies can also be associated to any stage (column) and even at any sub-status (In Progress, Ready) as long as the Team believes it improves what is produced.

We also see that Policies work to improve the dynamics inside Teams and the combination of Kanban board visualization with them is truly transformative.

There are three things I recommend you to have in mind when implementing explicit process policies:

- Criteria must be demonstrable, verifiable and understood by everyone.

- Writing policies in sticky notes proves useful and easy to change.

- The fewer, the better. Simplicity should be considered at all times. We generally put things there which either proves to be repeatedly problematic or especially important for the Team.


WHERE to start

MANAGE THE DIFFERENT KINDS OF WORK

You can also design a Kanban by having in mind the types of works to be done and the ones that need special treatment/different rules. For that to happen, rows or “swimlines” are added to the board to separate the different criteria. For example:

By type of work / classes of service (emergencies, projects, evolutionary, defects, support) that need a different response time.

By projects.

Works related to areas/departments.

Alternatively and/or in combination, sticky notes with different colours can be used for signalling the need of a different treatment / response time for specific requests. Remember that everyone should understand its impact and what happens when something is in a specific line, so a Kanban legend hanged on the board will also be very useful.


UNDERSTAND the Kanban, Scrum & Scrumban differences As we have seen, Kanban is a technique that helps display the value chain and uses Just-in-time As

we have seen, Kanban is a method that helps visualising the workflow and uses Just-in-time

concepts in prioritizing and Pull to limit work to capacity. Since Kanban is not a development

process or framework, it is sometimes complemented with Scrum principles and practices

to create cadenced control and create synergies among team members. Continuous work

is used along with short iterations for planning (for example once a week).

In this way, Kanban, Scrum, and Scrumban are options that can be used to manage product

development cycles. The three of them emerge from the Agile community and use the Pull

principle. Scrumban combines the pull principle and the work-in-progress limits from Kanban the

iterations from Scrum and allows some amount of unplanned items to pop-up in the middle of the

sprint.

PLANNING

In Scrum for example, Product Backlog items are pulled into to each Sprint. Tasks’

planning is regular and occurs in the beginning of each cycle. Project planning is supported by an

on-going activity called Product Backlog Refinement that takes place during the Sprint.

Kanban instead, does not prescribe a precise replenishment activity thus gives more freedom in

that area. For example, teams can choose to replenish when they run out of backlog items

(demand planning) or when the code or version is released.


A semi-automatic prioritization mechanism can also be used and based on diverse criteria such as:

ROI (business value vs. cost) and strategy factor.

Urgency.

% Effort to spend by type of work (e.g. 80% for new projects, 20% for maintenance and support).

% Effort to spend per project or product.

Stakeholder or person who asked for it (i.e. CEO, etc.).

UNDERSTAND the Kanban, Scrum & Scrumban differences

ESTIMATION

Relative estimation is a commonly used Agile technique to determine the time required to finish a

requirement/request/item. In Scrum, the estimation of the time required for the items to be

completed is done in the Product Backlog Refinement and reviewed in the beginning of the

Sprint. As there is a cycle, it is important that items are shorter than the time allocated for the

time-boxed cycle.

In Kanban, items are not estimated –as a rule of thumb- items should be small and of a

similar size (split them if needed) in order to achieve a smooth flow, easily predict

behaviour and times. Instead of predictive estimation, Kanban uses probabilistic forecasting. It

uses historical data to model the expected capabilities and build a probabilistic forecast of the

project outcome.

PRIORITISATION

In Scrum the prioritisation is done by the Product Owner based on many parameters (Business Value, risk, etc.).

In Kanban, you can still use this role and/or the Service Owner role, who is a person or committee of prioritization who reflects the needs of all stakeholders and petitioners. They can meet weekly at the board and decide what requests are prioritized for a specific week.


Kanban allows adding new items or reprioritise

them whenever WIP limits and system capacity is

respected. Therefore, Kanban is very useful for

functions with Just in time and continuous

flow.


ITERATIONS

In Scrum, an iteration is the heartbeat of product lifecycle and define how new items are added to

the iteration. In Scrum, it is discouraged to add new items during the Sprint. If there is a

new item, it is better to wait until the next Sprint in order to be developed. If the project also

requires dealing with some unpredictability (e.g. support or emergencies), it is generally a good

idea to use Scrumban. But if there is a lot of unpredictability or continuous need of

reprioritizations, the best option is to use Kanban.

TEAM SYNCHRONIZATION

Scrum uses certain fixed meetings plus a synchronisation meeting called Daily Scrum.

Kanban can also benefit from a similar daily meeting but starts analysing blocks at the rightmost side of the board, where there is the highest value (nearly finished work) and where to create more capacity for pulling. This is why it is recommended to use magenta sticky tags to signal blocks and their causes. In Kanban there is a further focus on identifying the queues between stages and possible "bottlenecks" in the workflow.

RETROSPECTIVES

One core Scrum practice that can be lost in a Kanban transition is the retrospective, as learning and corrections look more to be a “Just-in-time” process. Kanban does not prescribe regular meetings for process improvement, but you should make sure that frequent process improvement activities are carried out in order to improve the way that things are done (a core practice of Kanban).

ROLES

In Kanban there is no role definitions as it uses the current roles in the organization. You can still use the same roles as in Scrum or define different ones. Nevertheless, it helps a lot when using the Kanban Method to have someone focused on process improvement.

Remember that full responsibility from people involved is required to make sure that the Kanban is updated..



VISIBILITY

Regardless of the approach you use, it is a good idea to provide as much visibility as possible having in mind that the key performance metric in Scrum is the burn-down chart and the cumulative flow diagram and others related to the Lead Time (LT) in Kanban.

These are some ideas of the charts that can be created:

Charts & Metrics

Cumulative Flow Diagrams.

Throughput by type of work.

Dedicated effort by type of work.

Product Backlog Burndown per project, etc.

Diagrams

Architectural maps, models, product maps.

Calendars

Release calendars or Roadmaps.

Vision, medium-term goal or purpose.

Distinctive Visual Help

Tags to indicate why a card is not flowing (reason for blocking, pausing, etc.), tags for priorities, etc.

Avatars (or name-tags in different colors) for team members to easily identify who is working on what. Note that a maximum number of assignable avatars are an indirect way to limit Work in Progress (WIP).


EXAMPLES


TAKE AWAY

REMEMBER

You can use Kanban to create teamwork between different areas or departments that participate in the value chain (Business, development, operations, etc.).

The more important things to solve at an operative level are blocks and queues, from right to left, in

order to create flow. WIP Limits, Process Policies and even Kanban stages can vary on time as the Team learns.

Process improvement activities should be carried out frequently.

ADDITIONAL RESOURCES

Kanban vs Scrum. How to make the most of both (Free book) - Henrik Kniber and Mattias Skarin. Scrumban - Essays on Kanban Systems for Lean Software Development - Corey Ladas Lean from the Trenches: Managing Large-Scale Projects with Kanban - Henrik Kniberg

Kanban - David Anderson. LeanKanban University

BENEFITS

Start with what you have approach, respecting current process, roles and responsibilities. Continuous delivery and focus on finishing things. Flexibility and Just-In-Time prioritization. Improves the way to work in non-easily schedulable environments. Helps you predict an average response time per request. Reduction of idle time and wasted work (over production, rework of systematic defects), so increasing

productivity. Allows people visualise, understand and share a common understanding and goals. Increases team

focus by shared system overview of priorities, blocks and even lack of workload, so promoting collaboration and teamwork.

Helps to avoid overburden in the workflow system and its workers. Incremental, evolutionary changes. Fosters a mindset of continuous improvement based in visualization

and explicit work standardization.

Easy way of introducing Lean – Agile principles.

http://www.infoq.com/minibooks/kanban-scrum-minibook

http://leankanban.com/

AWB - 10 - Kanban

Technology

Transcript of AWB - 10 - Kanban