Evogility

Cumulative Flow diagrams can contain quite a lot of information for observations. However, they can also be a little daunting for those who are not familiar with them. In this blog post I’ll share with you some tips and information for how to start to use cumulative flow diagrams.

Here’s an example of a CFD:

Each line is a count of the number of tickets moving through that part of the process – stacked on top of one another, hence the name “cumulative”.

Light Blue – Done items
Yellow – Deploying
Grey – Testing
Orange – Developing
Dark Blue – Analysing

Along the x-axis are the days – it’s quite common for CFDs to use days as the point of measurement.

Along the y-axis is the count of the tickets. For example, on day 0 there were no tickets in the Done area, whereas on day 1 there were now 3.

That’s actually one key part of being able to read these kinds of graphs. The distance in height between the two lines represents the number of tickets. Thus the larger the gap between the lines, the more tickets that are in that part of the process. Therefore, the further apart the lines the greater the Work in Process (WiP).

If you get lines that are continuing to grow apart, the you have a WiP growth problem and this is going to slow down your overall throughput. This is particularly useful if you use the top and bottom lines when viewing WiP growth because these represent the input and output of your overall system. If you’re not getting growth in you system, but lines within it a growing, it means that there’s likely a bottleneck inside the system.

Additionally, where these lines start to converge, it means you have decreasing WiP and may lead to starvation of a part / all of the system. This might not be a problem in the immediate short term, but left unchecked it may lead to an unnecessary spend / costs.

Using these observations, you can start to adjust WiP limits and control the point of input to either prevent extra work coming into the system / parts of the system, or alternatively allowing more work to flow through. Effectively, this is what managing flow is about – trying to match variations in demand and capability to achieve a balance.

Another key observation about CFDs is that the average lead time is denoted by the width of the graph. For example, if you look at the above graph at the dark blue mark on day 1 – this is when item 11 entered the system. If you track horizontally across the chart, you’ll see that this item left the system (the light blue line) on day 7. To determine the system lead time, you can deduct the entry time from the exit time giving you a lead time of 6 days.

Of course, this time will vary as things change in the system. If you look further up the chart to day 7 and the analysis count there and then track across to done, you’ll notice the lead time is down to approximately 4 days. That’s about a 30% reduction in lead time and can often be attributed to actions such as limiting WiP in the system (as Little’s law tells us that decreasing WiP can also lead to decreased lead time) or other improvements to the system.

The third key attribute of this is the angle of the bottom line of the graph. This is known as the delivery rate or throughput of the Kanban system (as an average). The flatter the angle, the less the throughput. The greater the angle (moving towards vertical), the greater the delivery rate / throughput.

You can see these three key attributes in this chart:

You don’t need to always have electronic tools – if you have physical boards you can maintain a physical chart with this data. Alternatively, you can capture this in a spreadsheet. There are also other tools out there such as SwiftKanban, Kanbanize and LeanKit that do these things for you as well.

You can now start to use cumulative flow diagrams to help make more informed decisions about your system of work. You can see bottlenecks that you can action, you can start to limit or increase input to balance flow and you can limit work through the process to help smooth the flow. You can also start to make plans around how to reduce lead time or increase throughput which will have positive impact to your customers and your financial bottom line.

The cumulative flow diagram is an essential tool for managing flow and improving the outcomes of your service delivery. If you aren’t using one, you now have the basic knowledge to get started.

RETURN TO BLOG

Posted on April 2, 2020 by Daniel Ploeg

Kanban, Metrics

Lead time scatterplots are an important tool for a team working with Kanban. Sometimes these are referred to as a “Control Chart” which is often the case in manufacturing. However, in knowledge work I think it’s less about the “control” mechanism and more about using it to improve the capability of the term providing the services. Thus I usually just refer to these as “scatterplots” and if you look at the example below you can see why.

There’s quite a bit going on here, so lets look at each part in turn.

X-Axis – This contains a series dates, you can see they progress over about an 8-9 month period moving from left to right chronologically.

Y-Axis – Time in calendar days. This is the amount of time a work item took when it was completed. This is calendar days, so it includes weekends and public holidays.

Orange dots – These represent Standard class of service items. Each time an item is completed, an orange dot is added at the date of completion and the total lead time for the item.

