Kanban Software Development: The Just In Time Evolution

Kanban Software DevelopmentThe Just In Time Evolution!

LeanAgileSolutions.com

First published in 2012 on www.leanagilesoutions.com.

Copyright © 2012 Lean Agile Solutions. All rights reserved, including the right of reproduction in whole or in part in any form. No parts of this book may be reproduced in any form without written permission of the copyright owner. The author and publisher have used their best efforts in preparing this book and the instructions contained herein. However, the author and the publisher make no warranties of any kind, express or implied, with the regard of the information contained in this book, and specially disclaim, without limitation, any implied warranties of merchantability and fitness for any particular purpose.

NOTICE OF LIABILITYIn no event shall the author or the publisher be responsible or liable for any loss of profits or other commercial or personal damages, including but not limited to special incidental, consequential, or any other damages, in connection with or arising out of furnishing, performance or use of this book.

http://www.leanagilesolutions.com/

AcknowledgmentThis ebook is dedicated to all software development professionals in leadership positions who face resistance to change, who are not afraid to take risks on innovative concepts and who passionately believe that quality, integrity and empowerment are enablers for success. Without these people there would not have been the motivation to write this ebook.

Table of ContentsIntroduction....................................................................................................... 5 What is Kanban?................................................................................................. 8

What are the origins of kanban?How does a kanban system work in industry?What are the characteristics of kanban?

Kanban vs Scrum.............................................................................................. 14 What is Scrum?How is Kanban Software Development different?When is Kanban a better fit?

Kanban Applied to Software Development............................................................22 The 6 rules of KanbanRule 1: Build in quality from the startRule 2: Withdraw only what can be worked onRule 3: Produce only what is needed by the next stageRule 4: Deliver changes that satisfy the customer demandRule 5: Focus on continuous improvementRule 6: Stabilize the process The 6 Primary Design ConceptsConcept 1: Kanban Value Stream MappingConcept 2: Kanban Pipelines for Work StreamsConcept 3: Kanban Queues and WIP LimitsConcept 4: Kanban CadenceConcept 5: Kanban Reduction and ThroughputConcept 6: Kanban Software Engineering

Kanban Software Development Roadmap.............................................................44 The 6 StepsThe 6 PracticesThe 6 MetricsAdditional Information

TABLE OF CONTENT

Introductionre you under constant pressure from changing priorities and the need to deliver frequently? Have you tried other agile methods such as Scrum and found short comings in your environment? Do you work in a regulated industry but have a business need for agility? A

This ebook has been written so that the knowledge and the benefits of implementing Kanban in Software Development can be shared. More and more software development teams are coming under increasing pressure to deliver against demanding commercial and market pressures in today's economy. This requires a focus on business value and the need to deliver that business value on a “just in time” basis.

You may be an IT leader who has implemented Scrum and found short comings in your environment, such as the excessive time spent in team planning meetings, especially if team members are specialists or work in “silos” right now; or you have found that delivering production changes inside a sprint is encouraging your team to take hidden shortcuts to meet deadlines which then impact quality; or your priorities are constantly changing inside a sprint on a daily basis. All of these issues, plus others, are blockers to achieving agility but the good news is that they can be addressed by using Kanban.

The chapter "Kanban Applied to Software Development" will show you the way to implement a Kanban system, a concept that has been around for over 50

Introduct ion 5

1

TABLE OF CONTENT

years but which has only been applied in Lean Manufacturing until recent years. Even if you think implementing “just in time” delivery in your IT organization is too difficult, "Kanban Software Development: The Just In Time Evolution" will provide a route to achieving this goal based on lessons already learned in software development teams. Kanban is a proven industry technique for achieving “just in time” delivery and lowers the resistance to change through it's focus on work flow visualization and“work in process” limits.

Key benefits that can be achieved from implementing the lessons outlined in this ebook include:

• Learn about Kanban including pull vs push, queuing theory, “work in process” limits and “just in time” delivery,

• Recognize the characteristics of Kanban in Software Development ensuring there is no confusion with other agile methodologies,

• Optimize your different classes of service using a risk-based approach,

• Design a Kanban board to enable visualization of the work flow ensuring everyone knows what needs to be done next without having to ask,

• Understand what activities and meetings add value in Kanban Software Development,

• Learn how to prioritize work, communicate these priorities to the team and deal with technical debt,

• Integrate roles within the work flow and deal with bottlenecks on a daily basis,

Introduct ion 6

The most common reasons why agile adoption is hindered are:

1. Lack of upfront planning

2. Lack of documentation

3. Loss of control

4. Lack of predictability

5. Opposition to change

6. Engineering discipline

7. Inability to scale

8. Regulatory compliance

9. Lack of “built in quality”

Kanban can help with many of these issues.

TABLE OF CONTENT

• Use metrics to detect problems early and to aid continuous improvement,

• Reduce stabilization cycles with improved version control strategies.

Each chapter gives short no-nonsense "how-to" answers to your questions and “author's tips” to help you succeed with Kanban.

A software development team in today’s global economy must focus on delivering business value, meeting increasing commercial pressures which are driving the need for "just in time" delivery and “building in quality” ensuring continued business success. Your team and business can achieve agility with Kanban and your customers will thank you for meeting their needs on a “just in time” basis. In the next chapter you will learn about the origins of kanban and you will find the answer as to whether kanban can be applied to software development.

Introduct ion 7

TABLE OF CONTENT

What Is Kanban?hat are the origins of kanban? How does industry use kanban and why? Can kanban be used in software development? In this chapter you will learn how kanban is used in the manufacturing industry, the key characteristics of kanban and the answer to whether

kanban can be used in software development.WWhat are the origins of kanban?In Lean manufacturing kanban is a system of continuous supply of components and parts ensuring that the correct level of supply is produced at the right time by the right people. The kanban system is a visual display of the supply chain showing clearly the state each component or part is in at any state in time but also ensuring that any bottlenecks are dealt with as they happen.

he word “kan” means “visual” in Japanese and the word “ban” means “card”. This means kanban refers to “visual cards”.T

In situations where the supply time is lengthy and demand is difficult to forecast, the best that can be done is to respond quickly to that demand. A kanban

What Is Kanban? 8

2

TABLE OF CONTENT

system can help here. Without a system like kanban that response may be inefficient or ineffective and may cost sales.

The kanban system acts like a demand signal which progresses through the work flow or supply chain (known as the value stream in Lean). This system can be used to ensure that inventory or “work in process” is better managed. In order for a kanban system to be effective there must be rules. An example of a company that has pioneered kanban is Toyota and to ensure the kanban system is successful the following 6 rules are applied and continuously monitored.

• Do not send defective components to the subsequent phase,

• The subsequent phase comes to withdraw only what is needed,

• Produce only the exact quantity withdrawn by the subsequent phase,

