Think about the concept of a feature team – all of the skills you need to deliver features in a single team. This comes from software / IT teams predominantly – I first came across the concept from the Vodde / Larmann books on scaling agile. Furthermore, if you add the scrum ideas, usually this is limited to 7+/-2 people. So, everything you need to continually deliver features within no more than 9 people. To scale, you need many more groups just like this, all delivering features.

I have never seen this actually work in practice because eventually, particularly in medium to large organisations, you need many more services to deliver features. It might be OK in a start up, but eventually you will need to scale and once you do, this ideal breaks.

There are a few examples of this, let’s start with a product company. Imagine that you’re delivering a product to market, think of all of the things that you need to make this happen. You might have a product manager determining which features to target in particular markets. There may be quite a bit of research that helps start this journey – they might even call in some customer / user experience experts to help them with this research. They’ll need to understand if the feature will be financially viable, so they consult with the sales and finance departments to figure out if it will even be profitable. There may be legal issues involved with introducing this, so they may also consult with their legal department or external lawyers. I think I’ve already hit the 5-9 limit there and we haven’t even started to build the feature yet.

Let’s look at a company with a technology department supporting the larger organisation. Generally, teams are organised into domain groups or technology based groups or mixtures of both. Often when you get to a certain sized organisation, trying to keep all of the skills together for features is difficult. Granted, there might be a large number of features that can go through this team without touching any other interdependencies. However, eventually you’ll get to a point where you’ll need a skill that’s not contained within that smaller group. Oftentimes, you may get a group of 25-50 people who are formed in several “feature” teams, but often there’s some kind of specialist in each one. In that case the teams are always going to call on each other’s help to complete a feature.

I have heard some people mention that you can move people in and out of teams on demand – for example if you need some legal advice on an item, that lawyer becomes part of the team or even “solution/release train”. This is not a realistic option as that lawyer is likely simultaneously providing advice to different areas of the business, they’re really not part of the team. This is once again an example of trying to move “people to the work” rather than understanding how work flows through the network and the interactions involved.

In either case, by creating feature teams you’re assuming that you’re going to continue to get the same kind of demand, over and over. Herein lies the trap – if you create feature teams you could potentially create a fragile kind of environment that may be resistant to other kinds of demand – and those kinds of demand may prove to create new, highly valuable revenue streams. In manufacturing, you may be trying to do this kind of thing where you have to repeatedly create the same widgets over and over again, however in knowledge work it’s quite different. You need to be optimising for change and adaptability as the nature of demand will change.

Your organisation is a network of interdependent services, it’s not a mass of groups making widgets. What is important is to optimise the way different kinds of demand can flow through that network and to ensure that it continues to evolve and adapt in response to the different kinds of demand. Creating feature teams can work against this kind of agility as the teams focus internally to produce things and don’t strengthen and create new linkages in the network overall. This problem won’t necessarily be avoided with component teams, however component teams by their nature have to interact with other teams and groups to produce an outcome so they naturally create and use those connections.

When creating feature teams, you’re looking to optimise the creation of those features with small teams to cut down communications lines and enable more rapidly and cost effective delivery. This may work in the short to medium term where you’ve continually got the same kind of demand. Ultimately, you may be moving people around more regularly to keep features within a team or group. You might even find, particularly in organisations that are not small, that you’ll inevitably need additional services to complete features – too much to contain within one team. Strategically thinking, you might want to consider whether you want to optimise for creating the same things over and over or optimise to adapt and change with different kinds of demand.

In this way, feature teams really are an idealistic state that you’ll never effectively reach. In most organisations you’ll have to scale differently with different kinds of demand that will call on services from across the organisational network. Please consider feature teams and ask yourself what really is the best way to optimise and scale for your organisation?

RETURN TO BLOG

There are 3 key feedback loops in Kanban – the board, the cadences and the data. Each of these feedback loops play their part in enabling and improving flow. What you might not have noticed right away is that these three feedback loops support each other and without one of these, or with a lower maturity version of each, you’re likely not getting the most out of your kanban system. The following outlines how each of these support and effect each other and how you can use and improve them to enable better outcomes.

Here’s an overview of how the 3 relate to each other:

Boards and Cadences

These two really support each other. For example, during the Kanban meeting we often walk the board and in the process of doing so we may make some updates to items. This is also the case with the Replenishment meeting – you’re moving items over the commit point as a part of this. In that way, the cadences are supporting the boards in terms of keeping them up to date and relevant. Imagine if you didn’t have a daily kanban meeting – how likely is your board to fall behind or even into disuse? Additionally, the boards are supporting the cadences because imagine having these meetings without the boards – you wouldn’t have all the latest information at hand to make those decisions.

