Tag Archives: kanban

Boek launch: Scaling agile in organisaties – Wegwijzer voor projectmanagers en agile leads

Tijdens het 20ste BPUG seminar vond ook de launch van mijn nieuwe boek plaats. Altijd leuk zo’n mijlpaal en ondertussen al vele enthousiaste reacties ontvangen. Ook hebben wij, Bert Hedeman, Hajati Wieferink en ik van de gelegenheid gebruik gemaakt om de nieuwe naam van onze organisatie wereldkundig te maken. Het is geen Hedeman Consulting meer maar HWP Consulting om daarmee de complementaire kennis en ervaringen van ons drieën te benadrukken.

20170613_133950

Boek preview

Scaling agile in organisaties gaat over organisaties die stappen willen zetten om teams meer autonomie te geven door besluitvorming decentraal neer te leggen en managementlagen en managers weg te halen om de teams zelforganiserend te laten optreden.

OMS_SCALING_AGILE_v6Business agility (oftewel de vraag: hoe wendbaar is je organisatie) is meer en meer onlosmakelijk verbonden met het bestaansrecht van organisaties. Het snel en accuraat kunnen inspelen op consument- of klantbehoeftes is van levensbelang. Iteratief en incrementeel ontwikkelen biedt betere oplossingen en waarborgen om producten fit-for-purpose te laten aansluiten bij de eisen van klanten; beter dan een watervalaanpak waarbij alle eisen al aan de start gedefinieerd worden en gedurende het ontwikkelproces in principe bevroren blijven.

Vele organisaties hebben stappen gezet om teams meer autonomie te geven door besluitvorming te decentraliseren. Ze hebben managementlagen en managers weggehaald om de teams zelforganiserend te laten optreden. In dit eerste deel komen enkele agile aanpakken van het eerste uur aan bod. Dit betreft agile aanpakken op teamniveau. Daarnaast beschrijf ik wat het betekent als er meerdere teams met elkaar moeten samenwerken.

Kijkend naar zo’n agile team, werkend met Scrum (met voorgeschreven rollen) of Kanban (zonder voorgeschreven rollen), komen de vragen op of er in zo’n constructie met een ontwikkelteam en Product Owner (typische Scrum-rol) nog wel sprake is van een project en of er dus nog wel plaats is voor een projectmanager. Een project is een tijdelijke multifunctionele organisatie, werkend met een start- en einddatum, opgezet om een uniek product of unieke dienst of release van een product of dienst op te leveren, rekening houdend met onzekerheid en onderbouwd door een businesscase, waarbij de juiste mensen voor het projectteam worden gezocht. Er zijn ondertussen verschillende cases bekend van organisaties die alle project- en programmamanagers hebben laten afvloeien en hiervoor in de plaats zijn gaan werken met Product Owners en Scrum Masters.

Zelf ben ik van mening dat het compleet afbouwen van alle project- en programmamanagers een brug te ver is. Wel geloof ik dat het aantal project- en programmamanagers bij veel organisaties sterk kan afnemen, maar er zullen situaties zijn waar toch een beroep op project- en/of programmamanagers gedaan moet worden. Wellicht worden ze dan anders genoemd, maar de rolinvulling zal veel gelijkenis vertonen met die van de project- of programmamanager. Ondertussen word ik gesterkt in dit idee door het feit dat ik organisaties in Nederland toch weer project- en/of programmamanagers zie aantrekken. Hierbij moet ik wel de kanttekening maken dat de opnieuw aangetrokken of overgebleven project- en programmamanagers veel vaker op de relatie zitten (stakeholdermanagement) en dat ze om zaken voor elkaar te krijgen invloed moeten uitoefenen zonder macht te kunnen hanteren.

Dit boek kan dus ook gebruikt worden door meer traditionele projectmanagers die zich een beeld willen vormen wat business agility gaat betekenen voor hun eigen rol. Blijven er traditionele of hybride projecten bestaan (projecten waarbij gebruikgemaakt wordt van zowel tijdelijke als permanente ontwikkelteams en waarbinnen gebruikgemaakt wordt van zowel agile als meer traditionele aanpakken) waarbinnen zij een projectmanagerrol kunnen blijven vervullen? Of is het zinvol dat zij zich binnen de lijnorganisatie meer gaan ontwikkelen in de richting van portfoliomanager, Agile Leader, Integration Manager, Roadmap Manager of Roadmanager, Release Train Engineer, Scrum Master, Agile Coach of Product Owner?