• Equalize production with customer demand,

• Kanban is a means to continuous improvement,

• Stabilize the process and understand the root cause of problems.

How does a kanban system work in industry?An example of a kanban system could be a company that assembles widgets. If one of the components needed for the widget is say a custom made component and it arrives on a pallet. There are 100 components on a pallet. When the pallet has only 20 components remaining a kanban card is found, the worker assembling the widget takes the card that was attached and sends it to the component manufacturing area. Another pallet of components is then manufactured and sent to the assembly line. The new pallet arrives just in time for the assembler to continue. A new pallet of components is not made until a kanban card is received again.

What Is Kanban? 9

A kanban system is a “pull” system where downstream activities pull work through a work flow which is known as a value stream.

The value stream forms a series of processes which when, all completed, produce finished components or parts.

A kanban card refers to a “visual card” in Japanese and this card ensures a worker has enough information to start the required process activity.

The kanban board is used to visualize the kanban cards and the value stream.

TABLE OF CONTENT

If this supply chain is scaled then there could be multiple assemblers and multiple pallets being refilled. This is known as production kanban.

Another example of a kanban system is where the kanban system needs to operate like a warehouse. A small stock of every component needed to make the widget is stored in an aisle, on a shelve and within a container in the warehouse. The widget assemblers come to the “warehouse” and pick the components they need. As each component is removed from the container a message is sent to the supplier requesting a replacement. The warehouse may then receive a daily delivery of replacements. This second example is different to the first one as it is used when components are manufactured by a supplier who is not co-located. This is known as withdrawal kanban.

In the previous example a queue is acting as a buffer between the processes, this is the warehouse. This creates a balance between maintaining “a continuous flow” of work (reducing the waste of waiting) and minimizing “work in process” ensuring customer demand is met (reducing the waste of over production).

There are many ways that a kanban system can be implemented and one such example is CONWIP kanban. CONWIP is short for “constant work in process”. Here there is a backlog of parts or containers and as each part or container is made available a kanban card is allocated. Once the kanban card starts traversing the pipeline its start time is recorded. Once the pipeline is completed the end time is recorded and the kanban card is used again for the next available part or container in the backlog. In CONWIP the “work in process” limit is constant for the entire pipeline.

A CONWIP model can also be modified so that “work in process” is constant at the individual stages within the pipeline. It is this model that has the greatest potential for software development and for the purposes of this book this form of

What Is Kanban? 10

The 3 different types of Kanban System in Lean Manufacturing:

Production Kanban signals a preceding stage that a quantity of parts needs to be manufactured.

Withdrawal Kanban signals to the current stage that there is permission to remove a part from inventory and can also alert the supplier when parts need to be replenished.

CONWIP Kanban maintains a constant “work in process” within a pipeline.

TABLE OF CONTENT

kanban system will be known as WIP kanban.

What are the characteristics of kanban?The characteristics of kanban can be summarized by the following 7 points.

• kanban is a continuous flow of work meeting customer demands

The emphasis of kanban is on the smooth flow of work ensuring value is delivered to customers to meet their demand on a “just in time” basis.

• kanban is a pull system, downstream activities pull work from the upstream

A kanban system is known as a “pull” system. In the example above the number of components made for the widgets depends on the customer demand. The customer demand is reflected by the number of Kanban cards flowing through the system. The difference with a “push” system is that a demand forecast is not required for a “pull” system but instead the supply cycle times are monitored and used for forecasting.

• kanban provides flexibility in production

Through the use of queues to limit “work in process” and production kanban ensures that just the right amount of work is produced at any one time. This enables business agility through the ability to rapidly respond to a changing demand.

• kanban is a visual indicator showing work in process

Visualizing work flow and making bottlenecks transparent is a significant benefit that kanban brings to a business. This is a very simple but extremely powerful way of encouraging ownership and knowing the state of a work item without

What Is Kanban? 11

Characteristics of kanban:

1. Continuous Flow

2. Pull System

3. Flexibility at all times

4. Visual indicator of state

5. Visual alert system

6. Self-directing teams

7. Continual fine tuning

TABLE OF CONTENT

having to ask.

• kanban is a visual alert system for handling bottlenecks early

The focus of kanban is on reducing waste and sustaining a flow of work. To achieve this goal queues and “work in process” limits are used to manage the work. Once a limit is exceeded the kanban board will display a visual alert which is then a trigger for a continuous improvement cycle to happen.

• kanban encourages self-directing teams

The visual work flow provided by Kanban encourages teams to be self-directing by providing them with the information they need to perform their work without having to obtain that information from a manager.

• kanban focuses on continuous improvement

When a kanban system is used the team members must be responsible for the processes in which they perform activities. This ensures that fine tuning of those processes can happen.

Overall kanban can provide benefits such as

• Preventing over production and developing business agility

• Reducing waste and minimizing wait times

• Saving resources by streamlining production

There are several kanban models but for the purposes of this book the focus will be on WIP kanban. Can WIP kanban be applied to Software Development? The answer to that question is yes as software development is like a pipeline, “work in process” can be limited and work can be be “pulled” by downstream activities. A

What Is Kanban? 12

Benefits of kanban:

1. Prevent over production

2. Reduces waste

3. Minimizes delays

4. Saves resources

5. Focuses on value

6. Optimizes throughput

TABLE OF CONTENT

key difference is that software is not like a physical part and there will be defects but if quality is “built in” early then Kanban will help software teams to cope with bottlenecks, improve throughput and achieve “just in time” delivery. To avoid confusion with lean manufacturing the application of kanban in Software Development is now known as “Kanban Software Development” (Kanban spelt with a capital “K”).

Why is another agile method needed when we have Scrum? In the next chapter Scrum and Kanban will be compared and the business case for “just in time” delivery using a Kanban system in Software Development will be presented.

What Is Kanban? 13

What is “just in time” delivery?

In manufacturing and distribution “just in time” (JIT) delivery is an approach that emphasizes flexible processes and reduced inventories resulting in reduced costs and increased responsiveness.

JIT delivery covers all of the processes needed for delivery including kanban.

TABLE OF CONTENT

Kanban Vs Scrumhy is another agile framework needed for software development when we have Scrum? In what situations does Kanban Software Development work better than Scrum? In this chapter you will learn how Kanban and Scrum are similar but at the same time are different

and also learn when using Kanban Software Development is a better fit.WWhat is Scrum?Scrum is an agile project management framework that is widely implemented today in software development teams.

n 2008 Ken Schwaber estimated that “75% of those organizations using Scrum will not succeed in getting the benefits that they hope for from it”.I

The sprint cycle is an iterative cycle of about 2-4 weeks (a 2 week cycle is commonly used), in which the actual development of the software is performed. The sprint starts with a sprint planning meeting to discuss what will be done in the current sprint, to estimate the stories using story points or ideal days and then to break work up into tasks. At the end of the sprint the development is