In terms of the improvement cadences, often things like the service delivery review will look at the board and how it’s designed. You might even do a small STATIK increment and redesign the board with a new work item type or class of service that you’ve discovered. Thus the improvement cadences are keeping the structure of the board(s) up to date as well.

Boards and Data

This is relatively simple – essentially the data that we have from kanban systems is derived from the board(s). We capture data about the flow, blockages, work types, classes of service and any other data points that you may think relevant. For physical boards this data capture is often manual – you might at the end of the week round up all of the things that have been unblocked and record the details of the blockages for a subsequent blocker clustering activity. Alternatively, you might capture lead time data at the end of the week or even daily.

For electronic systems, these are often built into the kanban tool itself. Purpose built kanban tools such as Kanbanize and SwiftKanban have these built in from the beginning. If you’re using something else such as Jira or Azure DevOps, you might want to consider something like Nave (pictured above) to get the metrics directly from your board.

Data and Cadences

The data really does help to support the cadences – particularly the improvement cadences. You really can’t do the Service Delivery Review effectively without data – it’s a key part to look at things like lead times to see if your service is truly fit for purpose and if not, what actions should you take. Furthermore, after taking actions, you’ll go back to the data points to check in to see if the experiment you tried worked, if you need to rollforward/backwards or try something else entirely.

Using data is also useful in the delivery meetings as well. For example, if you know which work items have aged to an extent that puts their lead times at risk, you might want to focus on those and have others in the team help out to get them done.

Conclusion

The kanban feedback loops work together and help support each other. You’ll find that as you refine one, you all add to the maturity of others. For example, modifying the board will lead to new data which you’ll then review in you cadences. All of these serve to continually enable the delivery of and improvement of the services that you offer your customers. How are your feedback loops servicing your customers? If you want to learn more about feedback loops, please come along to my Kanban Systems Improvement course.

RETURN TO BLOG

Understanding the difference between work item types and classes of service can sometimes be confusing to those who are new to Kanban. These are two different concepts and whilst there is often a 1:1 mapping between a work item type and class of service, they are distinguishable concepts. Here’s a reminder if you’re getting confused between the two which will help you out in future STATIK exercises.

Work Item types

The work item type is closely related to the request that’s coming from the customer. Customers can often have different types of requests / different types of services / work required. These requests can go through different types of workflow.

This is the key to work item types – the customer request / service needed and the process we go through to provide the service.

For example, if you were to take a coffee shop, a customer could request a take away coffee or they could order a coffee to have in the coffee shop. These two are conceivably different work item types – in the first example the customer will expect to get the coffee in a disposable cup that they can take away. In the second example, the coffee will come in a reusable mug and staff member will bring it out to the table at which you’ve been seated. Notice that both have different workflows. Also, in either case there might be different expectations as to the level of service. For take away, you might want to get it as soon as possible, whereas for dine in service, you might be happy to wait a little longer as you’ve likely got someone there with you that you’re having a conversation with.

Classes of Service

Classes of service represent different policies on how to deal with a customer request / work. For example, for an urgent or expedited item the policies may be:

  • Stop what you’re doing and focus on this task
  • Swarm on it (use as many people as required)
  • Don’t wait in queues
  • Release when ready

Policies for standard items might be:

  • Only pull this in when capacity is available
  • First in, first out (FIFO)
  • Release weekly

Note how the policies describe how the team is supposed to treat the request.

Compare and Contrast

Sometimes a work item type will have a class of service to itself. Some work item types naturally have a higher priority than others. I think this is where some people can get confused, when there’s a 1:1 mapping between a work item type and a class of service. However, please remember to distinguish based on what was discussed above so that you can get a better understanding of how the system is operating.

Alternatively, some work item types will have different classes of service. There are situations where certain requests will have a different cost of delay compared to others. Thus, with those different levels of urgency the team will need to handle it in a different way.

Both types taken together can make up the service level expectations. Take the following examples:

Work TypeClass of ServiceLead time
AStandardAverage lead time of 12 days, with 85% completed within 16 days.
BFixed DateAverage lead time of 6 days, with 90% completed within 8 days
BIntangibleAverage lead time of 10 days with 80% completed within 15 days.
Lead time expectations

As you can see from the above, they both have distinct elements, but they work together to help inform customers of service expectations.

Conclusion

Work item types and classes of service are two distinct concepts. They need to both be understood in order to form a kanban system. When designing your system, take the above into consideration and you should be able to walk through the STATIK steps more easily.