Grey triangles – These represent Fixed date class of service items. Similarly to the orange dots, they represent when an item is completed and the lead time to completion.

Orange dotted horizontal line – This represents the 95th percentile mark for Standard class of service items. That is, 95% of the work items fall under the line and 5% above. This line is optional, plus you can add lines at different percentile’s as per your needs (eg 85%).

Grey dotted horizontal line – This represents the 95th percentile mark for Fixed date class of service items.

You may notice a few things:

Lead times are not necessarily uniform. This is often the case in knowledge work – thinking everything is exactly the same is a common misconception
Sometimes there are gaps – there may be holiday periods where there is less work going on. You should understand this as being part of the normal cycle / capability of your team.
Some items take a large amount of time – Often items that are blocked or have external dependencies cause work items to have their lead time blow out.
There are much fewer Fixed date items than standard.
Fixed date items have a much lower lead time

Things to look out for

Growing lead times – this would tend to indicate an underlying problem in the system that you need to attend to
Where batches are completed together – there may be some bottleneck in the process preventing things from getting done, or the items might not be independent – look at how you slice for independence.
In progress items – this only shows you the “Done” items, it doesn’t show you the ageing of currently open items. You can use a separate chart for this – it’s important to action problems early before it’s too late!

You don’t need a whole lot of data for this to get started. All you need is the start date and end date of each of your work items. A few years ago I did a lightnight talk at Agile Australia 2017 that talks about this. If you’re looking for a tool to help you do this, you should check out Troy Magennis’ “Throughput and Cycle Time Calculator” excel sheet in his Focused Objectives repository.

It’s good to understand the basics about how these scatterplots work. I’ve touched on some of the ways they can be used, but there’s more detail to it than that and it requires a few other charts, so I’ll save this for a future blog post.

RETURN TO BLOG

Posted on March 26, 2020 by Daniel Ploeg

Kanban, Metrics

kanban, metrics

One word that I continually think of when I think of WiP limits is “Focus”. Essentially, WiP limits create a focus for working on the right things at the right time. The absence of WiP limits means that there is often a lack of focus in the organisation.

Often when teams are doing many of different things, they tend to start lots of work, but tend not to finish anything. It really doesn’t help drive them towards their key goals and purpose. Having WiP limits in place will help focus a team on what’s key to be doing right now.

Sometimes there may be a mix of work types or priorities / classes of service for work. Using WiP limits more explicitly can help you ensure that your efforts are balanced appropriately across the different types. This helps people focus on the different things to the right level and see them through to completion. It can help ensure the right balance of work.

If teams are resistant to the use of explicit WiP limits, I would say something along the lines of “What’s our focus for this week / month” at their daily stand-up / kanban meeting. That invariably leads to a conversation around, “well we don’t have to start this yet, as it’s not our focus” or “this is critical for hitting <key focal point> for the month”. Teams tend to collaborate towards this shared goal and deliberately avoid the “noise” from other activities.

I often hear of / see things in organisations along the lines of “We have 100 people delivering projects, and 120 projects currently underway”. Clearly, in this kind of scenario there is a lack of focus for the organisation. What really needs to occur is to limit the number of projects in progress so you can focus your group efforts on achieving key outcomes.

In this kind of scenario, trying limiting the number of projects to, say, 20-30 and put a policy in place that says, you can only start a new project when an old one is completed. You start to create a bias towards delivery and completion of work to reap benefits sooner.

RETURN TO BLOG

Posted on March 19, 2020 by Daniel Ploeg

Kanban, WiP Limits

focus, goals, kanban, WiP

Everyone has probably seen a job ad for a “rockstar” team member, or perhaps it’s come under a different name like “ninja”, or you may just know them as “heroes”. How would you define something like this? Usually people are looking for the expert / saviour that will help get things over the line even when things are tough.

In reality, what this often manifests in are individuals who are working for their own purpose, rather than that of the organisation. Oftentimes, these individuals tend not to share knowledge and often work alone since the sharing of knowledge would threaten their position as the “rockstar”.

The effect that this kind of behaviour can have includes sub-optimising the system and creating a bottleneck – since only one person can solve all of the tough problems they quickly get overwhelmed with work. Since they won’t reach out for help it becomes an escalating problem as more and more work get’s backed up in front of the bottleneck.

