PRINCE2 Agile 2016
Previous Section   Next Section

20.4 Agile concepts and techniques

20.4.1 Kanban and the Kanban method

Kanban is a term that covers the use of Kanban systems, which are visual management systems that limit the number of work items in circulation. This creates what is known as a ‘pull system’. Kanban systems exist in a wide variety of forms, and in the late 1940s Taiichi Ohno employed a system of signal cards to deliver the just-in-time element of the Toyota production system. More recently, Kanban boards (see Figure 20.2) have become commonplace when working in an agile way.

As at Toyota, Kanban is usually applied not only to improve flow in the short term but also to create long-lasting and ongoing change to the underlying processes of the organization. With that in mind, David J. Anderson’s book, Kanban – Successful Evolutionary Change for your Technology Business, documented the principles and practices of the Kanban method, to provide a radical new approach to change management. A strong community has grown around the method, and Kanban in general, and both continue to develop with this evolutionary message at heart. Applicability

The first of the Kanban method’s foundational principles is ‘Start with what you do now’. This means that Kanban should not be regarded as an alternative either to PRINCE2 or to any agile framework. It is better to see it as a way to increase agility through improved day-to-day decision-making (the result of increased transparency), the deferral of commitment (the result of controls on work in progress), and the reduced lead times and increased opportunity for feedback that follow.

Definition: Work in progress (WIP)

Work that has been started but not yet delivered from the system or timebox. It can also indicate the status for incidents, problems, changes, etc.

Kanban becomes applicable with the establishment of a reasonably repeatable workflow. In a PRINCE2 context using agile, this is likely to be found after the project initiation documentation (PID) has been approved and there are discrete work items that can be pulled into a Kanban system. The use of Kanban may then continue after the products have been delivered into operation – a transition that Kanban can help to facilitate.


AXELOS’s ITIL suite of guidance covers all aspects of service management. See ‘About AXELOS’ at the front of this publication for a list of other AXELOS products.

When using any Kanban concept with PRINCE2 and agile it must be remembered at all times that this is in a project context. Many Kanban examples relate to solving wider organizational problems or typical BAU scenarios such as restructuring a service desk. Within a PRINCE2 context many of the Kanban concepts help to create a more agile environment for PRINCE2, particularly with respect to timeboxes of any length, but this does not mean to say that Kanban is being used to run the project. The basics

The Kanban method is made up of six core practices.


By making work visible, teams can easily see how work is progressing, what has been done, what is still to do and what problems exist that are hindering progress. For more information on the benefits of visualization, see section 15.4.2. How the work is physically displayed can vary but it is often a simple grid (or ‘ticket’, see Figure 20.3) primarily showing the different states a work item passes through and information that will help with prioritization and scheduling (e.g. recording risks associated with the work). The information is usually recorded on cards or sticky notes that are typically updated throughout the day.

Definition: Class of service

A broadly defined category for different types of work. The classes influence selection decisions because different classes of service are typically associated with qualitatively different risk profiles, especially with regard to schedule risk and the cost of delay. Four generic classes of service are widely recognized: ‘standard’, ‘fixed date’, ‘expedite’ and ‘intangible’.

‘Swim lanes’ can be added to identify similar types of work or ‘classes of service’. These would be horizontal rows going across the vertical columns.

Figure 20.2 An example of how a Kanban board might look

Figure 20.2 An example of how a Kanban board might look

A ticket can exist in many forms such as the example shown in Figure 20.3.

Figure 20.3 An example of how a Kanban ticket might look

Figure 20.3 An example of how a Kanban ticket might look

Limit ‘work in progress’ (WIP)

Although this is a fundamental concept in Kanban, it appears counterintuitive to many who would be forgiven for thinking that it may slow work down. It is important to understand the reasoning behind limiting WIP as it triggers many events and solves several problems, as illustrated by the following two analogies:

  • Reducing the pressure Introducing reduced speed limits on motorways and highways speeds up the flow of traffic at busy times.
  • Reducing task-switching Writing a document takes much longer (in terms of actual writing time) if the author is receiving email notifications through a desktop alert, or similar, at the same time. Each email notification breaks the concentration and the current thought processes which then have to be ‘reloaded’ and restarted.

The actual WIP limit is usually shown as a number at the top of a column on the Kanban board, and this denotes the maximum number of sticky notes or cards that are allowed to be present in that column at any one time.

The use of WIP limits underpins the ‘pull’ system which characterizes the way Kanban avoids scheduling work at specific times (referred to as a ‘push system’) and instead pulls work from upstream, when the capacity exists to work on it.