This is something that I’ve been thinking about over the last several years. After experiencing / running some of these events and having seen them played out with various clients I had an instinctive reaction as to the waste behind PI planning. I haven’t had the full language to express exactly the problems with this and how it fits into the overall organisational maturity and growth up until now. Recently, I attended an Okaloa flow simulation on multi-team flow and after stewing on the insights from that for a week or so, whilst planning an inception (I didn’t want to use the PI planning words), I realised a number of connections that I’d like to share with you.

Firstly, as if to contradict what I’ve just said above, even though PI planning is ultimately waste, it can be a useful stepping stone for chaotic / lower maturity agile implementations. I think this is similar to many things in SAFe – some of the practices are useful to begin with, the painful part is when they get hardened and become the norm rather than looking to rise above and find better ways to work. Let’s consider some of the useful points of PI Planning first:

  • It gets alignment (across leadership and teams)
  • It gets the teams to think about their capacity
  • It can help bootstrap the upstream (described below)

Bootstrapping Upstream

This is worthwhile expanding a little. For some teams, they haven’t yet developed or seen emerge Upstream Kanban. The PI Planning event can actually help bootstrap this if it isn’t there. However, often many agilists (yes, even those who consider themselves coaches!) don’t have knowledge of Upstream Kanban, so they miss the subtleties that occur upstream and how it is different to delivery. What is important to understand is that work flow through your overall system – some aspects prepare work for delivery and discard poor options, whilst others build / deliver it. Where flow doesn’t exist, the PI planning event (being large and expensive) creates an impetus to make sure “features” are prepared enough to run through during the event. Often what happens is that during PI planning teams commit to features to deliver, but also determine which features they want to “shape up” for the next event for delivery. This is one of the downsides if you’re not careful – it locks you into a 6 month lead time for features (is this agile!?!). But importantly, teams are concurrent thinking of getting items ready whilst they’re delivering other ones.

Where PI Planning comes unstuck

One of the key parts of where this comes unstuck is that this is usually held every three months. That’s problematic because what occurs at this time is that teams align and commit to a number of work items every three months. The result is that you essentially only get 4 of these per year. Is 4 points per year to plan / change course agile? This is really a large batch transfer that get’s underway and it undermines the continuous flow that was starting to emerge through bootstrapping upstream mentioned above. Agility comes from fast feedback and having only 4 pivot points per year where you can adjust the work based on feedback is the opposite of what I believe the agile manifesto authors were trying to achieve.

Other examples of where I have seen waste with PI planning is when an assumption during planning turns out to be false. I’ve seen this happen within 2-4 weeks of the PI planning exercise and teams in those instances dove back into a PI planning process. There’s a lot of cost involved in getting these PI planning events up and running – when a few assumptions learned down the track causes the whole process to come unstuck, I’ve got to question whether it is the right process.

Whilst working within a “train” is part of the PI Planning, if you have to synchronise work outside of your train then more coordination is needed. I think this comes down to the mechanistic nature of SAFe itself that denies the complex and somewhat organic nature of the organisational network. Although you may be able to predict the nature of interdependencies and organise around that, there’s always going to be new demand that will create new connections in the organisation that you have to deal with. Now we’re talking about pre and post PI planning events to ensure items are synchronised across streams. Again, these are often large events with a multitude of people involved. A couple of problems with that are that, once again, plans can change and you need an intervening process to keep things aligned once underway. Is there a way to achieve the outcome without the large cost of these events?

One key theme from all of this is that we’re committing too early. Whatever happened to the lean thinking that talks about committing at the “last responsible moment”? Now I’ve heard arguments that PI planning isn’t about “committing” but about planning and that plan will change. However, I don’t think that’s in practice what most people take away from it. Particularly so when teams do the “fist of five” – it seems like they’re “committing to the plan” (although the usefulness and safety of this technique is questionable). Alternatively, this perhaps could be argued to be a reversible commitment – that things later in the planning can change. But what’s not readily apparent is the abort costs and other potential waste of this behaviour.

If we were instead to defer commitment until we have capacity to be able to fulfil the order / option, then we have greater flexibility to deal with unexpected events with greater clarity for all. Oftentimes, we see urgent work enter the system after PI planning – this causes other work to either be paused, postponed or even aborted. All that time we spent planning and now we have to replan for this new item. We also have to reset expectations about when those other items will get delivered. Perhaps we shouldn’t do such detailed planning for items down the road, perhaps there’s another way to schedule / commit to work.

Alternatives

Replace “Plan” with “Forecast”