It can also have problems on team morale – when team members see people acting as individuals, then they will start to either resent those people pushing them further from the group and / or give others permission to act for their personal interest rather than the organisation’s interest.

You can start to see how one policy of hiring “rockstars” can have multiple impacts on the overall system of work. Is it really the rockstar who is to blame here, or is it the system of work and the leaders that allow this behaviour to continue?

In discussion at our local lean coffee group, one of the members used the example of a football (soccer) team. In which, he said he wants those superstars on his team because they convert those rare opportunities into goals that win matches. However, they often have rules in place to ensure that the star players don’t get ahead of the team – with systemic solutions such as dropping a player for a week if they act in their personal interest rather than the team / clubs interest (for example by not passing the ball in certain situations).

I think therein lies the solution – you can have great people in your teams so long as the system is set up so they continue to work in the organisation / team’s best interest, rather than their own. Set up the system so that great people can work together to achieve great outcomes and put in place measure that allow this to happen and prevent the need for heroes.

Posted on March 6, 2020 by Daniel Ploeg

Teams

leadership, teams

The origin of this statement for me goes back nearly 20 years ago when I attended a technical leadership training event whilst I was working at Hewlett-Packard. At the time I remember thinking that I learned more worthwhile lessons in a week of that course than in entire subjects at university. The title of this post is one of the key lessons that I took away and am still using today.

So, a little explanation is in order as the statement sounds a bit crazy taken out of context. During this training session, we were taken through a series of simulations – with a explanation and discussion of relevant points after each simulation.

The simulation behind this statement was a simple problem solving situation. The idea was that there was multiple rounds and each round there was a “minimum” score that you had to get (I think it was around 20 points). After each round, you presented your solution to the facilitator who would then calculate your score based on the answer you gave. Highest scoring team wins. There was a fairly simple and repeatable way to get 25 points which was over the minimum – it didn’t take a lot of brainpower to figure out. Now, you could try different combinations and there is a distinct possibility that you could fail and get zero points.

Different teams tried different strategies and I remember our team after getting the simple answer started to get bored. So, we decided to experiment. We failed a few times, but it gave us insight to try new things. After a few rounds our scored had dramatically increased (I can’t remember exactly how much, but I think it was in the order of 100-200 points). Within a couple of rounds we had made up any lost scores of the experimentation and we were the winning team.

During the debrief I remember the facilitator saying that he’s seen all sorts of permutations for this exercise. One that he remembers most was a sales team who repeatedly answered with the basic scenario getting 25 points a round. He said at the end he asked them why they did that, to which they replied “We made quota”. This in contrast to our teams approach was very different – we got bored as there was no growth / interest in maintaining the status quo so we experimented.

During our debrief the facilitator was going through how to solve problems – in particular with people working in technical domains. Obviously, when one of our experiments failed, we would try something else. It makes me think of the quote / cliche “Insanity is doing the same thing over and over and expecting a different results” (to which I would add, unless, as cynefin has shown me, you’re in the complex domain and you may well get different results). Anyway, continually repeating a failing practice tends not to be a good idea. Which brought us to the first part of his statement “If something’s not working do something different”.

The next part, relates to how we felt during the simulation. We figured out the basics and were getting bored. This is often the case with technical teams, and I’d also say knowledge workers more generally. They like to solve problems – a solved problem repeated over and over will not keep their interest for long. It also means that you plateau in terms of capability. You need to look for new ways of doing things, for example the evolution of land transport from horse to railroad to car. There’s a ceiling to breeding horses, they can only go as fast as their able – but different means may allow something superior to emerge. Getting around on horse is still viable for basic transport, but we may want something better. This relates to the second part of the statement – “If something is working, do something different”.

Therein lies one of the key lessons I’ve learned in my professional career: “If something’s not working, do something different. If something is working, do something different”.

RETURN TO BLOG

Posted on March 3, 2020 by Daniel Ploeg

Approaches

cynefin, experiments, learning

A Listing of Kanban Related Books

Over time, I’ve accumulated a number of Kanban books, however I don’t think I’ve seen a posting with all of the details of what they are so I thought I’d share my own personal collection and my thoughts about the various books to help people decide what they would like to choose. I probably have left out some really good books – not because they’re aren’t worth mentioning, it’s just because I don’t have a copy of them yet. If you find one that I should have, please contact me.