Kanban Vs Scrum 14

3

TABLE OF CONTENT

considered Done.

A sprint is closed with the sprint review meeting where the progress made in the last sprint is demonstrated, the sprint is reviewed, and adjustments are made to the project as necessary. A retrospective meeting is held with the team at the end of the sprint to discuss lessons learned and to agree changes to be implemented in the next sprint. The sprint cycle is repeated until the project is completed. The number of completed story points per sprint is the velocity and as velocity stabilizes it is used to forecast the project completion date.

Key roles that are mandated in Scrum are the Product Owner and Scrum Master roles. A key rule is that the sprint backlog should not be altered during the sprint as this impacts the teams ability to deliver upon commitments.

Kanban Vs Scrum 15

Backlog

Capacity = Story Point Estimates

SprintPlanning

ReleaseSprintReview

To-Do Active Done

Drawing 1: Scrum Overview

Sprint Cycle 2-4 weeks, Measure = Velocity

In a sprint, work is “pulled” by team members and marked as “done” when completed. All work is reviewed in the sprint review meeting and once the work is accepted (and any rework performed) then the sprint can be released.

If it is not possible to complete work items fully at the end of the sprint (technical debt starts to build) then there can be a temptation to add stabilization sprints or other workarounds. This could possibly be a symptom of an environment that is not ready for Scrum or where software development practices need to improve.

TABLE OF CONTENT

The aspects that are common between Scrum and Kanban Software Development are:

• Both are based on Lean thinking,

• Both prioritize work,

• Both involve self-directing teams (the team knows what work to start),

• Both make use of visual boards for communicating status,

• Both have daily standup meetings to communicate status,

• Both are focused on continuous improvement,

• Both use “pull” scheduling for starting work.

Kanban is a pattern that can be easily applied to Scrum but Kanban Software Development can exist by itself just like Scrum and there are a number of important differences which make Kanban Software Development an excellent fit in certain situations.

How is Kanban Software Development different?Kanban Software Development is wider than the Kanban pattern as it includes best practices for achieving just in time delivery. These practices will be discussed in the next chapter.

The main difference with Kanban Software Development is that there is no sprint.

Kanban Vs Scrum 16

If Scrum is already being used in a team then applying the Kanban pattern may provide benefits but if the reasons for applying Kanban are to solve organization issues then implementing Kanban Software Development outside of Scrum is likely to the best approach.

In particular if resource, scope, time and quality constraints can not be balanced within a sprint then it's highly likely that quality will suffer over time. This goes against the principles of agile development and it will damage a software development organization.

TABLE OF CONTENT

Individual work items are “pulled” through the pipeline until they are done resulting in a continual flow of work into the production environment.

Within Scrum there is more of a risk of stabilization sprints where the focus is on resolving defects preventing a release. In Kanban Software Development quality is built in throughout the work flow ensuring a release can happen once a work item is done. This is achieved through test automation and a feature-level branch/merge version control model.

Cycle times for completing the work and lead times for starting the work are continuously measured ensuring delays are highly visible. This is different to velocity as velocity is based on estimated story points. If the story point estimates are not consistent or are not accurate then forecasting will be difficult with Scrum. Cycle time on the other hand can be effectively used to forecast

Kanban Vs Scrum 17

Backlog

Capacity = WIP limits

Done

Ready (WIP)

Analysis(WIP)

Develop (WIP)

Review (WIP)

Test (WIP)

Done Released

Done

Released

Released

Drawing 2: Kanban Software Development Overview

Continual Flow, Measure = Cycle Time Kanban Software Development has a backlog just like WIP Kanban in Lean Manufacturing.

The Kanban board visualizes the work flow with WIP limits set globally or at each stage.

Once work is ready to be started team members pull the work through the work flow resulting in work that is done and is releasable.

Releasable means no stabilization cycles involving bug fixes or addressing partial check-ins of functionality that are not “done”.

TABLE OF CONTENT

completion dates for work items of similar type and size.

A sprint can provide management with “confidence” that the team is working towards a deadline. The absence of a sprint in Kanban can hence create a lot of concern. However, the benefits of using cycle time is that the team's throughput is visible at all times and this is a fact – it is not an estimate. This in itself will generate increased confidence and over time the team can start to commit to cycle times in the form of a service level agreement.

There are also no team wide planning meetings as individual work items are planned as they are scheduled. Additionally prioritization happens often, possibly daily, but this is a quick exercise as only the work that will keep the team busy needs to be prioritized.

All of the differences between Scrum and Kanban Software Development can be summarized in the following table.

Scrum Kanban

Sprints (time-boxes) used Continuous flow, no sprint concept

Work is limited for the sprint Work is limited for the workflow state

Priorities not changed in the sprint

Priorities can continually change unless work has already started

Stories that are the size of the sprint cycle are implemented. A story may be a feature but in most cases a story is a path through a feature.

Stories that provide business value are implemented, known as Minimal Marketable Features. If a feature can be announced on a blog or in a newsletter then it's big enough to add business value.

“Pull” the work they want to start “Pull” the work through the workflow

Kanban Vs Scrum 18

Kanban Software Development is unique in the following ways:

1. Continuous flow

2. WIP limits

3. Focus on business value

4. “Pull” work flow system

5. Cycle time measured

6. Just in time releases

7. Specialists or generalists

8. Focus on bottlenecks

9. Engineering practices are needed for JIT delivery

10. Estimates are optional

TABLE OF CONTENT

Scrum Kanban

Estimates needed for planning Cycle time used, estimates are optional

Cross-functional teams Specialist or Cross-functional teams

Sprint Team Planning Meeting Plan per feature or defect

Roles mandated Roles optional

Late binding measurement as velocity only known at end of sprint

Early binding measurement as cycle times are “live”.

No engineering practices although XP pratices are often combined

Feature branching and automation are key to implementing Kanban

To understand why measuring cycle time and a continual flow of work is favoured it is necessary to appreciate the scenarios where Kanban Software Development is a better fit.

When is Kanban a better fit?Both Scrum and Kanban are agile frameworks and are based on lean thinking. Kanban is more dynamic and is less prescriptive than Scrum (few roles and meetings are mandated) and is a very good fit in the following situations.

• A busy support or sales-driven environment where priorities change on a daily basis.

• In a maintenance environment where staff do not know the application's code base and for that reason cannot estimate with any degree of accuracy.

Kanban Vs Scrum 19

Ken Schwaber stated in 2008 that “Scrum exposes every inadequacy or dysfunction within an organization's product and development practices. The intention of Scrum is to make them transparent so the organization can fix them. Unfortunately many organizations change Scrum to accommodate the inadequacies or dysfunctions instead of solving them”