I think that the word “Plan” inherently has issues with it. When people hear the word “plan” the often associate it with a commitment. This gets the expectations around the event confused and misunderstandings will arise. Instead of using “Plan”, use the word “Forecast” and give a likelihood of something being done. For example, say something along the lines of “on average our features take 65 days to deliver, and we can deliver 90% of them within 110 days”. Note the difference between the average and the 90th percentile – it allows for the potential that an urgent item might slip into the flow and delay it – and there’s also a chance that it can take longer. This also requires teams to capture some basic flow metrics – again something else that might need to be bootstrapped through the process before you can rise to this next level. However, this gives stakeholders a much clearer understanding of when something will actually come their way.

Enable flow

Once the upstream has been bootstrapped, you can start to move away from the “stop/start” nature that tends to occur with PI Planning. This tends to be more of a batch transfer than flow and will start to impact the organisation’s real agility. Start to look at your flow and impose some WiP limits around the parts of the process – batch transfers happen when there are no WiP limits around those parts. Doing so will create a more sustainable pace for your teams and allow you to defer commitment until you need to make those decisions.

As your deployment practices mature, you’ll find that you’ll be able to start to deploy on demand. It begs the question why you can’t replenish on demand in the same way. Why would you want to wait for the 3 monthly cycle to pull new work in? The answer is that you probably shouldn’t – the problem is that the transaction costs of replenishment via PI Planning are now too high, so it’s probably best you avoid those costs and find a better way.

Continuous improvement inherently built in

One of the other problems with PI planning cycle is the “Planning and Innovation Iteration”. This totally goes against the ideas of flow and continuous improvement. Using the last iteration of the PI for this is inherently bad. What tends to happen in practice most times is that this gets left out when initiatives run into risk / dark matter expansion and have to fill it with work anyway. Also, leaving all innovation to one single point in time seems contrary to how innovation actually works.

Instead, plan in time along the way to do the preparation of new items and to include innovation as a matter of course – part of the weekly workload. At the team level, you can allocate capacity to intangible class of service items on the board to cover off innovation items as they’re needed (usually it’s own card colour or swimlane).

Tokens guide capacity

An alternative that was made clear to me through Okaloa flowlab simulations, was that you can use tokens to guide capacity and commitment. Teams understand how many features they can build concurrently and offer that many tokens. Let’s say it’s 4 concurrent features. They work on 4 features and when one is done, they have a free token. This token is then available for new commitment. When a new feature is ready that requires the token (usually it needs tokens from a few teams) that new token can be allocated to the feature and it can be started (once tokens from all teams required are available).

This is a simple solution to allowed deferred commitment and reduced transaction costs from PI planning and will ultimately help the agility of the organisation. Oftentimes, teams in SAFe style arrangements don’t have a very good understanding of their capacity – or they have to do lots of estimation and need other details to understand it. The tokens provide a simple way to understand capacity without the need to go into detailed estimation.

Conclusion

PI Planning builds in large transaction costs and creates batch transfers which are waste. Both of these effects can impact your organisation’s agility in the long term. These events can be useful in the short term to provide alignment and help bootstrap flow. You should avoid hardening in such costs and anchoring your agility and instead take it to the next level by concentrating on how to enable real flow in your organisation. There are other alternatives and you should look at how they can be implemented to help your people, your customers and your organisation’s strategic objectives.

RETURN TO BLOG

In my early days in agile, I remember statements from folks like Martin Fowler who would talk about continuous integration and his approach that “if something’s is hard to do, do it more often”. Through this continuous integration was developed, by folks who leaned into a stressor on the system of work. Later, based on the same kind of idea, this proved to be the foundation for other advances like continuous deployment / delivery.

Stressors on the system of work often appear – you may not notice them at first for what they are, but they’re often an opportunity to improve the system of work. Indeed in these examples, by leaning into the stressor teams have been able to unlock new opportunities previously unheard of. You can choose to listen to the stressors in the system of work or avoid them – the maturity of your system of work will reflect your group’s ability to deal with stress on the system.

Another example of a stressor that I often see on systems of work are WiP limits. Teams that are new to this often need some time to adjust. It can be hard not to follow old habits like continually pulling new work into the system without first clearing those that are in progress. Often systems are setup to reward / recognise those who are “busy”, but not necessarily those who have created a sustainable, reliable flow. Particularly, I’ve seen teams go over their WiP limits and have had to work with them to reinforce the need to do so. Those that can manage to lean into the stress often see benefits to the systemic improvements and can move onto next level problems like ensuring they really are being fit for their customers purpose.