Ik ga in op verschillende agile frameworks die het op organisatiebrede schaal agile gaan werken ondersteunen. Ik schets eerst een handvat om de verschillende agile aanpakken mee te positioneren en vervolgens ga ik in detail in op een aantal van de meest gebruikte frameworks en geef ik een korte introductie van enkele minder gebruikte en minder bekende frameworks.

Ten slotte vergelijk ik verschillende frameworks en sluit ik af met een aantal, soms aan een specifiek framework gerelateerde, aanpakken om een agile framework te implementeren. Verder krijgt u mogelijke valkuilen waar u bij het implementeren van een agile aanpak rekening mee moet houden en antipatronen waar u tegenaan kunt lopen bij het gebruik van een agile framework.

BestellenScaling agile in organisaties

Scrum or Kanban

In one of my previous blogs I wrote about ‘Agility by delivering changes as ‘business as usual’

In that article I showed a picture with different agile methods and frameworks. On the team level I mentioned Scrum, Kanban and DevOps. I came across a blog post from Roman Pichler titled ‘Is Scrum right for your product?’. A nice article explaining when to use Scrum and when to use Kanban, by following a product life cycle from launch via product market fit till the end of life. I added DevOps to his approach in the same product life cycle and will use this to expand my own article. See the animated PowerPoint too.

During the first part of a product life cycle the uncertainty is high and the focus is on goal driven iterations for the first product launch and market fit product. During this part of the life cycle Scrum is a great fit to cope with uncertainty and product iterations developed by the whole team. During the rest of the product life cycle the amount of uncertainty and change gradually declines. Here Kanban is a good fit. User Stories will be realized in a continuous flow by one or more of the individual team members.

When a major product upgrade has to be delivered by the whole team Scrum could be a better choice for that goal oriented iteration, otherwise Kanban stays a good fit.

To avoid the error prone handover and to shorten the time to market the Development and Operations teams can be integrated. Kanban is a good fit for the DevOps team. When to start with DevOps varies.

See: Is Scrum right for your product?

PRINCE2 Agile webinar recordings

Friday February 12th, I gave, on request of Fortes Solutions, the PRINCE2 Agile lecture twice (NL, EN). In total approximately 600 persons registered for these webinars. Due to the webinar system limitations we had to disappoint 150 people. I am sorry for that. The good news is that both sessions are recorded. In these 45 minute lectures I gave a brief overview of the new PRINCE2 Agile framework. The attached picture shows in a glance the overview of this new framework and showing the topics I discussed: PRINCE2 2009 version, Scrum, Lean startup and kanban, the behavior aspects, the usage of the Agilometer and the Cynefin framework as well as fixing and flexing of the six project control parameters.

Dia5

The first recording is my lecture in English and the second one is in Dutch.


If you want to know more about PRINCE2 Agile feel free to enroll for one of our PRINCE2 Agile training classes. The next one will start in April in Hilversum, Netherlands. See: Hedeman Consulting.

Book review: Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software

dblegacy_xlargecoverDavid Scott Bernstein asked me to review his book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software.

Looks like a book for software developers. Can I review this book, it’s 35 years ago that I was a programmer in the pre-OO era? But I started reading and I am glad I did it. There are some chapters (3 practices) with are definitely for the real software developers but the rest of the book is for a much broader audience. The book gives you great insight why so many organizations struggle with the implementation of agile practices and what you have to do to overcome these struggles!

Many organizations want to introduce agile, sent some people to scrum master or product owner training classes and think it will flow. Understanding time-boxes, daily stand-ups, and retrospectives doesn’t make your organization agile. This book shows that this is just a very first step. To fully benefit of agile it will take a software development team at least a year of practice, making errors and learn from them to fully understand e.g. Extreme Programming, pair programming, and Test Driven Development. Or with other words to achieve mastery you need more than skills and ability. You have to follow the three stages of the Japanese martial art Aikido Shu-Ha-Ri: Shu (knowledge), Ha (put theory into practice) and Ri (practice and theory begin to dissolve: highest level of mastery).