Kanban Software Development is not a “silver bullet” but it can help organizations make these cultural and process changes by focusing on lean concepts. A team does not need to be self-organizing to succeed with Kanban.

TABLE OF CONTENT

• When the same resource pool is being shared for different service streams such as support.

• Newness of technologies or complexity of work again leading to poor estimates.

• Inability to complete stories inside a sprint leading to reduced or fluctuating velocity which then significantly hinders planning.

• Team taking shortcuts and building up technical debt at the end of each sprint due to an inability to balance quality, cost and delivery decisions possibly due to limited resources or lack of discipline in the team.

• A group of specialists where team-wide planning meetings are wasteful.

• A need to enforce compliance at each stage ensuring work is not started until the downstream activity verifies the output from the upstream activity.

Overall Kanban offers a team a path to achieving “just in time” delivery and agility with less rules than other agile frameworks. This freedom allows Kanban to scale for larger distributed teams working on the same product.

This is not the case for Scrum unless the process is tailored as the focus is on co-located teams of 8-10 staff with dedicated staff performing scrum master and product owner roles. A scrum of scrums can be held but the success of this approach is dependent on each teams situation and agenda. It also means replicating scrum masters and product owners at each site.

For example, one team could be a remote team that is dependent on the other team's knowledge. The team with that knowledge may be too busy to provide effective knowledge transfers. This immediately places the remote team at a

Kanban Vs Scrum 20

Kanban Software Development specifically suits teams that provide multiple services and releases into production environments using the same resource pool or where compliance is necessary.

Software product companies, IT maintenance teams and software development teams in a regulated industry like the pharmaceutical sector will see value being added by Kanban.

A culture that is resisting agile adoption will be helped by Kanban in becoming a self-directed team.

TABLE OF CONTENT

disadvantage which could make them feel threatened if velocity is being compared. In this case having the 2 teams work together as a single team may be more advantageous.

Kanban Software Development is not a “silver bullet” for achieving just in time delivery but if a few basic rules are followed and guiding principles are understood then there is a much greater chance of success. In the next chapter the concepts in Kanban will be applied to Software Development demonstrating just how “just in time” delivery is an achievable goal.

Kanban Vs Scrum 21

The goal of Kanban Software Development is to add business value on a just-in-time basis, and to create the conditions for a team to become agile.

For Kanban Software Development to be effective it must be possible to

1. Divide work into small value-add features that can be scheduled separately,

2. Develop value-add features or defects in a continuous flow from start to finish.

TABLE OF CONTENT

Kanban Applied To Software Development

ow are the 6 rules of Kanban applied to software development? What are the main concepts that need to be understood to implement Kanban Software Development? In this chapter you will learn how the 6 rules for Kanban can be applied to software development, understand the

concepts behind Kanban and learn about the software engineering practices that are needed to enable “just in time” delivery.

HSoftware Development is not like a manufacturing production line as the final product depends on knowledge workers rather than on physical components. So how can a lean concept like Kanban be applied to knowledge workers? This is possible by using the WIP Kanban concept as it focuses on processes and utilises a backlog like other agile methods. Since software development can be viewed as a pipeline it should be possible to successfully use this pattern.

other and Shook (1999) in an article about the Toyota Production System called Learning to See say “Flow where you can, pull where you must”.

If you cannot flow then implement a pull system.R

Kanban Appl ied To Software Development 22

4

TABLE OF CONTENT

However, how do we overcome the argument that lean concepts learnt in manufacturing are just not a fit? We're comparing apples to oranges! A key argument is that the Kanban card represents a physical part or container which has all defects removed before it is “pulled” to the next stage. It is just not possible to remove all defects in software development before functionality moves to the next stage.

At first this would appear to be a significant limitation in the application of Kanban to software development. However, if there is a commitment to building in quality from the start then the concepts in Kanban can be easily applied (queues, work in process limits, continual flow and just in time delivery).

In Software Development downstream processes may still find defects but if lean software development concepts are implemented such as “right first time” then this impact can be significantly reduced. This requires building the software right and performing early testing before the next downstream activity pulls the work.

To understand how Kanban can be applied it is important to understand the 6 rules of Kanban, the 5 concepts needed to design a Kanban system, and the software engineering practices needed to enable “just in time” delivery. Once these rules, concepts and practices are implemented and continuously monitored and improved then it can be claimed that Kanban Software Development has been implemented.


A Kanban card in software development can be considered a “limited guarantee of work” as defects are not all known before work is pulled to the next stage.

To ensure lean thinking is applied a “right first time” approach must be taken whereby a focus is placed on “building in” quality.

Test automation and a solid version control strategy are key to “building in quality” in Kanban Software Development.

TABLE OF CONTENT

The 6 rules of KanbanThe 6 rules of kanban need to be modified slightly to fit for software development teams.

1. Build in quality to ensure zero “known” defects are sent to the next stage,

2. The subsequent stage comes to withdraw only what can be worked on,

3. Produce only the exact quantity of changes withdrawn by the next stage,

4. Only deliver changes that satisfy the customer demand,

5. Use Kanban as a means to achieve continuous improvement,

6. Stabilize the process and understand the root causes as they happen.

Rule 1: Build in quality from the startWhen kanban is used in lean manufacturing the parts are not sent to subsequent stages with any defects. In software development it is just not feasible to know about the existence of all defects but it is possible to apply techniques which will ensure quality is “built in” early and throughout the process. Since the focus in Kanban is on a continuous flow of work enabling “just in time” delivery it is vital that quality assurance techniques are used and are scalable.

Rule 2: Withdraw only what can be worked onTo enable a continual flow of work the downstream activities must only pull the work that they can do. Pulling in too much work distracts the team and can


The 6 rules originate from the Toyota Production System and are a guide to knowing when Kanban has been implemented.

In the Toyota Production System the objective is on becoming a learning environment and reducing Kanban in process. This goal should not be lost when implementing Kanban. Reducing the amount of work items (Kanban cards) that is in process is key to achieving a continual flow.

Completing work is preferred over starting work.

Working smarter is preferred over having more Kanban cards in process.

TABLE OF CONTENT

increase the risk of the team starting more work rather than completing it. By only pulling in work as needed the highest priority items can always be chosen and a steady throughput can be achieved. It is this rule that many teams find difficult to implement.

Rule 3: Produce only what is needed by the next stageTo encourage collaboration and focus the team on throughput it is vital that upstream and downstream outputs and inputs are balanced. If there is over production then work will build up and this will impact throughput eventually as work will not get completed.

Rule 4: Deliver changes that satisfy the customer demandKanban is focused on managing customer demand and for ensuring a continual flow. If too much work is in process then it becomes much harder to meet this demand. To avoid this Kanban places a strong emphasis on regular prioritization and on delivering business value rather than just functionality.