Furthermore, limiting WIP reduces the impact of task-switching and multi-tasking. If a team or individual is working on several things at once, a lot of productive time is wasted when changing between them.

WIP limits effectively produce the visual signals that indicate that work can safely be pulled into a place that has the capacity to deal with it effectively. Conversely, the team can respond when the system appears to be at risk of being overloaded.

Manage the flow

A Kanban system aims to achieve the highest level of performance from the existing way of working in order to deliver something of value as quickly as possible. Therefore the team is constantly looking at ways to maximize flow efficiency and minimize delays (e.g. by removing obstacles). Kanban highlights problems that the team needs to solve. This is a constant team exercise where the objective is to remove waste as quickly as possible. The Kanban board visualizes the work moving through the system and acts like a dashboard which enables the team to see blockers and areas where the flow is not smooth. They can then take immediate remedial action.

Making policies explicit

Even though empowerment, self-organization and trust play a significant role in agile, there still need to be clearly defined boundaries that teams operate within. In the same way as management by exception enables empowerment and autonomy, a team needs to clearly define how it works and make these policies transparent. These could be described as ‘rules’ and they create an environment that is more objective for decision-making and where scrutiny may be required. Policies (similar to ‘working practices’ in section 15.4.2) should evolve and be built up collaboratively over time to create a set of guidelines that then become the team norm.

Implement feedback loops

Ultimately, the value being delivered by any process (e.g. a project or a timebox) is judged by the final consumer such as the end customer. Being able to quantitatively assess this is very advantageous as it will directly affect what will subsequently be delivered. Typically there is a long time between a team adding a feature to the to-do list and the team receiving quantitative feedback from the feature being used. Constantly aiming to shorten this feedback loop so that the most valuable work is in the Kanban system is essential in order to deliver the most value (see also section 14.4.1).

The Kanban method contains four types of review to gather feedback (the stand-up meeting, the service delivery review, the operations review and the risk review). The stand-up meeting and the service delivery review can be used within a project context to check what is happening against what was forecast (e.g. for a timebox). Following this, policies can be adjusted as necessary. A risk review can be run at any time to see if there is a pattern to the types of risk that are being identified. The operations review would apply at a higher level than a project (e.g. programme level).

Improve collaboratively, evolve experimentally

The Kanban method embraces the idea that improvement is a collaborative exercise. Its transparency and the ease by which the Kanban system (and thereby the underlying process) can be modified creates the natural conditions for collaborative improvement to occur. The method builds on these advantages in its promotion of experimental improvement.

From observation of the system in action and the capture of key metrics such as lead times and delivery rates, the team is able to form hypotheses of what may be holding the system back and then agree to changes that can be tested experimentally in a safe-to-fail manner.

Definition: Safe-to-fail

A safe-to-fail experiment is one that is designed to have only limited impact on the system or the plan in the event of failure.

This practice implies a significant cultural shift for many – it embraces the concept of Kaizen from Toyota’s culture – i.e. ‘Process improvement is everyone’s business every day!’ There are no process engineers prescribed in Kanban, the point being that everyone focuses on managing the outcome of their process. They see anything that impacts on capability or performance as an issue they themselves need to solve, and not something to delegate to someone else to sort out. Further information


Scrum and Kanban are two of the most popular agile approaches and yet many people get confused regarding the differences between them. They are similar in that they both focus strongly on process improvement, transparency and empiricism. Yet they are different in that Scrum has specific roles, the work is timeboxed and it relates to a specific product; whereas there are no defined roles in Kanban, work is pulled to create a flow and the work may relate to anything.

The very simple structure of Kanban and the fact that it can be applied to any process means that you can apply Kanban to a Scrum environment, although the opposite is not the case. This has led to the creation of a concept known as ‘Scrumban’ – the application of Kanban where the underlying process (the ‘what you do now’) is based on Scrum. In its most limited form this may simply involve the use of Kanban systems to manage the work of the sprint. It is more powerful (and increasingly typical) to apply Kanban to a broader workflow that starts upstream of the build process and ends with customer delivery or even post-deployment validation (e.g. using Kanban at a programme or portfolio level).

Work item size and similarity

Kanban systems are able to deal with multiple types of work and/or classes of service. These are typically indicated as tickets of different colour or by organizing the board into horizontal swim lanes. Within such a category, flow will be more predictable if work items are within the same order of magnitude in size, complexity or risk. This is often achieved by policies on work item size, adjusted where necessary for risk. Over time, teams tend to get less tolerant of larger work items as they learn to recognize their disproportionate risk and develop the skills to identify and deliver value in smaller work items.