Essential Kanban Condensed

David Anderson & Andy Carmichael

Level: Beginner

https://www.amazon.com/Essential-Kanban-Condensed-David-Anderson/dp/0984521429

This guide summarises the basics of kanban. It talks about the values, practices and principles. It is quite simple and for anyone looking for a quick introduction to kanban then this is your go-to book. It has a very comprehensive glossary at the back describing many of the elements of Kanban systems.

Kanban – Successful evolutionary change for your technology business

David Anderson

Level: Beginner -> Intermediate

This is really one of the foundation books for Kanban, it will explain the Kanban method with case study information about STATIK (Systems Thinking Approach to Introducing Kanban) and many of the very basics. This is very common amongst kanban practitioners and is often referred to as “the blue book”.

Kanban Maturity Model – Evolving fit-for-purpose organisations

David Anderson & Teodora Bozheva

Level: Intermediate -> Expert

https://www.amazon.com/Kanban-Maturity-Model-Fit-Purpose/dp/0985305150

This book is useful for coaches and change agents looking to use Kanban to help organisations become more fit for purpose. This book comes from a large body of knowledge of applying Kanban in different contexts across the globe. What is interesting here is understanding what current level of maturity a team / organisation is at and then applying appropriate next steps for that context. Essentially, given Kanban’s evolutionary nature you will need to crawl before you walk before you run and this book takes you through the steps in the evolution to prevent you from falling down in the process.

Lessons in Agile Management – On the road to Kanban

David Anderson

Level: Intermediate

This book is a select collection of blog posts that come from Davids early work prior to release “the blue book”. Although this book was published subsequently, they tell the thinking journey that led to the emergence of his later work in Kanban. I found particularly interesting the sections on tribal behaviour and how it relates to the change management of Kanban.

Personal Kanban – Mapping work | Navigating life

Jim Benson & Tonianne DeMaria Barry

Level: Beginner

Personal Kanban is a really powerful tool for organising things in your own personal life. As someone who can attest to attempting to cram too much into life, these simple tips can help you achieve some balance.

Kanban from the Inside

Mike Burrows

Level: Beginner -> Intermediate

This book introduces the concepts of the Kanban values and goes over more detail about STATIK (Systems Thinking Approach to Introducing Kanban)

Making Work Visible – Exposing time theft to optimise work and flow

Dominica DeGrandis

Level: Beginner -> Intermediate

I really like Dominica’s subtitle – “Time theft”. Time is the one thing we can’t reproduce, so it’s highly valuable and Dominica helps us understand “The five thieves of time”. Although some of Dominica’s examples are quite simple with images to follow, she gets into more detail about metrics and feedback mechanisms that will help take your Kanban system to a much deeper level (thus I gave this a Beginner to Intermediate rating)

Kanban for Lawyers

John E. Grant

Level: Beginner

https://leanpub.com/kanbanforlawyers

This book is only partially complete, but I thought I’d include it here because it’s interesting to see others take the concept of Kanban and apply it to different domains. It’s fairly simplistic – written to get lawyers started.

Kanban Change Leadership

Klaus Leopold & Siegfried Kaltenecker

Level: Intermediate -> Expert

I think this book is really suitable for Kanban coaches and consultants out there helping organisations to improve. Although this book does recap on the basic practices of Kanban, its focus on the change and the leadership required around that change to support it is really more advanced. Be ready to tackle issues such as emotional responses to change and creating a learning culture.

Practical Kanban

Klaus Leopold

Level: Beginner -> Intermediate

I really like this book from Klaus. Like so many other Kanban books, it’s written from the experience of the practitioner applying Kanban in a number of situations. The first couple of parts of this are really focused at beginners – learning why kanban and how to use and improve kanban systems. He then gets into more advanced and interesting topics in the sections of Large-scale Kanban, Forecasting and Risk Assessment that are really aimed at the intermediate levels (or perhaps even expert).

Rethinking Agile – why agile teams have nothing to do with business agility

Klaus Leopold

Level: Intermediate

I really like the message in this book – plus the simplicity of the message. The cover really says it all – time to focus on the biggest organisational challenges towards agility, rather than an individual team level. At first the concepts seem simple – particularly so because they are portrayed through illustration as much as words. However, tackling the underlying issues that Klaus talks about at the larger organisational level can be challenging, thus I’ve marked this book at the intermediate level.