Rule 5: Focus on continuous improvementKanban is about fine tuning the flow of work. By itself it is not a continuous improvement methodology but if implemented with other lean concepts such as Kaizen then the measures provided by Kanban will provide a means to achieving continuous improvement. The thinking needed for Kanban is “always can do better” rather than “if it's not broken don't fix it” mindset.

Rule 6: Stabilize the process Limiting “work in process” is the only way to deal with bottlenecks. In all work


Kaizen is a Japanese word meaning "to change and make good".

The saying “don't fix it if it's not broken” does not fit well with Kaizen as it is all about continuous improvement.

There are 5 main elements in Kaizen: teamwork, personal discipline, improved morale, quality circles and suggestions for improvement.

The Deming Plan-Do-Check-Act cycle (PDCA) is typically followed during Kaizen events.

When implementing Kanban Software Development a Kaizen mindset is required.

TABLE OF CONTENT

flows including a software development pipeline there will always be a single bottleneck. This bottleneck may vary depending on certain variables such as the type of work or the available resources but in general there will always be a bottleneck in the process that needs to be stabilized and improved. The only way to do this is by using queues, setting small WIP limits and adjusting them accordingly. By continually focusing on bottlenecks the team are guided by the Kanban system and over time this can help encourage self-direction - a critical success factor for agile development. The visualization of the Kanban board will help provide this transparency and direction.

The 6 Primary Design ConceptsThere are 6 primary concepts behind Kanban Software Development which need to be understood and implemented.

1. Kanban Value Stream Mapping,

2. Kanban Pipelines for Work Streams,

3. Kanban Queues, Order Points and WIP Limits,

4. Kanban Cadence,

5. Kanban Reduction and Throughput,

6. Kanban Software Engineering.

Concept 1: Kanban Value Stream MappingWithin a Kanban system work is “pulled” through a work flow. This work flow is


A value stream map in a software development organisation can look like the waterfall model. However, Kanban Software Development is not Waterfall 2.0.

The value stream map will show:

• The States

• The Flows

• The Cycle Times

• The Delay Times

To get started with Kanban a value stream map may need to be produced without all of the metrics. These metrics can be added once a Kanban system is being used for a while.

TABLE OF CONTENT

known as the value stream and is basically the start and end of the process that creates business value. The value stream shows the states, the flow of work and the times it takes to complete each state.

Any organization that delivers a set of products or services is likely to benefit from applying VSM. Value Stream Mapping should also benefit teams where processes change continuously or where bespoke products are delivered simply because it can be challenging to establish what the work flow should be like. There is a misconception that value stream mapping will not benefit teams in bespoke situations as the value stream map will constantly change between projects and customers but this ignores the benefits that can be achieved through creating the map in the first instance.

The advantage of mapping the value stream is that it focuses everyone on cycle time and waste. The value stream maps should be reviewed frequently, say every 3 months. This is in addition to the fine-tuning continuous improvement activities required by the Kanban system.

If all work flows in the same direction then it is easy to map the value stream on to a Kanban board. The Kanban board will not display the times to complete each process and in some cases only part of the value stream will be mapped to the Kanban board. For example, the product prioritization process might not be displayed on the board.


PrioritizeAv 1 hr

24 hrs 40 hrs 120 hrs 100 hrs 2 hrs

RequestAv .20 hr

AnalyzeAv 20 hr

CodeAv 80 hr

TestAv 40 hr

ReleaseAv 2 hr

50% Defective, x2 times

0.2 hrs

The value stream map should cover all interactions performed and all interfaces. All of these flows may not be mapped directly on to the Kanban board.

One such example is the prioritisation process. This process is still key for Kanban Software Development but displaying a large product backlog will be of no benefit on a Kanban board.

The Kanban board needs to focus the team on the top priorities. A growing list of backlog items is an undesirable distraction.

TABLE OF CONTENT

A misconception with Kanban in Software Development is that the value stream map can look very similar to waterfall. The waterfall or v-model requires up front design and all work items move into a phase sequentially. This is not the same as a pull system where individual work items are pulled through a value stream. Kanban is not waterfall v2.0!

The next section will explain why it is important to start with understanding the types of services and the team organisation required to deliver these services as a first step to designing a Kanban system.

Concept 2: Kanban Pipelines for Work StreamsIn a software development team, particularly a team delivering multiple services and performing application maintenance using the same resource pool, there will be a need to have several pipelines for the same work flow. These multiple pipelines or streams enable a software development team to be responsive.


Ready To Develop Analysis Develop Test Release

Traditional project management does not focus on the risk of the different classes of services that need to be delivered by a team.

This is where Kanban differers. In Kanban each class of service is optimised within the value-stream and the risk of each service is clearly visible on the kanban cards. For example, colour coding is likely to be used.

TABLE OF CONTENT

There are a number of ways that a development team can be split into streams. For example,

• Emergency fixes (tier 2 support)

• High impact changes (tier 3 support or blockers for new sales)

• New product development

On a Kanban board these streams can be displayed by using “swim lanes” to represent each pipeline. Swim lanes are represented by dotted lines in the diagram below.

In the example above if each stream worked on one feature at a time then the “work in process” would be 3. Plus if the entire flow could be covered by a pair, one developer and one tester, then this pipeline could flow naturally.

In the majority of teams there are capacity limitations and external dependencies


Ready To Develop Analysis Develop Test Release

The prioritization process must support the classes of service ensuring a risk-based approach is taken to service delivery.

For example, a prioritization policy could have the following order:

1. Fixed delivery dates

2. Emergency fixes

3. High priority/impact

4. Standard changes

The rules that are followed will depend on the individual company needs.

TABLE OF CONTENT

such as not enough testers or analysts or reliance on other departments. If these limitations are not considered then staff may be idle at times and bottlenecks will quickly form. The next section describes how these capacity limitations can be addressed by using queues, order points and “work in process” limits to ensure downstream processes are balanced with upstream activities.

Concept 3: Kanban Queues and WIP LimitsA Kanban queue can be considered a buffer which contains prioritised items of work and is used when there are workers performing different jobs, for example developers and testers, or when the same resource performs multiple jobs. It is more efficient to allow work to build up inside a buffer as this helps to ensure a continual flow.

Workers “push” work items to a queue when a workflow state has been completed and workers “pull” work items from a queue when work on the next stage starts. The time it takes a work item to enter the queue and then exit the queue is the process cycle time. The process cycle time is part of the overall cycle time for the work item.

Let's say a development team can code 8 features in parallel but if there is a separate analyst team producing the specifications for these features then how can the upstream work be balanced with the downstream work? How can this be represented if there are a number of development streams but the analysts work across the streams? This can be achieved by adding a queue and setting a queue limit. In this situation the analysts need to work just ahead of the developers so that there is always development work to start. So a possible queue limit is 10. The “swim lanes” on the Kanban board also need to change to reflect the fact that the analysts feed all development streams.