When a team looks to improve how the system works in order to deliver more value to the customer, it should do so in a controlled and objective way. There is a lot of data that can be measured and therefore any suggested changes to the way a team is working can be validated quantitatively, empirically and not subjectively. The Kanban method recommends using the ‘scientific method’ to achieve this. The scientific method is a technique for improving understanding and knowledge by going through a process of several steps such as:

  • ask a question
  • carry out research
  • create a hypothesis
  • carry out experiments
  • analyse the results
  • draw a conclusion.

Cumulative flow diagrams

A common technique used in Kanban is to track work items on a cumulative flow diagram (CFD). This shows the amount of work in each column on a daily basis (see Figure 20.4).

Figure 20.4 A cumulative flow diagram

Figure 20.4 A cumulative flow diagram

The spreadsheet on the left shows how many work items are in each area of the system and this is represented on the CFD. Reading the spreadsheet from right to left helps when transposing the data vertically onto the CFD (e.g. on day 15, 13 items had been deployed, none were ready to deploy, 4 were in test, etc.).

Definition: Lead time/cycle time

These two terms are interpreted differently by many in the Kanban community (some see them as representing different things) but in simple terms they refer to how long a work item takes to go through the system or timebox. So although they are often interpreted differently, they are, in effect, the same thing.

Put more simply, WIP is therefore the vertical difference between the line showing work that is ready and the line showing what has been deployed in Figures 20.4 and 20.5, whereas lead (or cycle) time is the difference horizontally between the two, as shown in Figure 20.5.

Figure 20.5 A simple view of how to calculate WIP and lead (or cycle) time

Figure 20.5 A simple view of how to calculate WIP and lead (or cycle) time

Hints that may prove useful

Further to the comments made regarding applicability earlier in this chapter it is important to see Kanban for what it is, and what it offers, and then apply it in a project context in the most appropriate way. A 2-week sprint could be planned (to a degree) in advance with a finite amount of work as per Scrum. Alternatively, the sprint could be unplanned (to a degree) and work could be pulled from a list when necessary as per Kanban. The choice will depend on several factors such as the needs of any particular situation, the agile maturity of the team or the preferred working style of the team. It may be appropriate to not use sprints at all and run a 3-month stage just using a Kanban system.

If work items in a Kanban system are different in size by a significant order of magnitude, such as when comparing a day to a week, or a week to a month, it may be appropriate to use separate swim lanes for these, as these could represent different ‘classes of service’.

Improving flow and delivering value as early as possible (and as much of it as possible) is very much in keeping with the thinking behind flexing what is being delivered. Kanban aims for timeliness and reducing the impact of ‘cost of delay’ (see Figure 20.6) which can be considerable in many organizations: it is often intangible, as it is not measured. The significance of ‘cost of delay’ in a project context using agile is that there is a drive to deliver value as early as possible in some form during the project (e.g. a set of features) and a desire that the final product is not ultimately delayed (e.g. by reducing some of what was intended to be delivered).

Figure 20.6 The effect of delaying the delivery of a product

Figure 20.6 The effect of delaying the delivery of a product

If Kanban is being introduced for the first time to a team or it is being used in a specific way for the first time (e.g. it has already been used for stages but not sprints) then Kanban needs to be implemented carefully and gradually. Wholesale changes to existing processes and working practices (i.e. those used for the previous stages or sprints) should be avoided and the team need to agree to gradually change from where they are now and do it collaboratively.

When using Kanban you should always have WIP limits. If you are not using WIP limits then you may still find the use of a Kanban board useful but this would not represent a Kanban system per se.

Take care when someone mentions that they are using Kanban, because quite often all they are using is a Kanban board. Although this is still beneficial, it is the collective power of all of the Kanban practices that enables it to work at its full potential.

Definition: Little’s Law

L = λW

In simple terms, it is the average number of items in a system. L is equal to the average arrival rate, λ, multiplied by the average time an item spends in the system, W (assuming that this is over a long enough period of time and the system is stable).

Little’s Law is part of the queueing theory body of knowledge and an adjusted version of it is used to understand the flow of work through a Kanban system. If the nature of the variety of work and the dynamics of the Kanban system remain unchanged in the near future, then data from the recent past can be used to forecast the capability and performance of the Kanban system. This is the primary method of forecasting used in project management when using a Kanban system.

The origin of the term

The word ‘Kanban’ is used in both Japanese and Chinese, though with different meanings. In Japanese it roughly equates to a ‘signal card’ or ‘sign/visual board’. It is used in inventory control to signal that a particular level of stock has been reached meaning new stock needs to be ordered or pulled from a supplier. It is a physical card or token (see Figure 20.7). In Chinese, it means ‘looking at the board’. In Figure 20.7, stock is being taken from the front of the box.