The Scrumban [R]Evolution

Ajay Reddy

Level: Intermediate

People have been using Scrumban for some time now, however not many people have given a lot of thought to how Kanban can be overlaid on an existing scrum system of work. Ajay has provided a basic overview of scrum & kanban and then gets into many detailed recommendations as to how to combine the two. I’ve given this an intermediate rating because I think one should attempt to read one of the basic books first to get more detailed understanding of Kanban (eg “the blue book” or “Kanban from the Inside”) – oh and if you haven’t read the scrum guide then you should also do that too.

Stop Starting, Start Finishing!

Arne Roock

Level: Beginner

https://www.amazon.com/Stop-Starting-Start-Finishing-Roock/dp/0985305169

This is a very short (approx 30 pages) book that really sums up the very basics of kanban using few words and some visual aids. If you have a manager or leader who doesn’t understand Kanban yet and you’re trying to get started, hand them this book and check back with them the next day or week and have a follow up conversation.

Real-World Kanban – Do less, accomplish more with Lean Thinking

Mattias Skarin

Level: Beginner

This book describes kanban using real world examples. Throughout the book, you’ll see where things started, what they learned along the way and the improvements they made as a result. This is a relatively easy read with some basic examples – for me I particularly like the sections on “Using Kanban to save a Derailing Project” and “Using Kanban in the Back Office: Outside IT” – I think these two scenarios are more common use cases than what you might think.

Essential Upstream Kanban

Patrick Steyaert

Level: Intermediate

https://www.amazon.com/Essential-Upstream-Kanban-Patrick-Steyaert/dp/098452147X

This book, although relatively small, packs a great deal of information in about how upstream kanban works. Often teams start at the level of the team and don’t deal with how work comes to the team. Upstream kanban looks at how you can balance demand and capacity for a smoother flow overall. It’s probably best that you get to know Kanban basics through one of the beginner level books, as this book builds on a base level of knowledge.

Actionable Agile Metrics for Predictability – An Introduction

Daniel Vacanti

Level: Intermediate

Dan’s book on metrics is the go-to for many a kanban practitioner. He goes into many details about the different types of metrics and introduces a number of concepts such as “flow debt”. I’ve marked this as intermediate as you really do need to have a base understanding of Kanban before you venture into this book.

Related to Kanban

Although these books are not explicitly about Kanban, you’ll find a lot of Kanban related thinking in these.

Fit for Purpose – How modern businesses find, satisfy and keep customers

David Anderson & Alexei Zheglov

Level: Beginner -> Intermediate

This is really related to Kanban because Kanban systems when they become more mature are focusing on fit for purpose services for customers. The book includes simple to understand case study / examples that looks more deeply at the purpose of services and how to produce better outcomes.

A Practical Approach to Large-Scale Agile Development – How HP Transformed LaserJet FutureSmart Firmware

Gary Gruver, Mike Young, Pat Fulghum

Level: Intermediate

I really like this book – although it’s not explicitly taking about Kanban, many of the parts of the story are relatable to Kanban values, principles and practices. It describes the journey of a how multi-site HP team (approx 400 people) chose to transform the way they work for greater responsiveness to market. There is a lot of pragmatic context sensitive advice given – with reasons as to why those choices were made in their context and considerations given.

96 Visualization Examples

Jimmy Janlen

Level: Beginner

https://www.amazon.com/Visualization-Examples-Jimmy-Janl%C3%A9n/dp/9188063011

Although it doesn’t specifically talk about Kanban, many of these visualization examples are useful and relevant for those who are on a Kanban journey. No doubt you will select a number of these to help improve your current system of work. It’s well illustrated with examples that make it easy to understand and get started.

The Principles of Product Development Flow: Second Generation Lean Product Development

Donald Reinertsen

Level: Intermediate -> Expert

Although not explicitly Kanban, there is a lot here that relates to the way Kanban systems work (Donald also wrote the foreward for the “Blue book”). This is a really dense book – so much wonderful information, I’m glad Donald wrote it all down because it’s a lot to keep together in one’s mind. It’s a book you’ll keep coming back to – there’s always another nugget of wisdom buried in there that you’ll find that you can apply to your Kanban implementation.