The book is divided in two parts. Part I focuses on the legacy code crisis, and part II, the biggest part of the book, gives nine practices to extend the life, and value, of your software.

Part I is divided in three chapters. Chapter 1, Something is wrong elaborates on what happens when:

  • Software is created using the waterfall method resulting in legacy code
  • Software developers have little knowledge of how software is constructed and how software becomes legacy code
  • Batching features into releases.

Chapter 2, Out of chaos questions the Chaos Report definitions from the Standish Group. The author shows that using these definitions you still have no clue if a project is really a success or not. Also the usage of failed (cancelled) projects is misleading. To stop a project is in most cases not a failure, because it is related to external circumstances. But the final conclusion of the Chaos Report – that the software industry has a long way to go – is right. The rest of the chapter focuses on other studies showing that most of software costs are related to inefficiency and maintenance costs and are costing the industry a least tens of billions of dollars a year.

The last chapter of part I, Smart people, new ideas introduces agile to start moving in the right direction. Using daily stand-ups, time-boxes (according to the author better to use scope boxing) is not enough. Continuous attention to technical excellence and good design enhances agility and must be the top priority for the next ten years.

The second part, the core of the book, describes nine practices:

  1. Say What, Why and Whom before How
  2. Build in small batches
  3. Integrate continuously
  4. Collaborate
  5. Create CLEAN code
  6. Write the test first
  7. Specify behaviours with tests
  8. Implement the design last
  9. Refactor legacy code

These nine practices will help you to develop software (or use agile) in the right way. To build bug free software that is simple (and therefore cheaper) to maintain and extend. Or as David stated “Build better / risk less”.

Dia1Every practice is explained with much detail and based on real life examples from David and at the end you will get two key topics with practical strategies to implement these practices. See the attached figure, showing these strategies for all nine practices. You will also get references to books, websites and videos to get an ever much deeper insight in the mentioned topics. To download: beyond legacy code (practices, 150807) v1.0

e.g. a great video to explain the effect of work in progress (WiP, Kanban system) by comparing the highway traffic paterns, by Hakan forss:

Or explaining MOB programming: what does it mean if all the brilliant people working at the same time, in the same space, at the same computer, on the same thing.

To summarize, If you start using agile and understand the agile basics and you want to take the next step to leave ‘agile in name only’ and really want to use the agile way of working, this book is a must read.

On the pragmatic programmers website you can find the code examples as well as a discussion forum. You can also order your copy: https://pragprog.com/book/dblegacy/beyond-legacy-code

Interview with David about his book:

PRINCE2 Agile, a first overview

During the last Gartner PPM Summit, 8 and 9 June 2015, in London, it was confirmed again. “One size does not fit all” is true in the world of projects too. Are reliability and cost the most important or are we going for brand awareness, sales and customer experience? Do we have to deal with long-term or short-term contracts? Is the focus on IT only or enterprise-wide? Are we talking about frequent or a limited number of deliveries within short or long lead times? Many debates we see in the media, PRINCE2 versus Agile, Scrum only but what about governance or the business case? The answer from Axelos is PRINCE2 Agile that combines the best from both worlds to carry out a project properly.

Introduction

PRINCE2 Agile includes both the existing PRINCE2 as the agile way of thinking. The agile way of thinking must be seen as agile behaviour, concepts, frameworks, focus areas and techniques. The existing PRINCE2 principles, processes and themes remain, but should be tailored using the agile way of working and the project itself. PRINCE2 Agile searches for the best of both worlds where the emphasis lies in the use of PRINCE2 within project direction and project management and the agile approach in the product delivery. Depending on the project situation you can apply more or less of the PRINCE2 or agile way of thinking. See Figure 1.

Dia05Figure 1. Mixing of PRINCE2 and Agile