Why limit work in process?

• The team has a limited capacity to do work,

• More work started means it takes longer for work to get completed,

• Context switching costs around 20% in productivity. In other words working on multiple parallel work items is not productive.

TABLE OF CONTENT

To keep a continual flow of work from analysis to development the analysts will need to pull work from the backlog. An Order Point can be used here and in this case after every 6 work items are completed more work items are “pulled” into the analysis stage. This can be represented by having the Queue Limit on the right hand side and an Order Point limit on the left hand side.

The “Ready To Develop” stage in this example is also a queue which feeds the subsequent stages with work. This type of queue works well for a backlog and similarly an Order Point and a Queue Limit can be set for the backlog encouraging regular prioritization.

The next bottleneck in this value stream map example is likely to be the ratio of testers to developers. The ideal situation is a 1:1 ratio as a tester can be paired


Ready To Develop

(6) (10)Analysis Develop Test

Ready ToRelease

Ready To Develop

Analysis Develop Test Release

A small queue which is topped up and prioritised on a regular basis is all that is needed to feed the development team with work.

An order point can be set-up for this queue so that people know when prioritisation needs to happen.

The size of this queue and the order point will very much depend on the availability of the people who have the responsibility for prioritizing work but it should be kept relatively small in size.

TABLE OF CONTENT

with a developer but in most companies this is just not feasible. A buffer like the “Ready to Test” queue could be added between the “Develop” and “Test” stages to cope with this capacity limitation. The disadvantage here is that this queue does not help that much when balancing the work performed by the developers and the testers.

If the developers have started too much work and have not completed enough for the testers then the Kanban system will not alert the team early enough and this bottleneck will only be visible once the testers finish their current work load. An alternative is to add a “Work In Process” and a “Done” queue within the stages themselves.

Once work items are pulled from a previous stage they are added to the WIP queue and as they are completed they are added to the Done queue. In the case of development, once a feature is completed then the developer moves it to the Done queue and the Tester pulls the work across once he or she is ready.

A WIP limit can then be set for the Develop and Test stages ensuring the work between the stages is better managed. The WIP limit typically covers both active and completed work items. For example, if there is a ratio of 2:1 developers to testers and there are 4 developers then the WIP limit for the develop stage could be 4 and for the test stage it could be 2. In reality a developer and tester will typically work on 2 work items – both could be in progress or one could be in progress and the other could be done. So a better WIP limit might be 8 for the Develop stage and 4 for the Test stage.


Ready To Develop

(2) (5)Analysis

Develop

Test

WIP Done Done WIP DoneWIP

Ready ToRelease

Utilisation of staff, “work in process” and continuous improvement are all closely linked.

If staff are 100% utilised on work all of the time then there will be limited time to learn and improve. Burnout and apathy will slowly creep into the workplace.

Once there is no time to learn then there will be limited opportunities to improve. This is an anti-pattern for Kanban Software Development.

Reducing “work in process” is a great way of overcoming the “thrashing” that is seen in so many software development and test teams.

TABLE OF CONTENT

If a shared WIP limit is not desired then it is possible to add WIP limits to the WIP and Done queues. This may be desired if the team are not disciplined in finishing work items.

If the size of work items in a queue varies or if there is a build up of work items in a queue then this will affect the process cycle time. As utilisation of a worker approaches 100% process cycle time increases very quickly and this situation is made worse when there is a lot of variability in the size of the work items in the queue. If a queue contains work items that are all of a similar size the workers can maintain a high-level of utilisation and a steady process cycle time. However, if work size varies significantly then workers will slow down and process cycle time will be significantly impacted. All of these considerations must be monitored on a daily basis and processes stabilized ensuring bottlenecks are understood and addressed.

The example used above to highlight how queues, order points and WIP limits is fairly simplistic. For activities that can flow and where there are few capacity limitations then it is possible to combine stages under a single parent stage. The parent stage will typically have a WIP limit that is shared by all of the sub-stages.


Ready To Develop

(2) (5)Analysis

(8) Develop

(4)Test

WIP Done Done WIP DoneWIP

Ready ToRelease

Ready To Develop

(2) (5)Analysis

Develop

WIP Done Done (4) WIP DoneWIP (4)

Ready ToRelease

(4) Test

When deciding on WIP limits it is important to remember to balance downstream processes with upstream activities.

To get started with WIP limits it is sensible to start small incrementing by 1 periodically to see the effect.

Alternatively Little's Law can be used to calculate WIP limits.

Average work items in the system equals the average arrival rate multiplied by the average cycle time in the system.

This calculation can be applied to the entire Kanban board or to an individual stage or queue.

TABLE OF CONTENT

In some Kanban implementations it may be possible to share the WIP limit across the entire value stream if there are no capacity limitations to be managed. It is always better to flow from stage to stage but where you cannot flow then the next best solution is a pull system.

Once a Kanban system is designed the next stage is to consider how “just in time” delivery can become a reality rather than a dream for a software development team. The next section will explain just why a delivery cadence (or rhythm) is needed in addition to the lean thinking mindset provided by Kanban.

Concept 4: Kanban CadenceCadence is a “rhythm” and in software development regular release intervals are needed otherwise the team do not focus as well on meeting targets and stabilisation issues start to appear in the code base at a rapid rate.

Are these release intervals the same as sprints? The answer is no. There needs to be a regular release cycle to reduce stabilisation issues but a Kanban cycle is not a sprint as the team works to capacity rather than sizing stories to fit within a sprint cycle.


Ready To Develop

(2) (5)Analysis

WIP Done

DoneWIP Done

(8) Develop

Code

Peer Review

WIP

Demo

WIP Done

The meaning of cadence:

• A rhythm in music

• Steps in a military march

• The beat chanted by the oarsman in rowing

As there is no sprint cycle in Kanban Software Development a regular cadence (or cycle) is needed for prioritization, learning and continuous improvement activities. For example,

• Daily or Weekly Triage

• Monthly demo

• Monthly retrospective

• Monthly release

TABLE OF CONTENT

In the example above only the features that are done will be released.

A Kanban board by itself is not enough to achieve “just in time” delivery in software development as it is a knowledge based profession The Kanban system will help instil a lean thinking mindset but learning and communication are also key in achieving this goal. When implementing Kanban Software Development it is important to consider all of these factors. Team meetings will need to be held to encourage communication and it is important not to consider all of these meetings as waste.

In some situations team planning meetings can be considered wasteful especially if work is “pigeon-holed” for specific team members due to the complexity of the work or due to a lack of knowledge transfer within the team. On the other hand, meetings for daily status, prioritisation, knowledge transfer and continuous improvement are discovery meetings and are vital for delivery and improvement. All of these meetings need a regular interval or cadence within the Kanban Software Development process.

To ensure the team remains focused on delivery goals it is recommended that these deadlines are made very visible on the Kanban board.