Figure 20.7 A Kanban card is used to signal that stock needs to be replenished

Figure 20.7 A Kanban card is used to signal that stock needs to be replenished

20.4.2 The Lean Startup method

A popular agile publication is The Lean Startup by Eric Ries. Lean Startup is a method to grow new businesses, and develop existing ones, through product innovation in uncertain markets. There are many ideas and concepts that can be taken from it that add value when combining PRINCE2 with agile.

The core concepts of Lean Startup that apply to PRINCE2 are:

  • build, measure, learn
  • create a minimum viable product (MVP)
  • fail fast
  • validated learning.

Drawing on an approach to developing businesses may not seem to be an obvious parallel to running a project, or even a timebox, but the way that Lean Startup works is to create a simple approach that can be applied to any situation where uncertainty exists, such as a project.

Lean Startup can be used in part or in whole as a source of techniques because it is like PRINCE2 and agile in that it is product-focused and responsive to change.

Time is of the essence nowadays and the customer wants ‘as much as they can get in as short a time as possible’. They do not want it ‘all in the fullness of time’. A lot of start-up companies are using new technologies, and the pace of change in this area is so fast that they have to use a different management approach, and that approach needs to be an agile one based on the early delivery of value (sometimes this being in the form of ‘learnings’). Uncertainty still needs to be managed

Lean Startup and PRINCE2 both see the need for a managed process even though Lean Startup is geared to handling uncertainty or looking to innovate. To over-plan and forecast too far ahead wastes effort – but so does a ‘just do it’ approach. The same thinking is behind combining PRINCE2 with agile.

The guidance on Lean Startup is included in the context of combining PRINCE2 with agile, as some of the core concepts and techniques in Lean Startup are fundamental to the most effective way to deliver a product at the end of a timebox or a project. Lean Startup focuses on uncertainty, learning and handling change.

It should be remembered that Lean Startup in its entirety is not built for projects or timeboxes. It is included in PRINCE2 Agile as there are many similarities between creating a successful business and running a successful project in an agile context (e.g. a business needs a business plan and a project needs a business case). Applying Lean Startup to PRINCE2

When applying some of the thinking behind Lean Startup to PRINCE2, it should be seen in the context of a timebox. This timebox could relate to the whole project or just a 2-week sprint. Lean Startup is aimed at a group of people, such as a delivery team in a sprint, creating a product where there is uncertainty. This is the context in which Lean Startup is useful to PRINCE2 as a technique.

At the heart of Lean Startup is the idea that in order to be successful there is a need to focus on learning as this feeds into everything a team is trying to achieve. Understanding the customer’s needs and understanding them quickly is vital. The ultimate goals are to get a better understanding of the customer’s needs (bearing in mind that they themselves may not know them) and to speed up this learning. Lean Startup refers to this as shortening or accelerating the feedback loop and this is in keeping with the PRINCE2 Agile behaviour of exploration. Measures and validated learnings

Essential to learning is that feedback needs to be measurable. Even if the feedback is subjective it has to be measurable so that it can be quantified (e.g. an opinion could be measured on a scale from 1 to 10). Lean Startup refers to ‘vanity metrics’ and ‘actionable metrics’. The metrics you need to capture are those that directly relate to the business case or a timebox objective. These would be actionable metrics and not vanity metrics. The latter do not relate directly to the business case.

If a tourist attraction is looking to increase revenue, then:

  • the revenue received during a day is an actionable metric
  • the number of daily visitors is a vanity metric.

How a project is planned has a direct effect on how feedback is received. An early release into operational use of a part of the product will provide feedback. This will have an impact on the rest of the project. The sooner this is received the better. This feedback could turn out to be negative and result in the project being cancelled. Lean Startup is happy with this. If you are going to fail you need to fail as fast as possible (‘fail fast, fail quickly’ – or put another way, ‘learn fast’).

One of the key stories described in The Lean Startup is that of a company that took 6 months to build a product and when they launched it the product failed. If they had released a reduced version of the product after 1 month they would have failed 5 months earlier and saved a lot of money. The key point that Lean Startup makes about this, and it is at the nucleus of Lean Startup, is that the loss of 5 months’ money is not as important as the loss of 5 months of learning. After 1 month they could have responded to what they had learned.

The same applies to a 2-week sprint. It may be early in a sprint that a prototype is made and shown to a customer, and immediately rejected. The learning has already started. Build, measure, learn