six project control parameters: PRINCE2 uses six project control parameters: time, cost, scope, quality, risks and benefits. All six have their own tolerances. PRINCE2 Agile recognizes the same six project control parameters except that within an agile approach time and cost are fixed (no tolerance), quality and scope can be partially flexible (no tolerances for the essential criteria and products) and the risks and benefits can be fixed or flexible (tolerances in consultation between the project manager and the project board).

The reasons for flexing are explained by the five targets:

  1. Be on time and hit deadlines
  2. Ensure the required quality
  3. Embrace change
  4. Keep the team stable
  5. Accept that the user doesn’t need everything

In the following paragraphs I explain how the principles, themes and processes can be customized to incorporate the agile way of thinking.

Principles

The seven PRINCE2 principles remain. However PRINCE2 Agile adds five behavioural components to it:

  • Transparency – regarding the progress of the project.
  • Collaboration – between the project team members and stakeholders.
  • Rich Communication – consultation over email, visualization over text.
  • Self-organization – empower and facilitate the project team.
  • Exploration – curiosity over obeying the rules.

The processes

Starting up and initiating the project: Make during starting up a project, an initial estimate how far you can go with embedding the agile way of working in the project. To perform this agile risk assessment, PRINCE2 Agile developed the Agilometer. This evaluation must be repeated during the initiation stage and the various stage transitions.

Agilometer: The Agilometer consists of six key areas to be used in the assessment of the application of agile within the project. The six key areas are:

  • Acceptance of agile;
  • Advantageous environmental conditions;
  • Ability to work iteratively and deliver incrementally;
  • Ease of communication;
  • Level of collaboration;
  • Flexibility on what is delivered.

The project manager performs this analysis and looks for each key area for possible or necessary improvements and gives insight how agile the project can be established. So, it’s not a matter of yes or no. It also makes no sense to calculate an average of the six sliders. This Agliometer is comparable with the agile project questionnaire from DSDM.

During Start up and Initiating the project it’s key to find the right balance between the risks associated with the project and the level of detail the issues should be sorted out beforehand. The aim should be to maximize the freedom to steer the project during the implementation of the project. Sometimes within agile they call Starting up and Initiating the Project stages, sprint zero or the discovery phase. The Project Product Description is then referred to as the project backlog.

Cynefin model: PRINCE2 Agile uses the Cynefin model from Snowden to determine the level of uncertainty and thereby what the most logical approach and management of the project. The Cynefin model identifies five domains:

  • Obvious: clear cause-effect relationship
  • Complicated: cause-effect relationship is not clear
  • Complex: cause-effect relationship can only be explained in retrospect
  • Chaotic: cause-effect relationship can’t be indicated
  • Disorder; unclear to which domain the change belongs.

With clear cause-effect relationships there is usually a simple project or ‘business as usual’. Projects we find especially in the complicated and complex domains. The more complex in its environment the more an agile way of working is desirable. If the cause-effect relationship can’t be indicated, then a process approach is the most appropriate approach.

Directing the project: With ‘business as usual’ the product owner directs the agile process. In a project environment, we see the PRINCE2 roles of executive (sponsor), senior user and senior supplier. For simple projects, some of these roles can be merged, e.g. the executive and senior user role.

In all cases it is important that collaboration is based on trust, and that therefore there is no blame culture. Management by exception is than characterized by empowerment and rich communication.

Controlling a stage / Managing product delivery: Within PRINCE2 Agile it is possible that there are no stages but only time boxes, whether inside releases or increments. Releases or increments can also be defined as stages, if at the end of which an explicit go / no-go decision is planned. It is important to plan around the functions (sub-products) and use flexible work packages that emphasize that teams are as much as possible self-organizing, communicating rich and make management by exceptions possible. Focus is on the result to be delivered, so the scope and quality criteria and the control of the agile related risks. The Controlling a Stage is characterized by transparency, collaboration and rich communication, self-organization and flexibility.

To have frequent releases makes it possible to harvest benefits as early as possible, obtain fast user feedback and reduce risk. It provides confidence that the project will deliver and it will help to obtain and retain the stakeholders’ interests. Small releases are often easier to take into production. Of course, the releases needs to be planned so that it is clear when which of the functions (sub-products) are delivered.