There are many other examples, such as “backflow” (items that are rejected, move backwards in the flow), other quality issues, discovering and dealing with fat tailed lead times, cultural issues such as heroism and rockstars as well as dealing with things that are blocking flow. All of these can create stress on the system of work and often the people in it.

In all of these cases it’s important to be able to detect the stressor. Often visualisation systems help with this, but what’s also important is the supporting cadences and feedback loops. Equally important is to have an inspection mechanism / point where you can more deeply understand what is happening to the system and why, so that you can take a more logical, reasoned response to the causes. Many people respond to these stressful situations emotionally as they too are under stress, but if you focus on the system of work you can help relieve the people in it.

I would hearten you to have courage when facing into these stressors, it’s not going to be easy, but if you handle it correctly the ultimate system will improve and relieve stress on the system of work and the people within it. Remember our Continuous Integration example above – it would have taken quite some work to go from no CI, to a working CI practice but the benefits are clearly there. Sometimes it will be difficult and require patience, but don’t back away from it because that will only hide or exacerbate the problem.

Leaning into the stressor in a system of work is difficult, but often very beneficial. You will uncover better ways of working through doing it and improve your ability to service your customers and your market. To do so effectively you’ll need to set yourself to be able to start, being able to see / visualise the problems, having a feedback mechanism to understand causes and catalyse action and it often requires a little slack in your system to be able to allocate capacity to create the improvement. The good news is, you can start putting these things in place today!

RETURN TO BLOG

This is a format of retrospective I first started using in around 2013 and still use it today to help teams understand their work and the system of work in more detail. It’s particularly useful for teams starting out with Kanban and can be used as not just a reflection point for the team, but one for coaching and learning. It’s fairly simple and doesn’t need a lot of preparation – you can just go with this on your next retrospective.

It’s called the campfire retrospective because essentially the team gather around the board like a campfire and tell stories. You look at the board and prompt with questions like “what’s going on here” and let the team tell the story. I also often ensure that key data such as lead time distribution / scatterplots are to the side of the board so we can discuss this in relation to the stories on the board. After telling a few stories and understanding some more of what’s going on, you can start to adjust your board right there in the retrospective. Here are some things you can look out for / prompt for:

  • Does the workflow look correct or should we adjust it?
  • How are the WiP limits going – do we need to adjust?
  • How’s collaboration – are people helping each other to achieve better flow?
  • Are any items blocked and what’s causing it?
  • Are we seeing some key repeating dependencies?
  • Are there any new work item types or classes of service emerging?
  • Are the policies working or do we need to update them?
  • What is the data telling you?
  • Are recent changes working as you expected or do we need to adjust again?
  • What are the customer expectations and interactions around the tickets?

There are so many things that you can look at and talk about around the Kanban campfire. Importantly, once you discuss these issues, you should look to make improvements. Some you can make straight away – for example to adjust the policy just do it there and then on the board. Others you might need to add a task to the board to track a larger improvement body of work.

This is a simple form of retrospective that often provides a great way for the team to collaborate and improve. Often they may start this with improving the system to help the team, but over time, you’ll find you can shift this to help them focus more on the customer outcomes with their Kanban system. The other thing that’s great about this is that you don’t need a permission to get started – you can just schedule this for your next retrospective and watch the team take ownership and leadership. Have you tried the Kanban campfire retrospective yet?

RETURN TO BLOG

This is a question that I often ask people when they’re having trouble adapting to Work in Process (WiP) limits. WiP limits can be challenging to some when they’re new – all those competing demands telling you that you need to do more. How do you respond – by pulling more work into the system in the hope that business will equal better performance. It can be hard to make the switch to say “not yet“.

Often the decline into high WiP will occur over time – and it will be so gradual that you don’t notice it happening. Until you’re snowed under – there’s so many things on the go you find that you spend your entire day just trying to keep all the balls in the air – you don’t actually make much if any forward progress. There’s so many things on the go that you don’t have time to consider how to fix the problem – and any attempt to improve the system is met with a negative, sometimes aggressive response because you’re too busy to even think about it.

People can react this way when they’re under stress – from too much work in the system. People don’t want to take on a WiP limit and don’t understand how it can help them and they often think that it’s OK to task switch a lot. It’s not OK – especially in knowledge work. To do knowledge work effectively you need time to think through deeper problems and try and solve them in ways that are intensive on the “necktop computer”. Task switching takes you away from this ability and is part of the source of the frustration.