RETURN TO BLOG

Posted on February 28, 2020 by Daniel Ploeg

Kanban

book, kanban

I’ve heard this being said a number of times with teams and it often reminds me of the story the Jeff Patton told in his book “User Story Mapping” when he was talking about requirements. In that story, when he was trying to get a better understanding of the underlying need being requested he was told “They’re requirements” – to which he likened to being told to “shut up”.

When I hear the term “It’s on the backlog” I think that’s another way some agilists are telling others to “shut up”, or at the very least “go away”. Often it’s not followed up with more honesty like “we don’t intend to build that”, or at the very least “it’s not likely to be built in the near future”. Sometimes this is a way of saying “No” or “Not yet” where it can be difficult to say this flat out, but is it the most respectful way to treat people?

Again, this is the problem with using the term “Backlog” instead of “Options”.

How about instead try something along the lines of “we can add a ticket to our pool of options, but it’s not likely to be implemented anytime soon, if at all”. You might find that this change in terminology gives your stakeholders greater respect and builds on the trust and transparency that you need to build a more stable foundation for a longer lasting relationship. Also, you’re starting lean towards the use of language that supports probability / likelihood rather than absolute certainty. This incremental step can be built upon later with greater use forecasting.

RETURN TO BLOG

Posted on February 24, 2020 by Daniel Ploeg

Agile, Backlogs

Backlog, kanban, Product Management, Scrum

This is a term I first come across in Don Reinertsen’s “Principles of Product Development Flow” book (“B9: The Batch Size Death Spiral Principle”), but I’m constantly reminding myself of its importance . Essentially, this describes the behaviour of how large batches with their infrequent delivery seem to attract more and more work – becoming even larger batches. As larger batches take longer, there is an increasing problem of dates moving out and more and more work being added. Essentially this can become a never ending spiral of work that never gets done.

Essentially, as projects start to get larger they invariably create a “gravity” to which other things are attracted to, creating even larger batches. As things start to slow down, other things become dependent on the large project. Given that it’s really large with a lot invested in it, often this project becomes the priority with others having to give way to it. However, this is not always the case – other pieces tend to “attach” themselves to the large project because this is the only way to get things done.

Once a few things have attached to the large project, it makes that project even larger. Timelines start to blow out and everything slows down. Once this avalanche has built up enough momentum it’s almost impossible to stop. With all the interdependencies and things hanging off the key project, it’s hard to start to unwind it. Now this key project becomes the only available delivery vehicle to the organisation and other things start to attach itself to it.

As things get critical, people start to work late nights and weekends trying to get that key project over the line. Although burnout might not be specifically mentioned, it’s likely this is happening to your staff. They get sick as a result of the workload and in the sum total is that you haven’t gone any faster. People get unhappy and leave the organisation further impacting timelines and puts more pressure on those who remain.

Now you’ve invested a lot of capital into this and in some organisations, by cancelling a project they convert the CAPEX into OPEX and that effects their budgets to “keep the lights on”. That project is now not contained within itself, it’s starting to impact your business at a fundamental level.

Often nobody in middle management wants to take the onus of stopping such a large investment and it can be a career limiting move. There may not be enough safety in such an environment to make such a call and thus the reporting continues to be positive. Given that delivery gets delayed there’s often little negative feedback as it’s coming from internal sources, rather than real customers further fuelling the biased feedback loop.

Executives may not be aware that there is a ticking time-bomb waiting for them – at some point, it may even be years down the track, they will have the shock of discovering everything isn’t as rosy as they had assumed. The result can often be that they need to go into full damage control mode – sometimes they may even have to act quickly to save the business.

To avoid this kind of situation, you will need to use WiP limits and other means to control batch sizes. A project is essentially a batch of work, so understanding how these batches work is key to unlocking the batch sizes. Just putting a WiP limit on the number of projects may not be enough – if one project is massive, then you will need to look further below to see if you’re really going to be affected by this.

One way to prevent it is to only release funding on a smaller and limited increment – for example per feature. This kind of constraint places a focus on the transaction costs of large batches and tends to start to unwind the damage caused by the large batches. You may even impose time based constraints – eg every project must delivery some value at least once a quarter / half financial year.

Other ways are to treat batches over a certain size as critical risks that must be dealt with. Often there are ways to decouple items or reduce transaction costs / time of delivery such they don’t have so much to do all at once.