# 1 # 2 # 3

Release 2 Release 3

# 4 # 5

# 7

Release 1

Drawing 3: Kanban Release Cadence# 6

Is Kanban a methodology or a tool-kit?

A Kanban Board can be viewed as a tool but the concepts behind Kanban take it much further than a tool-kit. The meaning of methodology is “a system of methods followed in a particular discipline”.

Kanban Software Development has taken Kanban further by focusing on software engineering best practices which are needed to achieve “just in time” delivery.

TABLE OF CONTENT

Do stabilisation cycles not go against agile development principles? How are stabilisation cycles prevented? These cycles do go against agile development principles and in the next section the software engineering practices required to overcome these wasteful cycles will be described.

Concept 5: Kanban Reduction and ThroughputFor Kanban to be efficient each work item needs to have a low cost. This can be described as a minimum marketable value, the value that meets the immediate customer or business demand. Within software development care must be taken with any enhancement or new feature as there is a risk that scope will creep. If this happens then throughput will be impacted. To avoid this the focus should be on developing Minimum Marketable Features (MMF). A MMF is characterized by the three attributes:

• Minimum – no “gold plating”

• Marketable – the feature is useable and provides a significant value to the


Analysis Develop TestReady To Develop

Deadlines

How can work items be reduced? A policy needs to be agreed with the team and managers.

For example,

1. Can you help someone?

2. If the answer is no then can you reduce a bottleneck?

3. If the answer is no then can you pull work in to start?

4. If the answer is no then ask a manager.

These rules help encourage collaboration.

Release

TABLE OF CONTENT

company such as increased license sales, cost savings, competitive differentiation, compliance or enhanced customer satisfaction.

• Feature – it is a single feature, not a mini project

An important point to note is that an MMF is not the same as a story or a task. A story is part of a feature or enhancement and by itself it might not provide any business value. Whereas an MMF is a change that could be announced on a companies blog or in a newsletter.

An enhancement or a defect is also considered a type of MMF. Color coding can be used on the Kanban board to identify each MMF type and this has the benefit of increasing the visualization experience. The size of the different MMF's does however need to be monitored continuously as a large variation in size will have an impact on the cycle time. Initially this will probably not be the most urgent consideration when implementing Kanban Software Development but it needs to be considered over time.

Ensuring a consistent size for each MMF is only one small way to improving throughput. The best way to increase throughput in a Kanban system is to minimize the amount of Kanban that is “in process”. Kanban is the number of work items “in process” at any time. So how can this be achieved in a software development team?

Obviously ensuring team members complete work before starting new work is going to help but sometimes this discipline is just not there in a team. In most cases this isn't necessarily a fault of the developer or tester but an underlying cultural or environmental issue. For example, if the team feel that they are rewarded for getting to the code complete state quickly versus completing testing and ensuring a work item is “Done, Done”.


Pair programming is an XP practice that has been around for a number of years; some organisations have seen benefits but many organisations find this idea too expensive and many developer's do not like working on the same code with someone else.

An alternative model is a “feature crew” where 1 or more developers or testers work together on the same feature but on separate tasks.

If there are few capacity limitations work will flow and throughput will be higher.

TABLE OF CONTENT

Another solution is to introduce the concept of a Feature Crew. This could be a pair of developer's working on different stories in the same MMF and also testing each others work. It is not necessarily pair programming. Or it could be a developer and a tester working together. This works by having the “feature crew” perform as many stages in the value stream as possible ensuring that work can flow and that only one MMF is worked on by the the “feature crew” (this MMF could also contain multiple defects in the same functional area). If work flows then work does not need to be pulled and fewer capacity limitations need to be managed. Another benefit of this model is that it encourages collaboration and is particularly effective in organizations where staff work in “silos”. This is an ideal solution but it may be too expensive for most organizations.

Another waste that can be reduced is the unnecessary stabilization cycles at release time and in the next section a number of software engineering practices will be discussed that will help achieve the goal of “just in time” delivery.

Concept 6: Kanban Software EngineeringA big challenge in achieving “just in time” delivery in software development is reducing the wasteful release stabilisation cycles. These are the regression test/fix cycles that appear when it is time to release. Many of the stabilisation issues are caused by partial incomplete check-ins being in the code when a release needs to be made. In Kanban Software Development there needs to be a continuous flow of work but the stability of the code base is vital if “just in time” delivery is to be obtained. The solution to this problem is a branch-by-feature version control model (or a promote-by-feature-stream model if you use a version control system like Accurev). Why is a branch-by-feature model necessary?

Typically the version control model used by teams that use Scrum or other time-


Some mature teams who have implemented agile development utilise solid version control strategies. However, not everyone does. In many teams there are still wasteful stabilisation cycles before a release.

Incomplete check-ins or partial features are the biggest threat to a stable code-base.

This can be overcome by using version branching or version promotion (although more care needs to be taken with promotion models) but the key is to use change-sets so that check-ins can be easily reversed.

TABLE OF CONTENT

box based agile methodologies is to check-in changes on a daily basis into trunk (the main code branch), perform a nightly build and then at the end of the sprint create a branch. If developers write xunit tests for all functionality that they develop and these tests are run nightly then this model will work fairly well. If these tests are not written then code stability and quality will be a major problem.

However, incomplete check-ins are still possible in this model as action is only taken if xunit tests fail. If multiple check-ins for the incomplete feature are performed then it will also be difficult to remove the partial check-ins from the trunk branch without further testing at release time. This will require at least one or more stabilisation sprints before a release can be made: not good for Kanban Software Development.

One solution could be to prevent the developers from doing a check-in until all of their code is peer reviewed and tested but the major disadvantage with this option is that it does not encourage collaboration and the check-in will likely involve merging anyhow: so few benefits for the agile lean enterprise.

A better solution is to use a branch-by-feature model. Here a branch is created for each feature, story or bug; the branch is continually synchronised with the trunk ensuring changes made in the stable branch are included; and then the branch is merged with the stable branch once the work item is done (coding done and testing done i.e. done done).


Regular Commits

Branch at end of sprint

Trunk branch

If your version control system does not provide the support required then consider replacing the tool. The cost of implementing a tool is likely to be lower than having wasteful stabilisation cycles and not achieving the goal of “just in time” delivery. Letting a tool dictate your process is another anti-pattern to Kanban Software Development.

Distributed version control systems like Mercurial make branching and merging so much easier. These tools can be used with central version control systems like Subversion.

TABLE OF CONTENT

Branching-by-feature helps ensure there is a stable branch for the code-base but some additional overheads are introduced by this model. If cost reduction strategies are implemented then branching-by-feature will help enable “just in time” delivery. If a branching model is not used then the costly stabilisation cycles will be difficult to overcome. What are the costs for the branch-by-feature model?