Which is where my question comes in – if you think a little bit of task switching is OK, then I take it to the extreme. “Is it ok to work on 1000 things at once?”. To which, the inevitable answer is “No” (I haven’t heard anyone say Yes to this yet). To which I respond, “Good, so you agree there needs to be a WiP limit. Now let’s talk about where that limit should be for your context”.

Getting started with WiP limits can be difficult – sometimes you need to take it to the extreme to help people understand what’s really going on. If you find yourself bogged down with too much work, don’t use hope as a method. Limiting your WiP will help you focus on what’s important to meet commitments and achieve balance. What are you waiting for?

RETURN TO BLOG

This question comes up quite a lot – particularly with those who are new to Kanban. I was reminded of this by Alexei Zheglov recently in one of his tweets and I recall some recent conversations on this topic. The way you handle this kind of situation reflects on the maturity of your Kanban implementation. On lower maturity systems, you will see cards moving backwards quite a lot. However, with more mature implementations this should rarely occur, if at all.

It comes down to whether your board is representing a workflow with handoffs and backflow for problems or if you’re modelling the knowledge discovery process. If you’re modelling you’re basic process or purely specialities of work you will see things move back and forth as people create those handoffs. In this kind of board you’re describing the specialities – so although it may be a useful transition point you run the risk of hardening those distinctions, rather than focusing on the overall flow. You may use it briefly as a transition point – to demonstrate the problems, but please use it as a catalyst for further action and improvement rather than sticking with it otherwise you’ll continue to face problems.

When we teach Kanban, we recommend that your board visualises the knowledge discovery process. What that means is on the left we have little knowledge of the item and as it moves through the flow we gather more knowledge and information about the problem we’re facing, its implementation / rollout to customers. It also means that the titles on the board describe the predominant knowledge discovery activity – it doesn’t exclude other types of activities. Take this simple board:

Just because the title says analysis, it doesn’t mean no development or testing can occur. For example perhaps as part of the analysis you might need a developer to do a quick spike to see if something will work in a particular way. Additionally, the development column doesn’t mean no analysis can occur – for example the developer may analyse the various data scenarios in order to create the appropriate set of unit tests to handle the scenarios. Testing doesn’t mean development activities can’t occur – maybe you’re developing the automated test suite here or fixing bugs.

This brings me to my next point – how to handle these situations. The testing scenario where we find a bug is one that is quite common. In that case we often leave the original card in testing and create a new card for the bug which also traverses the flow. Once the bug reaches testing and is verified as fixed the original card can continue on its way. Another way to deal with this is using blocking stickies. I discussed this in one of my earlier posts on blockers.

If you don’t treat this as a knowledge discovery process and instead move cards back and forth in the flow you’ll hit a number of issues that will make it very difficult – if not impossible, to manage flow effectively:

  1. Your metrics are going to be out – if you look at your CFD charts they’ll do all sorts of strange things such as lines going down (that’s usually a sign you messed something up).
  2. You’ll break your WiP limits – these are there to help you manage the flow based on capacity. Items moving back and forth will constantly be breaking WiP limits and you’ll find it very difficult to manage flow as you have no control over the movement back and forth

Furthermore, if you’re modelling the knowledge discovery process it makes no sense to move something backwards. Cards upstream denote that you have less knowledge about them. The trigger for moving something backwards is usually that you’ve discovered something about it – some kind of problem. It makes no sense to move it to a place on the board which denotes you have less knowledge – quite the opposite the discovery shows that you now have more knowledge than you did yesterday about this ticket so it should not move backwards. You may be better off examining your policies to make sure items flow cleanly without the backflow.

Moving cards backwards on a kanban board doesn’t make sense unless you’re using it as a catalyst to bring about improvement. There are better alternatives available that take into consideration the whole of the system. You’re better off going to a place of understanding the knowledge discovery process so that you can manage the flow effectively.

RETURN TO BLOG

Many organisations don’t recognise the difference between upstream and downstream. Some do recognise, but don’t consciously think about the nature of the difference between the two and consequently don’t design their systems of work in the most effective way. I hope this article will help you recognise the difference between the two and secondly, how to handle each situation.

Both upstream and downstream involve knowledge work. I consider knowledge work anything that requires the use of the “necktop computer”. That is, it’s inherently human and requires skills and knowledge, but it’s also about knowledge discovery. The following diagram is a visual representation of flow moving through upstream and downstream.

Upstream

Upstream is to the left of the “commit point” (the red line). You can see a few columns there describing a basic flow, plus a discarded area at the bottom. Different types of work may flow through at different rates, but usually the high value items will take longer to move through this flow.

Upstream is about discovering and selecting from your options. This is why it’s slightly different here – you can see the discarded area where we drop options that are not worthy of our time in delivery. We have other things like minimum WiP limits to help ensure that we don’t starve downstream.