Manage a stage boundary: During managing a stage boundary (increments or releases), it is important to assess how much is produced, which what quality and what benefits have been or may be harvest. In addition, an assessment of the agile way of working, and determine if the method used must be adjusted. This corresponds to the retrospective in Scrum. Of course, this step should take place with as little as possible ceremony.

Closing the project: Within agile there is not much described on the formal closure of a project. Usually there are already several interim products delivered. PRINCE2 Agile emphasizes on the following activities that may or may not be conducted in workshop form. Rate the final outcome with respect to the original plan. Agree on the formal user acceptance. Evaluate the process as well as the usage of agile in the project. Finalize the required documentation. Transfer the result formally to the customer.

Themes

All themes within PRINCE2 can be found in PRINCE2 Agile. Some topics are within the agile way of working more important than others.

Business justification: The business case for the entire project is drawn up during Starting up / Initiating the project and updated at the end of each stage. It must also clearly define the minimum usable product, based on the prioritized list of requirements (must-haves). The added value of the individual functions will be prioritized in the different timeboxes. A requested function or feature that adds no value to the organization will not be realized.

Organization: The known roles of executive (sponsor), senior user and senior supplier still exist in an agile project but from a user perspective often expanded with the role of Business Ambassador (DSDM) or Product Owner (Scrum). The Project Manager has a more facilitating role than a managerial role (servant leader). Depending on the self-organizing ability of the development team and the Agile method used, the role of Team Manager can be filled formally, or by a Scrum Master (Scrum), or be fulfilled by the team as a whole. For the Project Manager, it is important that he has at least a point of contact in the team and that in the team someone from the user side is involved (business ambassador or product owner).

If the project consists of only one agile team, then a simple agile approach with one product owner and scrum master suffice. Consists the project of more teams than the different product owners and scrum masters must tune their work and progress (scrum of scrums).

Plan: A project is finite. For each project there must be a planned end date. Therefore you need an overall project plan. This also distinguishes the agile project approach to agile maintenance approach as part of business as usual. The project plan to support the agile approach, however, should be limited to the main topics/functions. It has to be just sufficient to be able to determine the total duration and the total budget, assuming sufficient (flexible) tolerances within the to be requested functionalities. Per increment or timebox the project plan will be more detailed. Within an agile approach the time and cost tolerances are set to zero and the flexibility will be found in the tolerance of the functionalities.

PRINCE2 Agile prescribes no mandatory planning technique and no planning approach. From the agile way of working it is appropriate to establish the project plan empirically in consultation with the project team and set the various timebox plans by the delivery team themselves. These delivery teams can make use of a simple scoring system such as planning poker, or T-shirt planning.

Progress monitoring: As with the PRINCE2, PRINCE2 Agile focuses on the product to be delivered. However, PRINCE2 Agile is less about whether it will succeed to deliver the product as defined within the given time horizon, but how much functionality can be completed within the given time horizon. For progress reporting at project level you can make use of stand-up meetings, information radiators, team boards and visual burn-down or burn-up charts that are used at the team level. In addition agile teams frequently make use of the concept of velocity. This is a measure of the production of the development team in a certain period of time (timebox), with which one can also determine the extent to which a team learns, and hence can realize more in the course of time.

Risk Management: Risk management gets less attention Within PRINCE2 Agile because many project risks are already minimized by the agile approach. But due to a possible discrepancy between the agile approach and more conditioned environment new project risks can be introduced too. In order to identify these risks, the Agilometer is introduced. As a result the project approach can be tailored to accommodate the given situation as showed in the Agilometer. PRINCE2 Agile uses the five behavioural components to control possible project risks too.

Quality: Within PRINCE2 Agile is important to develop a less formal quality management strategy, but you still need to capture it: what and how is tested within the development teams and what, how, and by whom will be tested at the end of the time boxes. Within the Project Product Description we find the description of the needed necessary changes in the organization based on the result to be delivered. Further, the acceptance criteria and the “Definition of Done” are central to the quality theme. Quality criteria of the requested products can be found in the product descriptions on the project level and in the user stories at the team level.