Instilling an air of safety in the organisation that allows managers to give full transparency to executives and be honest about the options. Having up front upper / lower control limits defined will help you guide this conversation objectively. Being able to stop this train wreck before it happens will be key, often it’s easy to start projects, but they are really hard to stop – adjusting your process so that you’re able to stop will be useful.

Large batches can quickly spiral into larger batches. These can be a critical threat to your business and it may not necessarily be immediately apparent. These can be avoided if you put in place measures and constraints to control this kind of situation.

RETURN TO BLOG

Posted on February 20, 2020 by Daniel Ploeg

Lean

#lean, batches, WiP

I’ve recently been thinking about a number of experiences in my career where organisations who have a bias for delivery have uncovered options that were not previously available to them. I’ve also seen others who had a tendency to delay delivery (or at least deployment) to when their customers are “fully ready” for it.

This predominantly happens in organisations that have traditionally had long lead times for delivery. Often the transaction costs for delivery are quite high, but other times it may be that the process and thinking over time has solidified such that the delivery managers don’t consider other options.

Some of the arguments I’ve heard include the following (along with my counter arguments):

“That’s the way we’ve always done it” – That’s a Kodak moment waiting to happen. You can bet you’re bottom dollar that if you’re not looking to improve, then your competitors are. How long do you think that will last?

“It will cost too much” – This is often in the context of the cost of deploying without delivering – there is a run cost to have the hardware / systems there earlier. However, I would counter this by saying the hidden costs you’re not considering are:

Lifecycle vs Project costs – if you deploy regularly during the project, you can test the deployment automation mechanism and be confident that it works at the push of a button. Delaying this often means costs are pushed into BAU where later releases are still manual and are longer, costlier and riskier
Opportunity cost – by sticking to long cycle times, you are cutting yourself off to potential other opportunities that you’re not aware of yet
Transaction costs are high – well, if we don’t do something about it earlier they will always be high. Maybe there are some ways that you can start to reduce these transaction costs that you haven’t thought of – perhaps start here.
Have you fully considered the overall cost of delay if you get into a “large batch death spiral“? This is quite likely if you stick to this.

“Our users are not ready for it yet” – Perhaps, but have you considered all of your user groups? I’ve seen opportunities where you can do early releases to your staff / operations team often referred to as “Eating your own dog food” (a common practice at Microsoft). This is a great way to reduce overall delivery risk – particularly if you have a large delivery footprint.

What are some of the results we’re likely to see?

Some of what I’ve seen before are a combination of things, the key one is:

New opportunities – This is often not thought of and the value here can be enormous. I’ve seen organisations try to release a new product and it doesn’t go exactly as expected. However, by getting something out earlier, it’s given them a new capability / offering that has allowed for exaptation / transforming into other products or parts of products. By getting something out early they have created a new foundation for future revenue.

Other reasons for taking a bias to delivery include:

Reduced delivery risk – particularly around timeline. Getting things out early and regularly so at least someone can use it helps validate if you’re really on track (even if it’s not your final target user group).
Reduced costs – In some instances I’ve seen clients say “This often takes 12 months and can often fail – let’s see if we can get something out in 3 months”. It gets really hard to spend a lot of money in a smaller timespan.
Stopping – There’s often an OPEX / CAPEX problem if you haven’t actually produced a usable asset. Some organisations, are reluctant to stop the large batches because it will switch spend to date to OPEX from CAPEX which will have deeper ramifications for the organisation and their customers.
CAPEX depreciation – If you can start depreciating an asset in 3 months rather than 12, there are potential financial benefits to this that you otherwise wouldn’t have

How do we get started?

In a word – Leadership. By this, I mean someone has to have the vision and courage to see what is possible and make a change. This does not necessarily have to be done at the top level – I would encourage all Delivery Managers, Project Managers etc to consider this on their project.

If you’re working in a space and see this happen, try arguing with some of the reasons above and probe to understand why people might not wish to try it. It may just be “too different” to what they’re used to. You may need to break through any fear there in some way – you might want to create a greater fear in maintaining the status quo with the reasons above to create that movement.

RETURN TO BLOG

Posted on February 17, 2020 by Daniel Ploeg

Agile, Kanban