Key to upstream is that you’re buying information. That is, you’ll need to make decisions thus you should understand what decisions you’re looking to make and get the appropriate information for those decisions. Doing so, you should usually find the cheapest and fastest ways to get information that is “good enough” for making decisions.

I also like to overlay this with the Cynefin framework. I quite often consider a lot of the work that occurs upstream to be in the complex domain. We often probe to find the information we need to make decisions. We may also apply some expertise / analysis (complicated domain) – for example to get the appropriate information to be considered “Ready” for downstream consumption, but the main high value work will usually involve some probes.

Image source: https://en.wikipedia.org/wiki/Cynefin_framework#/media/File:Cynefin_as_of_1st_June_2014.png

There are also linkages with upstream once an item is “Done”. There may be some validation that occurs once items are deployed which will feed new options into upstream. Ensuring appropriate feedback loops and data capture are performed are ready should also be considered when designing your system of work.

Downstream

Downstream we’re looking to convert the options chosen into outcomes. This is quite different to upstream – whilst still knowledge work the goals are different and we need to adapt the system appropriately. I often also see / refer to this as “Delivery” as well.

This is why in downstream we consider things like efficiency and quality. Often downstream is quite costly – there may be a variety of skills and competencies here that aren’t cheap to buy so we want to make sure we’re getting the best “bang for our buck”. Here we’re looking to avoid blockages and bottlenecks and convert the option as quickly as possible, or at least doing so in a way that’s fit for the customers purpose.

As this conversion of options requires quite a lot of skill, often we see most of the work in the Complicated domain of Cynefin. That’s not to say that we won’t see elements of complexity or best practice, just that predominantly it will be complicated. Ensuring we adjust the system of work that is created should reflect this nature. We see this in agile software development quite a lot, where teams might be working on stories that fulfil user / customer needs, but there might be other types in there such as “Spikes” which are a form of probe.

The quality aspect here downstream usually get’s us to ask “are we building the thing right”. Conversely, upstream are often asking the question “are we building the right thing”. Downstream we focus on making sure the customer’s need was met through the service we’re providing. We’re also looking more deeply at “how” we do it rather than “why” – upstream should have already answer the question of “why”.

Conclusion

As you can see, there are considerable differences between upstream and downstream. Just knowing the differences will help you create a better design for your system of work. Please consider both and make sure your system has been optimised in the right way at the right points to enable better outcomes.

If you want to learn more about upstream, we cover this off in more detail in the Kanban Systems Improvement course. I’d encourage you to do Kanban System Design first if you haven’t yet done so to understand more of the basics of how to create Kanban systems.

RETURN TO BLOG

I was recently asked by the Adelaide Agile community to give a talk at their Scaling Agility meetup. I had a lot on my plate the last few months with adapting all of my training to the virtual world and running some TKP and KMP sessions, but I thought this is a topic that I’d like to address. I think that many organisations have been doing “Agile at scale” in the wrong way so I hope that the folks from Adelaide – and others around the world, got something out of this recent talk.

I’ll start with what I think folks have been doing wrong. Firstly, the whole “we need to reorganise first” is completely wrong. There are a number of organisations doing this to implement things like SAFe and “the Spotify model”. I think this is completely unreasonable because it puts people offside in the organisation from the start and guarantees that for about the next 12 months your organisation is going to be massively internally focused and lose track of customers and purpose. If I were a competitor and you announced you were going to go down this path I’d be smiling away in the background knowing that I’d have a distinct competitive advantage for the immediate future that I should capitalise on.

Also, when it comes to things like the “Spotify Model” – not even the folks at Spotify think this is a thing. If you think the benefit is there, then go right ahead, but you’re missing the point that each of these organisations is unique and has particular needs. What was going on at Spotify was based upon their culture, their domain, their market – so a variety of factors that you likely don’t align with. I’ve always believe that organisations should find their own path to agility that is unique to their context – sure there may be patterns that you can apply, but don’t do so blindly.

Which is really my key point – understand the problems you’re trying to solve, understand your customers and understand your purpose. There’s no such thing as perfect and you’ll need to continually adapt. Models like SAFe are more internally focused and don’t put these things at the forefront – it feels more like a solution looking for a problem. I’ve mentioned this before in posts like “Focus on core problems“.

