LeanAgileSolutions.

com

Kanban Software Development

The Just In Time Evolution!

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 LIAB ILITY

In 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.

Acknowledgment
This 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 Contents
Introduction....................................................................................................... 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 Kanban Rule 1: Build in quality from the start Rule 2: Withdraw only what can be worked on Rule 3: Produce only what is needed by the next stage Rule 4: Deliver changes that satisfy the customer demand Rule 5: Focus on continuous improvement Rule 6: Stabilize the process The 6 Primary Design Concepts Concept 1: Kanban Value Stream Mapping Concept 2: Kanban Pipelines for Work Streams Concept 3: Kanban Queues and WIP Limits Concept 4: Kanban Cadence Concept 5: Kanban Reduction and Throughput Concept 6: Kanban Software Engineering The 6 Steps The 6 Practices The 6 Metrics Additional Information

Kanban Software Development Roadmap.............................................................44

TA B L E O F C O N T E N T

Introduction

re 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?

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

Introduction

TA B L E O F C O N T E N T

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 andwork 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,
The most common reasons why agile adoption is hindered are: 1. 2. 3. 4. 5. 6. 7. 8. 9. Lack of upfront planning Lack of documentation Loss of control Lack of predictability Opposition to change Engineering discipline Inability to scale Regulatory compliance Lack of built in quality

Kanban can help with many of these issues.

Introduction

TA B L E O F C O N T E N T

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 todays 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.

Introduction

TA B L E O F C O N T E N T

What Is Kanban?

W
T

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.

What 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.

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

W h a t I s Ka n b a n ?

TA B L E O F C O N T E N T

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.
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.

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.

W h a t I s Ka n b a n ?

TA B L E O F C O N T E N T

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

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.

W h a t I s Ka n b a n ?

10

TA B L E O F C O N T E N T

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.

Characteristics of kanban: 1. 2. 3. 4. 5. 6. 7. Continuous Flow Pull System Flexibility at all times Visual indicator of state Visual alert system Self-directing teams Continual fine tuning

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

W h a t I s Ka n b a n ?

11

TA B L E O F C O N T E N T

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
Benefits of kanban: 1. 2. 3. 4. 5. 6. Prevent over production Reduces waste Minimizes delays Saves resources Focuses on value Optimizes throughput

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

W h a t I s Ka n b a n ?

12

TA B L E O F C O N T E N T

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 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.

W h a t I s Ka n b a n ?

13

TA B L E O F C O N T E N T

Kanban Vs Scrum

W
I

hy 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.

What 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.

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

Ka n b a n V s S c r u m

14

TA B L E O F C O N T E N T

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. Capacity = Story Point Estimates
To-Do Active Done

Backlog

Sprint Planning

Sprint Review

Release

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.

Sprint Cycle 2-4 weeks, Measure = Velocity Drawing 1: Scrum Overview 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.

Ka n b a n V s S c r u m

15

TA B L E O F C O N T E N T

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.
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.

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.

Ka n b a n V s S c r u m

16

TA B L E O F C O N T E N T

Individual work items are pulled through the pipeline until they are done resulting in a continual flow of work into the production environment. Capacity = WIP limits
Ready (WIP) Analysis (WIP) Develop (WIP) Review (WIP) Test (WIP) Done Done Released Released

Backlog

Done

Released

Continual Flow, Measure = Cycle Time Drawing 2: Kanban Software Development Overview 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 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.

Ka n b a n V s S c r u m

17

TA B L E O F C O N T E N T

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 Sprints (time-boxes) used Work is limited for the sprint Priorities not changed in the sprint 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. Pull the work they want to start Kanban Continuous flow, no sprint concept Work is limited for the workflow state Priorities can continually change unless work has already started 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 through the workflow
Kanban Software Development is unique in the following ways: 1. 2. 3. 4. 5. 6. 7. 8. 9. Continuous flow WIP limits Focus on business value Pull work flow system Cycle time measured Just in time releases Specialists or generalists Focus on bottlenecks Engineering are needed delivery practices for JIT

10. Estimates are optional

Ka n b a n V s S c r u m

18

TA B L E O F C O N T E N T

Scrum Estimates needed for planning Cross-functional teams Sprint Team Planning Meeting Roles mandated Late binding measurement as velocity only known at end of sprint

Kanban Cycle time used, estimates are optional Specialist or Cross-functional teams Plan per feature or defect Roles optional Early binding measurement as cycle times are live.

No engineering practices although Feature branching and automation are XP pratices are often combined 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.

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.

Ka n b a n V s S c r u m

19

TA B L E O F C O N T E N T

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 colocated 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 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 selfdirected team.

Ka n b a n V s S c r u m

20

TA B L E O F C O N T E N T

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.

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, Develop value-add features or defects in a continuous flow from start to finish.

2.

Ka n b a n V s S c r u m

21

TA B L E O F C O N T E N T

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. Software 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.

Ka n b a n A p p l i e d To S o f t w a r e D e v e l o p m e n t

22

TA B L E O F C O N T E N T

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.

Ka n b a n A p p l i e d To S o f t w a r e D e v e l o p m e n t

23

TA B L E O F C O N T E N T

The 6 rules of Kanban

The 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 start

When 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.

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.

Rule 2: Withdraw only what can be worked on

To 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

Ka n b a n A p p l i e d To S o f t w a r e D e v e l o p m e n t

24

TA B L E O F C O N T E N T

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 stage

To 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 demand

Kanban 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 Kaizen is a Japanese word functionality.
meaning "to change and make good".

Rule 5: Focus on continuous improvement

Kanban 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.

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.

Rule 6: Stabilize the process

Limiting work in process is the only way to deal with bottlenecks. In all work

Ka n b a n A p p l i e d To S o f t w a r e D e v e l o p m e n t