The three steps of build, measure and learn apply both to releases and interim products (see Figure 20.8). The most important of the three is the final step to do with learning. This then drives a project forward. In Lean Startup terms, if this results in refinements and adjustments this is seen as positive change and is described as ‘perseverance’ as the solution is becoming more accurate. However, if the feedback is surprising or significant and affects the foundations upon which a timebox was built, or more importantly, the project baseline, this may then need the team to take a very substantial change in direction and probably, in PRINCE2 terms, cause an exception. Lean Startup refers to this as a ‘pivot’ – something major has surfaced and it was not expected.

Figure 20.8 The build–measure–learn feedback loop from Lean Startup

Figure 20.8 The build–measure–learn feedback loop from Lean Startup Minimum viable product in Lean Startup

The concept of an MVP is well known in agile. There are other similar concepts such as minimum marketable feature set (MMFS) and minimum usable subset (MUST) but these are not the same.

The basic idea behind MVP, in Lean Startup terms, is to create the simplest form of the product in order to get feedback. This would typically involve a limited set of features which could then be enhanced throughout the project in accordance with the incoming feedback. However, it is possible that this simple form could also be a paper prototype that could be shown to a customer.

What constitutes an MVP for a project is not easy to define as it depends on the levels of uncertainty that are involved. In very innovative situations it can involve educated guesswork or instincts, but the Lean Startup method forces target measures to be created and then validated as soon as possible by the results.

Definition: Minimum viable product

In a PRINCE2 Agile context, the term MVP broadly aligns with the Lean Startup view that it is a ‘version of the final product which allows the maximum amount of validated learning with the least effort’. This should not be confused with the viability of the project as a whole. Typically, an MVP would be delivered as early as possible during the project.

It is important to note that an MVP is about learning; it may not go into operational use and may be in the form of a simple experiment or prototype.

Lean Startup could be said to view the MVP concept differently from most agile approaches in that Lean Startup assesses ‘minimum viability’ based upon ‘what is the least that can be done to learn’. Put another way, the team needs to learn as fast as possible or ‘learn the most with the least effort’. A common agile view of MVP is about the commercial viability of the product in terms of whether or not it will sell. PRINCE2 Agile does not share this view and defines the MVP based on the Lean Startup definition. Further information

In keeping with Kaizen and continual improvement, Lean Startup sees the need for process when trying to be agile, and the need to continually improve that process. It also sees the need for hard data to scientifically evaluate feedback and learnings. Being flexible and dynamic needs control: ‘ad-hocracy’ will rarely work, even in the volatile start-up arena. This is why the concepts of Lean Startup can be used to complement PRINCE2 as it believes that to be responsive you need control. Hints that may prove useful

Where there is extreme uncertainty (what Cynefin may describe as ‘complex’ – see section 17.4.1) Lean Startup is happy for the MVP to have less than the ideal level of quality: i.e. it may contain defects. Lean Startup is comfortable with this, as part of its learning process is to find out from the customer what level of quality they are happy with. In effect this is saying ‘let’s not guess the quality level – let’s find out from the customer’s feedback’. This level of quality will need to be defined from the start, as it does not represent the quality level being compromised.

Lean Startup prefers to segment the feedback it receives by groups of users or ‘cohorts’. This may not add value if there is a clearly defined user group for a project, but it illustrates why it is important to engage with a representative view of the stakeholders from the customer side. They may have different views on the product or use it in different ways. A single product owner may be a disadvantage if you are using this approach (i.e. segmentation with cohorts).

Lean Startup refers to ‘funnel metrics’ (e.g. How many enquired about the product? How many asked for a demonstration of the product? How many bought the product?). These all represent data that can be learned from to a degree, but the key metrics (referred to as actionable) need to tie back to the business case to validate the original rationale. A twofold increase in demonstrations is not great news if there is no increase in sales. However, opportunities to learn about why the number of demonstrations increased, and to hypothesize as to why they are not converting into sales, now exist.

On a PRINCE2 project using agile that is releasing frequently, these funnel metrics may start arriving during the project and may affect how future work is planned and organized (e.g. features may be reprioritized). Reducing uncertainty

It could be said that Lean Startup is at its best when faced with extreme uncertainty and in a project context this level of uncertainty may only apply to a minority of situations. However, uncertainty will always exist to some degree and will vary from project to project and timebox to timebox. This will in turn affect the degree to which the feedback loops are used: i.e. how many and how often. But the goal remains the same in all situations and that is continual feedback to reduce uncertainty and to understand the customer’s needs as well as possible.

Previous Section   Next Section