Change management: PRINCE2 Agile embraces change. The more changes, the better the product is likely to be connected to the company strategy and the greater the user involvement, and thus the probability of acceptance of the product. It is important to make a distinction between the changes in the officially fixed configuration (project product description), which should be monitored formally at project level and the further elaboration of that configuration within the development team and user representatives (informal). Adding new parts means that those new parts needs to be exchanged for other less important parts (trading), because there are no time and cost tolerances within agile projects.

Lean start-up: Within the philosophy of embracing change, PRINCE2 Agile also introduces the principle of lean start-up. Lean start-up focuses on learning and act accordingly. Try as fast as possible (fail fast). But take as soon as possible (parts of) products in use, and learn from them. The product that processed most of the learning experiences, usually delivers the most value.

Agile and supplier contracts

Agile in combination with strict supplier contracts remains a challenge for many. Within PRINCE2 Agile this problem is worked out in a clear manner and therefore also provided various guidelines. Useful recommendations are:

  • Focus is on the end result (outcome) and not on the final product (output);
  • Define the level of user participation during the project;
  • Describe, in terms of time, important delivery milestones (sprints and / or releases);
  • Include a clause that the project board may decide to stop prematurely;
  • Take a bonus / penalty clause on the basis of the quantity of delivered end result;
  • Define global requirements and prioritize them. Detailed requirements will ask for too many adjustments during the project;
  • Keep the contract as simple as possible (depends on mutual trust).

Agile Frameworks

PRINCE2 Agile discusses the use of the Scrum and Kanban frameworks and related techniques such as user stories, MoSCoW prioritizing, frequent releases, planning poker and T-shirt estimation extensively.

A Dutch version of this article will be published in due course (IPMA Projectie).

PRINCE2 Agile in one picture

In one of my previous posts I already gave some preliminary facts regarding the new PRINCE2 Agile framework. See: preliminary facts 

In this post you get a simple overview regarding PRINCE2 Agile. This framework is based on blending PRINCE2 and agile together. PRINCE2 is strong in the areas of project directing and project management and agile is strong in the area of product delivery. It’s not a matter to chose between PRINCE2 or agile but to decide how far you can go using specific agile ways of working by tailoring the PRINCE2 approach. The new framework offers the Agilometer to understand how far you can go using agile. Together with the usage of the Cynefin framework created by David Snowden you must have a good view how to blend PRINCE2 and agile.

Dia5

For the PRINCE2 part this new framework is based on the existing PRINCE2 2009 version. For the agile part they use The definitive guide to scrum by Ken Swaber and Jeff Sutherland (integral copy included in the manual) and material based on The lean startup by Eric Ries and Kanban – Successful evolutionary change for your technology business by David Anderson (see book review).

Besides these frameworks you can also find explanation of behaviour in the areas of collaboration, self-organisation, transparency, rich communication and exploration.

In a next post I will give a summary of PRINCE2 Agile based on the official PRINCE2 Agile manual.

Book review: Kanban, Successful evolutionary change for your technology business

kanbanI just read the book “Kanban, Successful evolutionary change for your technology business” from David J. Anderson. This book gives you a great insight in the world of Kanban.

I was always under the impression that Kanban was just an example of the usage of a team board. This book proved how wrong I was. Kanban is much and much more!

The book is divided into four parts with in total twenty chapters:

  • Part I: Introduction
  • Part II: Benefits of Kanban
  • Part III: Implementing Kanban
  • Part IV: Making improvements

The first part contains two chapters introducing Kanban. Kan-ban is a Japanese word that literally means “signal card” in English. Kanban is an evolutionary change method that utilizes a kanban pull system, visualization and other tools to catalyse the introduction of lean ideas into technology development and IT operations.

The book gives the following definition: “A Kanban system is a system were a number of cards equivalent to the agreed capacity of a system are placed in circulation. One card is the equivalent of one piece of work. Each card acts as a signalling mechanism. A new piece of work can be started only when a card is available. This free card is attached to a piece of work and follows it as it flows through the system. When there are no more free cards, no additional work can be started. Any new work must wait in a queue until a card becomes available. When some work is completed, its card is detached and recycled. With a card now free, a new piece of work in the queuing can be started.” This is what you call a pull mechanism.