Scaling with Kanban is different because you focus on problems facing your customers and your teams. You look to understand purpose – customer and organisation, and evolve towards it in a humane way. There are different ways you can look at scaling such as height, width and depth. These are the kinds of things I cover off in my Kanban Management Professional courses. If you really want to go deeper as well, I’d suggest checking out the Kanban Maturity Model which has gone through many evolutions and is now packed full of useful, pragmatic advice.

Many thanks to Jason Cameron for reaching out to me and asking me to do this talk. It might be somewhat different than what your group is used to, but I hope that everyone got a lot out of it.

Here are the slides:

RETURN TO BLOG

Something that I hear quite regularly, even throughout the agile community, is the perceived need to get better at estimation. Often in responding to areas of uncertainty, we attempt to add some level of control or certainty – particularly to delivery. I think that in many cases when I hear this, we’re actually solving the wrong problem.

Firstly, to the problem – do we actually understand the problem we’re trying to solve? In many cases this is a key point – any estimate will be based on the understanding of a problem and oftentimes, we don’t understand the problem well enough to be able to do this with any accuracy. In those circumstances, it’s not really worth estimating because we need to explore the problem space some more. Perhaps it’s a case that you’ve prematurely converged into the solution domain and need to get back to the problem domain. Often this occurs, because answering the questions in the problem domain are hard – perhaps it’s more about what experiments / spikes / customer trials should we run next to understand the problem some more before considering estimates.

In exploring the problem domain, it’s likely the case that you haven’t sliced the problem enough to be able to create focus and understanding. This makes it increasingly difficult to provide estimates because the domain is so broad. Spend more time creating alignment and focus on a more narrow scope and the estimation will inevitably be better as you have less uncertainty.

Estimates are often given as a single number – “it will be 6 months for 3 teams” or something of that nature. It doesn’t take into account or demonstrate the uncertainty in the domain – both in terms of problem domain and complexity of coordinating through the organisation to deliver the outcome. What if it was something along the lines of 4-8 months for 2-4 teams. Or perhaps something like “there’s a 80% chance of finishing within 6 months with 3 teams and 95% chance at 8 months with 6 teams”. Using a single number cuts down the conversation around risks and lulls stakeholders into a false sense of security. Starting with understanding and dealing with key risks up front gives you a greater chance of achieving the outcome – or stopping early if the outcome is not a viable option.

Furthermore, even in delivery maybe your estimates are not your largest issue. Quite often, I find in terms of medium to large organisations, there’s generally a low flow efficiency. Estimates usually pertain to effort rather than lead time. If you have a flow efficiency of 10%, then how much better off are your really by trying to get a better understanding of the 10%? There’s a point of diminishing returns and in this case it’s basically straight away for that kind of activity. You’re better off spending your time dealing with the blocking / wait states that are impacting the 90% of your lead time than getting better at estimates.

I often hear the cry that “we have to get better at estimates”. However, this is usually a symptom and the cause is likely elsewhere in your system of work. Take some time to get to understand the system of work and be more specific about the problem you’re undertaking to solve and you’ll likely avoid the discussion about estimates altogether.

RETURN TO BLOG

The power and value of the the term “yet” is underrated. The power of continuous improvement is only attainable if you continue to challenge the status quo, even in small ways. Often the first step towards this is in our thinking – if we can start to see new possibilities then we can start to move in that direction. Being closed to possibilities might be hurting your ability to continuously improve.

Change and improvements can sometimes stall – there can be many reasons to this, including:

  • Not focusing on core problems
  • Too much change creating “change fatigue”
  • “This is how we’ve always done it”
  • Thinking that making a change is too big

With many of those things, sometimes it’s best to just introduce a small change in language to help push people’s thinking away from the “now” and into the “possible future”. Use the word “yet”. It can be a very simple and useful lead in to a provocation that allows you to start to move towards something better.

Instead ofTry…and then ask….
We don’t know how to do that.We don’t know how to do that, yet.What would it take to know that?
We haven’t achieved that goal.We haven’t achieved that goal, yet.What is the next simple thing we can do to move towards that goal?
We don’t know how the customers will react to that.We don’t know how the customers will react to that, yet.How can we find out?
The team’s morale hasn’t improvedThe team’s morale hasn’t improved, yet. What is impacting their morale?
What can I do to help?
We don’t know how to validate that.We don’t know how to validate that, yet. Is there a safe to fail experiment we can run to find out?

As you can see from the above, we take a statement that sounds quite negative or closed and turn it into the chance of something possible. It also encourages the follow up questions to explore the possible.

Using the word “yet” is a small change in language, but it can light the way to your next steps. It costs nothing to try it and it may open you to possibilities you haven’t considered yet. Try it out and see if you can move towards a new possibility.

RETURN TO BLOG