agile, kanban, leadtime, Options

Often we become constrained in our thinking by the language we use – a good example is the use of the term “backlog” instead of “options”. Quite often if you say to someone “It’s on the backlog”, the perception is quite often that although I might not get it now, it will become available sometime. However, in reality this is often not the case – or should not be the case. If we change the wording we use, we’ll create a more accurate representation of what is actually, or should actually, be happening.

Definitions from the Cambridge dictionary:

Backlog: “a large number of things that you should have done before and must do now”

Option: “one thing that can be chosen from a set of possibilities, or the freedom to make a choice”

Commonly, the term option is used in the context of the stock market, where you can have an option to buy shares (or not). You have the choice – it’s not an absolute.

As you can see from the basic definitions above, they are quite different and the impression that they can give stakeholders, also, would be quite different.

The above definition of backlog implies a fixed scope – “must do now”. However, to truely be agile we shouldn’t be committing these kind of things up front as we’ll learn along the way and what should be done will change as we learn.

Try to stop using the term backlog, and instead replace it with the word(s) “Option” or “Pool of Options” and see what effect it has to the conversations with your customers and stakeholders. You’ll be able to defer commitments to a more reasonable point in time and have that process better understood. Additionally, you’ll likely find that you’ll have earlier conversations as to whether we should discard some options, rather than keep maintaining the illusion that something may get done.

RETURN TO BLOG

Posted on February 12, 2020 by Daniel Ploeg

Agile, Backlogs

Backlog, kanban, Options, Product Management, Scrum

Dealing with Resistance to WiP Limits

Sometimes teams will understand the concept of WiP limits and be reasonably open to them, but perhaps their process is still emergent or they don’t yet understand what WiP limits they should put on the parts of their flow.

One possible solution to this scenario is the Constant WiP limit – also known as CONWIP. The idea is that you don’t put the WiP limit on each part of the process, but rather have a WiP limit on the overall flow. See the example below.

This is a basic pull system, but often the underlying process is not well understood or managed, thus it is a lower maturity implementation. You can use this to buy enough slack for you to be able to better understand and elaborate on the underlying system and start to implement some of the deeper kanban practices.

RETURN TO BLOG

Posted on February 10, 2020 by Daniel Ploeg

Kanban, WiP Limits

agile, kanban, WiP

Dealing with Resistance to WiP Limits

Another technique for dealing with resistance to explicit WiP limits is to try limiting WiP per person. This can be useful for a team who is not used to working coherently together yet or might not want to go straight to WiP limits.

This technique has the advantage of being easy to adopt – it can be explained by how it can be beneficial to individuals to stop them getting overburdened with too much work. I often start with a deliberate provocation like “Is it reasonable for someone to work on 1000 things at once?”. To which practically everyone answers “NO!”. The discussion usually continues along the lines of “Well then, why don’t we restrict the number of things someone can work on concurrently to something much lower, say 3 items”.

This can be represented simply on the board by limiting the number of tokens or avatars of each person to, say, 3:

In the example above, there are 3 people working together. Two people are using each of their 3 tokens. One person still has a spare token in the backlog area where they park spare token, enabling them to work on one more item.

This in itself can be difficult for some people. Often, you might get some “hero” types that might like to be the centre of getting everyone out of trouble all the time. However, often these folks are actually the source of many of the problems because they become bottlenecks. You might find challenges with these folks just getting transparency into what they’re doing in the first place, even before you limit WiP.

Assuming you do have a level of trust and transparency, there are a number of drawbacks to this approach. For example, are 3 items actually practical in preventing time wasted context switching? Perhaps / perhaps not – it just depends on the nature of the work and your context.

Also, as you may notice, this limits the work done concurrently by individuals, it doesn’t actually limit the amount of work in the system. You can see the last ticket in the development column isn’t being actively worked on because someone’s token got moved somewhere else. In this case, because systemic WiP is not limited, you’ll notice longer wait and lead times, plus it will make the system less predictable.

If you are having trouble getting a team started with WiP limits, this might help. Ideally, you should try and get to explicit systemic WiP limits, so treat this as an evolutionary step, not an endpoint.

RETURN TO BLOG

Posted on February 5, 2020 by Daniel Ploeg

Kanban, WiP Limits

agile, kanban, WiP

1 2 »