When there is no explicit limit to the work in progress (WIP, or the maximum number of cards at a specific process step) and there is no mechanism to show that we have to pull new work into the system, it is not a Kanban system.

Key properties of a Kanban system are:

  • Visualize the workflow (using a kanban board);
  • Limit work in progress;
  • Measure and manage flow;
  • Make progress policies explicit (e.g. the number cards/work units at a certain step);
  • Use models to recognize improvement opportunities (e.g. ToC, system thinking, …).

The second part explains the benefits of Kanban. In three chapters we get a recipe for success, a real life implementation example at Microsoft and the importance of a continuous improvement culture.

The author describes his six steps in the recipe for success: Focus on quality, reduce work-in-progress, deliver often, balance demand against throughput, prioritize and attack sources of variability to improve predictability. To grow in or build maturity you first have to “learn how to build high-quality code. Then reduce the work-in progress, shorten lead times, and release often. Next, balance demand against throughput, limit work-in-progress, and create slack to free up bandwidth, which will enable improvements. Then, with a smoothly functioning and optimizing software development capability, improve prioritization to optimize value delivery.

In Kanban it’s important to have explicit policies, designed to manage risk and deliver customer expectations. Work must be tracked transparently and all team members must understand and know how to apply the policies.

The last chapter of this part elaborates on a continuous improvement culture. In Japanese, the word Kaizen literally means “continuous improvement”. “Kanban provides transparency into the work, but also into the process (or workflow). It provides visibility into how the work is passed from one group to another.” “In addition to the visibility into the process flow, work-in-progress limits also force challenging interactions to happen sooner and more often.“

Dia33Part III, covering half of the book, is al about the implementation of Kanban. I created an example of a Kanban board and use that example to explain some of the key characteristics of the Kanban system. To build your Kanban system you could follow the following high-level steps:

  • To set up your visual control board you you first have to define a start and end point for control. This results in an outline of the workflow (from left to right) on the card wall.
  • Next you have to define your work item types. Think about requirement, feature, user story, use case, change request, production defect, maintenance, refactoring, bug, improvement suggestion or blocking issue.
  • As a following step add buffers and queues to the workflow to manage the bottlenecks.
  • For each type of work you must make a study of the demand (in the figure the swim lanes for Change Request, Maintenance and Production Defect) and allocate capacity according to the demand. This results in limits for each queue.
  • On the board we are putting work item cards. Each visual card representing a discrete piece of customer-valued work has several pieces of information on it, e.g. id number, explanation, data accepted, hard-delivery date, et cetera.
  • Set the input and output boundaries. Upstream and downstream partners want to see their work on your card wall. For you, you first want to provide transparency onto your own work. In the example you find the input queue and release ready columns.
  • At the top of each column you show the WIP (Work-in-progress). When there are fewer cards in a column than the WIP you have to pull a card from the previous column to keep the flow going. This will help to reduce the lead-time.
  • Downstream you have to discuss the input queue size. This depends on the prioritization cadence and the throughput of the system. Upstream you have to agree on delivery coordination and method.
  • Decide on the different classes of service. Each class comes with its own set of policies and target lead-time. Use e.g. for standard class of service the yellow post-it, for fixed delivery date the purple post-it, and for expedite the grey post-it.
  • For issues (impediments) you could add a red post-it to the existing work item.
  • As a result establish service level agreements and policies.

In the book these steps (and several more) are explained in much more detail including lots of best practices how to apply them.

The last part is the most difficult part of the book. If you want to make improvements to your Kanban system you have to look for bottlenecks and non-instant availability, waste elimination and reduction of variability. This part ends with issue management and escalation policies.

Conclusion

To get familiar with Kanban this is a good book to read. The book uses good examples and gives you a good insight how Kanban can and must work. It will help you to set up, use and optimize your own kanban system. Like all agile approaches don’t start with everything, begin simple and build upon it based on your own experiences and feedback.