25

TA B L E O F C O N T E N T

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 selfdirection - a critical success factor for agile development. The visualization of the Kanban board will help provide this transparency and direction.

The 6 Primary Design Concepts

There 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.
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

Concept 1: Kanban Value Stream Mapping

Within a Kanban system work is pulled through a work flow. This work flow is

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.

Ka n b a n A p p l i e d To S o f t w a r e D e v e l o p m e n t

26

TA B L E O F C O N T E N T

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.
50% Defective, x2 times Request Av .20 hr
0.2 hrs

Prioritize Av 1 hr
24 hrs

Analyze Av 20 hr
40 hrs

Code Av 80 hr
120 hrs

Test Av 40 hr
100 hrs

Release Av 2 hr
2 hrs

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.

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.

Ka n b a n A p p l i e d To S o f t w a r e D e v e l o p m e n t

27

TA B L E O F C O N T E N T

Ready To Develop

Analysis

Develop

Test

Release

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.

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.

Concept 2: Kanban Pipelines for Work Streams

In 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.

Ka n b a n A p p l i e d To S o f t w a r e D e v e l o p m e n t

28

TA B L E O F C O N T E N T

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.
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. 2. 3. 4. Fixed delivery dates Emergency fixes High priority/impact Standard changes

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

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

Ka n b a n A p p l i e d To S o f t w a r e D e v e l o p m e n t

29

TA B L E O F C O N T E N T

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 Limits

A 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.
Why limit work in process?

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.

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.

Ka n b a n A p p l i e d To S o f t w a r e D e v e l o p m e n t

30

TA B L E O F C O N T E N T

Ready To Develop

Analysis

Develop

Test

Release

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.
Ready To Develop (6) Analysis (10) Develop Test Ready To 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.

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

Ka n b a n A p p l i e d To S o f t w a r e D e v e l o p m e n t

31

TA B L E O F C O N T E N T

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.
Ready To Develop (2) (5) Analysis WIP Done Develop WIP Done Test WIP Done Ready To Release

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.

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.

Ka n b a n A p p l i e d To S o f t w a r e D e v e l o p m e n t

32

TA B L E O F C O N T E N T

Ready To Develop

(2)

(5) Analysis WIP Done

(8) Develop WIP Done

(4) Test WIP Done

Ready To Release

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.
Ready To Develop (2) (5) Analysis Develop WIP Done WIP (4) Done (4) (4) Test WIP Done Ready To Release

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.

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.

Ka n b a n A p p l i e d To S o f t w a r e D e v e l o p m e n t

33

TA B L E O F C O N T E N T

Ready To Develop

(2)

(5) Analysis WIP Done

Develop Code WIP Done Peer Review Done WIP

(8)

Demo WIP Done

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 Cadence

Cadence 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.

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

Ka n b a n A p p l i e d To S o f t w a r e D e v e l o p m e n t

34

TA B L E O F C O N T E N T

Release 1 #1 #2

Release 2 #3

Release 3 #5 #7

#4

#6

Drawing 3: Kanban Release Cadence 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.

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.

Ka n b a n A p p l i e d To S o f t w a r e D e v e l o p m e n t

35

TA B L E O F C O N T E N T

Deadlines

Ready To Develop

Analysis

Develop

Test

Release

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 Throughput

For 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:

How can work items be reduced? A policy needs to be agreed with the team and managers. For example, 1. 2. Can you help someone? If the answer is no then can you reduce a bottleneck? If the answer is no then can you pull work in to start? If the answer is no then ask a manager. help encourage

3.

4.

Minimum no gold plating Marketable the feature is useable and provides a significant value to the

These rules collaboration.

Ka n b a n A p p l i e d To S o f t w a r e D e v e l o p m e n t

36

TA B L E O F C O N T E N T

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.

Ka n b a n A p p l i e d To S o f t w a r e D e v e l o p m e n t

37

TA B L E O F C O N T E N T

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 Engineering

A 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.

Ka n b a n A p p l i e d To S o f t w a r e D e v e l o p m e n t

38

TA B L E O F C O N T E N T

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.
Branch at end of sprint

Regular Commits

Trunk branch

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).

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.

Ka n b a n A p p l i e d To S o f t w a r e D e v e l o p m e n t

39

TA B L E O F C O N T E N T

Stable branch

Sync regularly with the stable branch

Feature branch

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
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.

Ka n b a n A p p l i e d To S o f t w a r e D e v e l o p m e n t

40

TA B L E O F C O N T E N T

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-toend 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.

Ka n b a n A p p l i e d To S o f t w a r e D e v e l o p m e n t

41

TA B L E O F C O N T E N T

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-byfeature are: 1. 2. 3. 4. 5. 6. 7. 8. Branch early, merge late Sync with baselines daily Smoke test branch daily Build branch daily Test branch before merge Merge a change-set Test after a merge Copy merged changes back to the branch

A developer should always verify a merge has been successful.

Ka n b a n A p p l i e d To S o f t w a r e D e v e l o p m e n t

42

TA B L E O F C O N T E N T

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.

Ka n b a n A p p l i e d To S o f t w a r e D e v e l o p m e n t

43

TA B L E O F C O N T E N T

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.

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 Steps
The 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

Ka n b a n S o f t w a r e D e v e l o p m e n t Ro a d m a p

44

TA B L E O F C O N T E N T

5. Implement any new processes and practices 6. Start using the Kanban Board taking small steps and continually fine tune

The 6 Practices
The 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 Metrics
The 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)

Ka n b a n S o f t w a r e D e v e l o p m e n t Ro a d m a p

45

TA B L E O F C O N T E N T

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 Information
Once 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!!

Ka n b a n S o f t w a r e D e v e l o p m e n t Ro a d m a p

46