Many teams are afraid of branching and merging as they believe administrative overheads will be increased and there is a perception that a single person will need to be dedicated to administrating version control to handle branch creation and merging. This all depends on the version control tool being used but in general this tends to be a misconception.

Modern version control tools such as Subversion now make branching and merging much easier. When combined with distributed version control tools like GIT or Mercurial then branching and merging is made even easier. Developer's are smart people and after some training they should be more than capable to deal with branching and merging. Merging will take some time to master but if changes are kept relatively small (individual features, enhancements or defects) then the merge overhead will be low.

If your version control system, particularly a centralised system where the


Stable branch

Feature branchSync regularly with the stable branch

Do you have the merging fear?

Many developers fear merging as they view it as painful. The reason why it is so painful is that they do not do it very often and then merging becomes a much bigger job. The more often a developer merges the less painful that exercise is.

Merging is as risky as coding – bugs can be introduced. This should not be used as an excuse for not doing merging as there are clear benefits. If parallel development can be reduced then merging becomes less risky as there are fewer conflicting changes.

TABLE OF CONTENT

branching takes place on the server, has a high cost associated with branching and merging then that cost may just be too high. In this situation other solutions may need to be considered such as a version promotion model, check-in once “done done” etc.

The next cost that needs to be considered is the testing cost. If testing is performed after the software has been developed and merged as a distinct stage in the value stream then the impact on branching is negligible. However, we will not have solved the code stability issue. A better approach is to perform the testing early and continue testing whilst the code is being developed. This testing needs to be performed against the build produced against the feature branch. The problem arises when extensive manual tests for new functionality and regression tests need to be run. These test suites will need to be executed at least 2 times: once whilst the feature branch is alive and once when the feature branch is merged. A risk-based approach can be taken on the final QA check after the merge but there is still overhead in duplicating the execution of manual tests.

Automated testing is needed to solve this problem. Manual tests are still necessary but a balance needs to be found with using automated tests to speed up the testing cycles. An automated test tool is also likely to be required as executing xunit tests are not a replacement for GUI or message-oriented end-to-end system tests.

Peer reviews are also an effective technique for verifying quality. In Kanban Software Development the preference is on using automation rather than just relying on visual verification and to also ensure that work flows with minimal bottlenecks. With code reviews resources tend to become bottlenecks very quickly. There are ways around this such as not including the person performing the architect role in a feature crew and ensuring the code review is a stage within


Test automation is key to achieving “just in time” delivery in software development.

Test driven development (TDD) is an approach where by a junit or nunit test is written first, it fails, and then the code to make it pass is written. The focus is on a simple design.

TDD requires a significant mindset change. Other factors hindering TDD is if a legacy application is being maintained. If TDD can be achieved then this is the ideal situation. However, TDD is not a replacement for end-to-end system tests and for these tests an automated test tool is likely to be needed.

TABLE OF CONTENT

the work flow.

How should the branch-by-feature (or promotion-by-feature) model be used? A key lesson in using a feature branch is that the merge with the stable branch needs to happen as late as possible. If the merge happens before testing then there will be an issue around where rework is performed and again this means that incomplete work is on the stable branch. One approach is to follow these steps.

1. Branch from the stable branch early and do this for each feature, enhancement or defect. If there are a group of defects in the same functional area then use a single branch. Take a common-sense approach.

2. Synchronise changes made on the stable branch daily.

3. Smoke test the feature branch daily ideally using automated tests.

4. Perform daily builds on the feature branch.

5. Once the feature is “Done, Done” (code complete and tested), package the changes into a single change-set and merge the change-set with the stable branch. This allows the change-set to be easily reverted.

6. Deal with the merge conflicts and communicate with other developer's if there are any doubts. Copy the merged changes back to the feature branch.

7. Perform a final QA check to verify the merge. The feature is now “Done, Done, Done”.

The only exception to creating a feature branch is if an extremely low impact change needs to be made quickly to the stable branch. This could be a field label


Guidelines for doing branch-by-feature are:

1. Branch early, merge late

2. Sync with baselines daily

3. Smoke test branch daily

4. Build branch daily

5. Test branch before merge

6. Merge a change-set

7. Test after a merge

8. Copy merged changes back to the branch

A developer should always verify a merge has been successful.

TABLE OF CONTENT

that is spelt incorrectly. An explicit “branch or no branch” decision is still required.

Overall the concepts behind Kanban Software Development can be considered stages in adopting the Kanban pattern. These stages may run in parallel but they will more than likely run sequentially depending on the culture and mindset that already exists within a team. The goal in implementing Kanban Software Development is to deliver business value continually whilst building in quality and on the way developing the skills necessary to become agile. In the next chapter a high-level roadmap for implementing Kanban Software Development will be presented.


TABLE OF CONTENT

Kanban Software Development Roadmap

hat steps need to be taken to roll-out Kanban Software Development? In this chapter you will find a summary of what needs to be considered when rolling out Kanban and where to find additional information.W

Kanban Software Development is made up of a simple and a flexible set of concepts and engineering practices that when combined together can help guide teams in achieving agility. To achieve this goal a number of project management techniques must still be used. Implementing a basic Kanban system is not sufficient and by itself could allow poor working practices to evolve.

The 6 StepsThe 6 steps for rolling-out Kanban Software Development will help teams to get started.

1. Gain executive and team buy-in

2. Map the value stream (as-is and to-be)

3. Agree policies, practices and initial WIP limits with the team

4. Choose a physical or electronic board and set-up the Kanban Board

Kanban Software Deve lopment Roadmap 44

5

TABLE OF CONTENT

5. Implement any new processes and practices

6. Start using the Kanban Board taking small steps and continually fine tune

The 6 PracticesThe 6 practices for managing teams using Kanban Software Development will help ensure the goal of “just in time” delivery is achievable.

1. Constantly monitor and adjust (WIP, Bottlenecks, etc.)

2. Frequent prioritization

3. Forecast using cycle time

4. Continuously educate

5. Continuously improve

6. Balance quality and throughput

The 6 MetricsThe 6 metrics that will help a development team focus on the goal of continuous improvement.

1. Average cycle time (development, test)

2. Average lead time (from request to release)

3. Number of bugs found before and after a release (failure demand, technical debt)


TABLE OF CONTENT

4. Average work in process (WIP)

5. Delivery rate (WIP / Average Lead Time)

6. Automation coverage and failure rates (build, acceptance test, unit test, production release)

Additional InformationOnce you have read this e-book, and started to implement the concepts, it is recommended that you continue to grow your knowledge by reading one or more books from the recommended book list. Additional information can also be found at www.leanagilesolutions.com. Good Luck!!


http://www.leanagilesolutions.com/

http://www.leanagilesolutions.com/2012/12/popular-agile-lean-books.html

Documents

Kanban Software Development: The Just In Time Evolution