A lot of demand comes into teams who think they have no other choice except to say “Yes” to it and start working on it. This is a common mistake and usually requires a deeper understanding of the demand coming into your system of work and / or the capacity of your team to deal with it. What you will likely find is that only a small proportion of demand is irrefutable, much of it can likely either be avoided or deferred.
A key part to understanding why not all demand is irrefutable has nothing to do with demand, but it has everything to do with capacity. In knowledge work systems, capacity is finite – you don’t have unlimited capabilities to deal with whatever comes in the door. Furthermore, expanding that capacity is often neither cheap nor rapid – it’s knowledge work for a reason in that it takes skills and particular talents to be able to deal with it. So at some point, you’re going to have to say no to certain requests, whether you like it or not.
If you do say yes to everything and go over your capacity, you’ll end up slowing things down and rushing which will impact quality – neither of which are good for providing a “fit for purpose” service. Furthermore, due to the nature of capacity being finite, by saying yes to something you are impliedly saying “no” to other things. That is, every time you take on a piece of work, you decrease your capacity to take on other pieces of work. This might not necessarily be a conscious choice, but it’s one that you should start to think about. Saying no is not necessarily a bad thing – it means you’re focussing on what is most important for your business. It’s also a mark of professionalism and leadership to be able to have honest and forthright conversations up front, because if you do say yes to everything, you’re just delaying that tough conversation and will be breaking commitments to do so.
I think the important distinction here also comes in from the fact that not every request should be “committed” to. Some people view the fact that a request comes in means that they must make a commitment. Being able to separate the request from a commitment to get it done is a key point in kanban – make sure the commitment point and capacities are known and a discussion is being had with the requesters as to what should be committed to. Making this process transparent goes a long way towards deeper conversations about managing the competing risks of the different requests.
It’s inevitable that you will have to say no to certain types of demand – so how do you do it? Firstly, understanding your different sources of demand is a good point. Some sources of demand may not have the same importance or cost of delay than others. You’ll need to establish some policies around what should come in and what get’s left behind. There may be different classes of service that you need to apply to certain requests that help you decide what to take on and when. There are also other kinds of policies that you can adopt that will help inform what to start on.
Another way of looking at what we call “deferred commitment” is not necessarily saying no, it might just be a “not yet”. That is, we don’t want to start things too early and have them sitting on the shelf collecting dust. There’s an opportunity cost in starting some things too early and you want to make sure you’re not “saying no” to some thing by “saying yes” to others too early. Sometimes, some items can be deferred for some time which might be enough to take the stress of your teams and overall system of work. Knowing when the right time to start things is as important as what to say “no” to.
Not all demand is irrefutable, you may find much of it is deferrable or not needed at all. Establishing a transparent process with appropriate policies to limit the work coming into the system will take the pressure off your delivery team and allow you to provide a more predictable, reliable and fit for purpose service. Our case study in the Kanban System Design course covers this topic really well. I guess the question you should ask yourself is do you want to be an order taker or a leader?
Teams often have different sources of demand for their services. This is fairly normal, but I often see some teams try to treat all types of demand the same and even route them through the same process. Although this might work for a little while, you’ll probably quickly realise that the work and demand is more nuanced than a “one size fits all” approach and you’ll need to find ways to better deal with each.
First, lets clarify what I mean by demand. Its really any request or need for the team to provide some kind of service to someone (it could be a customer, someone internal to you business or a partner / vendor relationship). As you can see, just understanding who is making the request can lead you to start to understand more deeply about the need and the level of expectation around it. Not all requests should be treated equally – for example, certain customer requests may take priority over those from other departments in your business.
Not all types of requests will be the same. For example, customers might have certain types of requests that relate to their current service, but you might have needs coming from internal product sources that need capabilities to expand the customer base that you can offer to. Often the source of the demand will also give you some information about the nature of the kind of request that is going to come into the team.
Another source of demand that is often forgotten is from within the team itself. There’s often some maintenance activities that allow the team to “keep the lights on” that will need to get done. Not doing so, will eventually lead to larger problems with customers and / or product management that you’ll need to deal with. Another source of internal demand is capacity for improvements that can be made to the system of work. Not all improvements are free and sometimes you need to allocate capacity for it. If you haven’t allocated capacity to this kind of demand, guess what, things are often not going to get better and you’ll continue to tread water.
Another problem comes from the squeaky wheel. You’ve probably all seen this before, where an outspoken person (whether they are a customer, internal or partner) makes so much noise that you allocate an inordinate amount of capacity for their demand just to keep them quiet. This is not always the best strategy, because by saying yes to the squeaky wheel, you’re impliedly saying no to other types of demand.
So, perhaps you have a product owner that is going to do all this for you. Great, you’ve now just created a single point of failure – what happens when they go on vacation for 4 weeks, what do you do then? The team delegated all of this responsibility out and don’t have any idea how to go about “prioritising” the work. If you do have a product owner role, they should really be making clear through systemic policies about which demand is valid and how much of each type of demand the team should take on. This includes which type of demand you should not take on – just because someone has requested it doesn’t necessarily mean you must do it. Here’s an example board that describes how to deal with different types of demand using WiP limits per swimlane:
Note how half the capacity is allocated to Product enhancements, and a quarter each to customer requests and maintenance and improvements. It’s clear the amount of capacity being allocated to each source of demand in this case – you can go even further and put more detailed policies into each swimlane’s “Next” queue to describe how items get pulled into the system.
It’s important to understand the different sources of demand because your team will have a finite capacity. Understanding how to distribute that capacity amongst the different types of requests will determine if you can service them and whether you can provide a service that is fit for each purpose. Being clear about the policies around the sources of demand will equip the team well for dealing with the different sources without the need for constant management intervention. If you want to learn more about discovering and dealing with different types of demand, come along to our Kanban System Design course to learn more.
I went and got my first shot of the vaccine this past weekend. For those of you reading from countries outside Australia, we’ve been fairly slow on the uptake of vaccination not because of lack of demand but because our government didn’t order sufficient supply – so it’s a little slow going. But the purpose of this post isn’t about upstream / downstream kanban and the supply / demand – rather it is about what I observed in terms of how they managed flow out our local Covid vaccination hub and I was rather impressed.
For those who are not local to Australia, or even Melbourne Australia, the vaccination hubs have been set up at various communities within each city to help distribute the vaccines for Covid. The main vaccine in use is Pfizer, thus it needs to be kept at -70 degrees which requires specialist cooling equipment, thus it’s not so practical to have these more distributed. Thus they are designed with greater demand per hub in mind and are on a moderate scale.
There were several points in the workflow / system of work that I noticed:
Initial site check in using a QR code & hand sanitisation – this is normal now in practically every establishment (restaurants, shops etc) as the government uses it to trace the spread of the disease.
Main tent – here they double check that we’ve checked in properly and we enter a queue. During the queuing, we’re asked to read a number of documents to make sure we understand what we’re getting.
Secondary check in:
Outside – this is the main queue with a secondary sanitation station
Inside – there is a small queue here and then there was a identity check station
Vaccination cubicles (with a small queue beforehand)
Post vax waiting area
The following were some of the things that I noticed in this system:
The system was clear with it’s policies
There were specialists trained in each station, plus there were flow managers there to manage flow and queue sizes.
There were different classes of service
There were different work item types
I’ll talk about each in more detail
Policies
At each station it was fairly clear what we needed to do, and if not there were people there to make sure we did the right things at each point. This was most clear with the check in stations, where there were plenty of QR codes and signs – plus we are now used to this policy more generally. In the inside spaces in particular, there were floor markings noting the distance to stand from one another.
Additionally, each team member was wearing a badge to describe the kinds of work they were doing. This made it easy to identify who was qualified to do each task.
When we had our shot, the nurse gave us a little sticker with a time that we can exit – very clear and explicit. This allows them to monitor to see if there’s been any side effects. There was a large digital clock projecting in the waiting area which made it really clear when you could leave. On exit, the check out attendant took the vaccine type sticker and the exit time sticker and kept it for their records.
Although I would have like to take pictures to share with you on this blog, there were clear policies posted around the area requesting that we not take pictures.
Managing Flow
I noticed this particularly once inside in the secondary check in. There were very small queues before each of the pairs of check in attendants. Plus there were a one or two flow managers. What I noticed at one point was that the flow managers actually stopped people checking in, thus people stopped coming inside into the small queues. The outside queue (single queue) started to grow at this point. It became evident to me that the main bottleneck in the flow was the vaccination cubicles. Thus it made a lot of sense to make sure there were flow managers before the bottleneck to make sure the system doesn’t get overwhelmed. Once the health workers giving the vaccines caught up, the flow managers then allowed us to check in – but they still kept a watchful eye of what was going on downstream.
Also, having us read information whilst we were queuing made the overall flow occur more quickly – this was well thought out as it reduced the overall lead time to get the vaccine process completed.
Different classes of service
I noticed this when one person was on crutches – in the outside tent they let her straight through to secondary check in, I took a little longer to get through. Then when she got to the station just before entering the building, I heard the attendant there usher her forward and call out ahead “Priority!”. She went to a queue that didn’t have anyone in it so she could get checked in right away. This was a very simple example of a different class of service – note that the policies and workflow changed to allow this person through more rapidly so as not to cause any hardship.
Different work item types
I also noticed that there were different work item types here. The attendant at the door to the building who was checking priority was also starting to filter for work item types as well. She called out “Is there anyone here for AstraZeneca?” (this is another vaccine we have available, but is used less). I didn’t see anyone come through at the time with that, but there may have been different rules for how that flowed through the system. I did notice that when we checked in we got a blue sticky dot that we put on our clothing to identify the type of vaccine. I noticed on the check in desks that they also had orange dots – I’m guessing this was for the AstraZeneca. No doubt there would have been a subtly different process (perhaps specialist cubicles) for that type of vaccine.
Conclusion
I was most impressed with the system of work that was put in place for the covid vaccination hubs locally. Seeing many of the practices we teach about Kanban come into play allowing them to provide an efficient, safe and “fit for purpose” service based on the resources they had. I’m booked in for my second dose and I’m wondering if I’ll see some of the other Kanban practices come into play around improvement and see if they’ve made it even better. Kanban is being used around you in ways you might not be aware. If you want to learn how you can build it into the way you work, check out our Kanban System Design course.
I typically hear this kind of question from a number of agile coaches and those supporting “agile transformation” activities. The reality is that most agile coaches are not equipped to do this kind of work as they’re used to dealing with team level problems. The so called “frozen middle” are the layers of management – so in order to unlock them, we’re going to have to start to talk about how to “manage” teams and organisations in an agile way.
First of all, let’s set some context. This approach is really focusing on organisations that focus on “knowledge work”. That is, they’re using what I refer to as the “neck-top computer” to solve problems, create products and provide services for their customers. This is human centric and although we may use computers & technology to solve the problems, the key is the people creating those solutions. Usually, this is in the form of intellectual property and involves the creation or modification of various forms of intellectual property. For those in other industries that predominantly involves the physical aspects, such as construction or manufacturing, this does not necessarily apply to that kind of work (but it may apply to those aspects of the business that involve knowledge work – eg finance, legal, HR etc).
The management layer, particularly in medium to large organisations, has been created and evolved usually over many years or decades. Many of the processes and practices were put in place at some point in time for good reasons that may still be valid. First of all, we need to understand the context and the problems that you’re trying to solve – but we need to put this in the perspective of those in this management layer. How do they set and meet expectations? What are they being measured on? What management levers to they have to pull? Many agile transformations start with reorganising the structure of the organisation, however this is usually counter productive because you’re not necessarily dealing with the underlying problems that created the “frozen” aspect. Indeed, if you do a large reorganisation, you’re competitors are probably smiling thinking “they’re going to be busy distracting themselves for the next 6-12 months, we can take advantage of this”. If you’re undergoing this kind of change right now, come back to this in 12 months or so because I’m guessing you’ll still be facing these issues.
If you start to talk to the management layer about their specific problems and start to address them, you’ll both gain credibility and also have some practical benefits from the changes. But you’re probably thinking “how do I do that?”. This is the first step of any kanban implementation – understanding the points of dissatisfaction and addressing them. This is how to start thawing out the frozen middle. Often times there are problems like:
I can’t see / don’t understand what’s going on
I’m not sure of the team / group’s capacity
Are we predictable in our delivery?
Can I make reliable commitments?
There’s an existing policy / rule we have to follow
The next thing you need to know as a coach / transformation agent is that there are a lot of management practices that are firmly rooted in the 19th & 20th century. They’re not really designed for 21st century knowledge work. The key to this is that you need to be able to connect with managers of this understanding an alternative way to manage – the way they can “manage flow”. Many of the techniques are quite different and when you use this lens you’ll note that a number of the older practices are part of the reason for the existing problem and why the middle has become “frozen”. Through this, you’ll start to see where the problems / bottlenecks / blockers are to your organisations delivery capability. Seeing and improving this will lead to greater organisational agility. We cover this off in our Kanban System Design and Kanban Systems Improvement courses in more detail.
But why should the manager’s listen to you with this new management style? You need to understand what their motivations are – and it will be different for different managers. Understanding their motivations and giving being able to answer “What’s in it for me” for each of them is key to continuing to thaw out that permafrost. You can’t change everything overnight, but you can start to move them to a greater level of maturity more gradually. You just need to understand the change levers that are at your disposal. The reality is that it’s taken years / decades to create the existing system of work – you’re not going to be able to change it overnight, but it can start to evolve. We cover off these topics in the Kanban Maturity Model course, where you can learn how to help managers enable greater flow and maturity through their organisation.
For any agile coaches out there, if you’re coming across a “frozen middle” problem, please consider how agile management should really work. If you’re going to go into this space you really should be equipped with the at least the Kanban Management Professional if not the Kanban Coaching Professional capability to help you navigate those frozen seas. For those of you who wish to learn more about how Kanban can help you unlock the frozen middle, please sign up to our newsletter.
If you’re a Project or Program manager and you haven’t had much experience in agile delivery, this can be a daunting experience. You probably don’t know much of the lingo and you’re probably not sure of how you need to operate. More than that, you probably don’t know what on earth the team is doing or how you can understand it.
There are several possible ways you can go:
Get out – find another project that doesn’t have all this “Agile” stuff going on. Go somewhere else where you can be comfortable with the delivery techniques.
Bluff – you can try to pretend you know how to do this, perhaps trot out a few buzzwords and try and fly under the radar.
Revert – declare that agile doesn’t work and “we’re going back to waterfall”. That way you don’t have to change, you just need to get everyone else to do so
Learn how to manage an agile project / program – this may at first seem outside your comfort zone, but chances are no one else there’s knows how to do it, or do it really well – otherwise they wouldn’t have asked you.
Get out
Sometimes discretion is the better part of valour – you may need to make a tactical withdrawal at this point. There are likely plenty of “traditional” or waterfall projects out there that you can contribute to. You won’t learn as much or challenge yourself in a new context, but that’s ok, you can reliably deliver the kinds of things you have in the past the way you know how to do it. There’s still value in that for certain contexts through this delivery mechanism – so look for something that suits you.
It can be quite frightening going into an agile context if you’re not used to it. Things seem out of control – you won’t have your trusty schedule and other tools that you’re used to to rely on to see things through. You might not know how to communicate with the teams – how to understand the risks / issues and get the information you need to do you job.
If this is you, then I thank you for understanding where you want to be and not trying to fake your way through agile delivery and deciding to bow out. So many program / project managers pretend to understand and don’t really change any of their behaviours for this new context and they’re better off not getting involved – it will just lead to failure.
Bluff
In this option, you may not understand agile delivery – or you may think you do and just don’t want anyone to notice. You decide to bluff your way out of it – or “fake it till you make it”. It’s a nice idea, and you might get away with it for a little while. If you pick up on some of the buzzwords and kick off a few basic ceremonies, no one will notice that you really don’t know what you’re doing……will they?
This is a great option if you don’t want to change your behaviour too much. The teams can go “agile it” over there, but I’ll manage it with my traditional tools and techniques across all of that. What could possibly go wrong?
In the context where a number of people are new to agile and don’t know any better, you’ll probably get away with it, until it becomes noticeable. Essentially, the dynamics of the two paradigms will start to contradict each other and you may actually have to switch your approach to “Learn” instead. In which case, will you have made the switch in time or is it too late? It’s likely that if you’ve left it till this point in time, there’s some kind of problem that surfaced and you’re getting called upon / called out to fix it.
If people in this program actually have some agile delivery / management experience, they’ll probably call you out on it. When this happens, you can try one of the other options – “Get out”, “Revert” (perhaps you might need to remove / silence the agile delivery manager to do so) or “Learn”.
Revert
This can often happen – particularly if you’re not well experienced / trained for this kind of delivery. What happens is that often your traditional project / program managers come into the agile context when they probably should have gotten out. Often these are the fakers that don’t understand what it takes to manage agile delivery, thus they don’t set things up for success from the beginning. Eventually, you’ll see the program / project starting to go off the rails.
If the scenario is one where everyone is entirely new to agile delivery, you would have had to set up a lot of support initially for this to occur. Both at the team level and the management level – there are different techniques and practices that will need to be in place. You’ll have a lot to “Learn” – plus you may need to bring in outside help to coach and / or recruit some more experienced practitioners and inject them into the team. But fundamentally, at the program / project level if you’re in this circumstance then you’re probably lacking agile management skills. Often, those that tend to revert miss this point – so to avoid reverting, you’ll need to look to “Learn”.
Often things go off the rails when things start to work at scale – when we had one or two teams working in an agile way, things were fine and we could manage it in that way. When you have to scale across multiple teams, perhaps multiple vendors and bring things together across an organisation, this is often when things start to go wrong. However, at this level it’s not a team problem it’s a management problem. Guess who’s going to get called upon?
Or, another scenario is that you tried to move too quickly too fast. You just can’t get to agility overnight – it takes time to get to a decent level of maturity. If you planned that you’d be “agile” instantly, or very quickly, then you were probably planning to fail from the beginning.
You probably knew this would happen – they should have just done things the old way from the start. In which case you declare “We’re not doing agile anymore, we’re going back to the way we used to do things”. I dare say that things haven’t really changed to begin with – you’re likely using you’re old practices because you haven’t supplemented or replaced them with 21st century knowledge work management techniques. Perhaps you weren’t sure how these could work together or haven’t seen them used successfully.
In this case, you may have a group of really talented agile practitioners at the team level. In this scenario “reverting” will mean they might need to change their behaviours and practices. They likely won’t want to do this and will either resist or leave. In any case, you’ll suffer from an alignment problem or you might stall because the skills have left the organisation. Either way, things are going to get worse before they get better.
If you’ve gotten to the point of reverting, then there was probably already a problem from the beginning and perhaps you should have tried one of the other options such as “Get out” or “Learn”.
Learn
If you’ve selected this option – congratulations, you’re about to venture into a new world where you’ll have new skills and understanding of how to manage knowledge work. But the good news is that you don’t have to throw away all of your existing skills – things like risk management & vendor management are still very relevant to agile delivery, it’s just that we view these through a slightly different lens.
You will need to give yourself time and space to learn – you won’t be an expert overnight, so make sure you plan to have the capacity / time to be able to learn. If you’re considering taking on an agile project / program in the future, then this is the optimal time. You’ll have some time to learn what you need to do for day 1 when you land on that program. Often managers new to this type of delivery, don’t set things up from the start. You’ll know from you’re existing skill base that anytime this happens, regardless of the method, you’ll be behind the eight ball from the start.
If you don’t give yourself the time and space to learn, effectively you’re really in the “Bluff” space, you just don’t know it yet. Often people talk about learning, but their actions clearly don’t give enough time and investment in learning so they might not realise that they’ll need to resort to the “Bluff”. If you’re in the learn space, please make sure that you’re actions match your intent, otherwise you might find yourself in a world of pain and stress.
If you don’t have time before you start you’re next assignment, you’re probably going to need some help right away. Find an experienced agile manager / consultant / coach and bring them on to set things up that you’re not aware of. Watch what they do, be curious and ask them along the way why they’re doing what they’re doing – you’ll learn a lot this way.
If others on the program are new to this way of working, you might need to organise similar support / capacity for learning for their roles as well. They’ll be supporting you along the way, so you need to make sure you’re all on the same page.
You’ll need to get an understanding of how to manage down as well as manage up. How do you understand what the teams are doing and how it all comes together towards the aligned goals. Plus, how do you ensure that you make reliable commitments to your stakeholders and customers in this kind of world? You’ll need to understand how to manage these expectations in this different paradigm.
At some point in time you’ll want to understand for yourself how agile systems of work can be created and improved on. Your best bet for this is to actually get some formal training on this, sooner rather than later. To really get the most out of this, you should consider becoming a Kanban Management Professional. This is made up of two courses (Kanban System Design & Kanban Systems Improvement) which will give you a practical foundation from which to manage knowledge work and achieve real agility.
Conclusion
If you’re a project / program manager and you’re new to agile delivery you have some options open to you. However, in the end the only two real options are to “Get out” or to “Learn” – the others are only temporary stop gaps. Although there are many different pathways to learning, you may want to learn about Scrum or XP to understand the things going on at a team level. You may also be in an organisation that practices SAFe, in which case its program and portfolio layers are Kanban anyway, however they tend not to go into enough detail about the particulars of how to do this. Plus, you might have other teams working in non-technology based areas and you need to bring them all together. Kanban can do this for you, so why not go to the source and achieve true agility. Read more about in our blogs, or check out our training programs.
Many of my clients and the people I talk to are using Jira – it seems to be the default choice here in Australia and no doubt in some other countries for Agile teams. However, I have personally found the Kanban implementation lacking many things and over the years have had to implement a number of “Hacks” or workarounds to get it to work somewhat closer to the Kanban that I understand. Ideally, if you want to go deeper with Kanban you should be looking at tools like Kanbanize and SwiftKanban, but in true Kanban spirit, we’re going to “Start with what you do now” and look at how you can get more out of Jira.
The “No sub-columns” problem
The Problem
This problem is fairly straightforward, basically, Jira doesn’t allow you to have sub-columns. Here’s an example of part of a board in Kanbanize that has subcolumns:
What is useful about this is that you can very clearly see what items are being worked on and which items are ready for the next step in the process. You might say that “Jira can do that, it’s just two separate columns”, which is true. However, the key to this is that the WiP limit is above both columns. This prevents people from starting new items if the next part of the process hasn’t picked it up – in this example, developers can move downstream and help testers fix bugs, write automation or anything else to get the flow moving again. Usually what happens in Jira implementations is that you put a WiP limit of 5 above each (creating higher overall WiP), or perhaps you do 3 & 2. Either way, what happens is at some point the “Done” column fills up and there’s something else that gets finished from “In Progress”. Where does this go – essentially either you break the WiP limit in “Done” or you have a “Done” item sitting in “In Progress”. Now your Kanban system doesn’t reflect reality, nor is there enough stress on the system to enable change or the increased WiP is throwing out lead times & predictability. Additionally, your data is going to be out – it looks like items are “In Progress” rather than queued up, further putting less stress on the system to fix the queuing and WiP problems.
Possible Solution(s)
The way you can get around this is to add both statuses to a single column – here is the view in Jira for the board settings
However, this leaves you with a view on the board where you still can’t really distinguish between what’s in progress and what’s done:
You can do something like the following below to add the status to the cards on the board so that you can distinguish them:
Here’s a view on the board:
Alternatively, you could change the card colours based on the statuses to give you a better visual:
The “Single Workflow” Problem
The Problem
Again, the problem is fairly simple – essentially you can’t have different workflows on the same board. Here is an example (straight from one of the template Marketing boards) from SwiftKanban:
What we want to show is different work item types with different workflows that are done by the same team or are related services. We want to see all of the work together, reflecting the actual process. You can see in the above, general marketing tasks have a different workflow compared to running events. There’s also different WiP limits involved and we want to control those independently – however I’ll deal with WiP limits more broadly below.
The Solution(s)
One way people have tried to solve this is to come up with “common” workflows for both and put them on the one board. I don’t really think this is a solution – it’s more of putting a square peg in a round hole. The problem with this approach is that neither workflow is a true reflection of what is going on and you run into problems understanding what’s going on in the flow as well as making improvements. I would not recommend doing this.
The only really viable solution to this is to have two separate boards – one with each workflow. It’s not ideal, because you can’t see all of the work together, but at least you can see each workflow and get accurate data so that you can track it and make improvements on the system of work. You may need the assistance from a Jira admin to help with status management at this point as well. Essentially, if you have a Jira project and the Simplified Workflow, all statuses for all types will appear in the drop down. What commonly occurs is that people, whilst in the issue view, update the status to something outside of the workflow for that type. You will need your Jira admin to create a specific workflow for that type for your Jira project so that you don’t get them mixed up and have missing cards.
The “WiP Limit” Problems
The Problem(s)
There are several problems here:
Can’t assign WiP Limit to a swimlane – This can allow you to control the flow based on things like work item type or class of service. See below where “All Marketing tasks” has a WiP limit of 50, whereas “Events” has a WiP limit of 5.
Can’t assign WiP Limit to different sub-columns – although above we talk about putting a WiP limit above a column, sometimes you want the sub-parts to have WiP limits as well (see below under Events -> Execute)
One thing that is positive about the way Jira has implemented WiP limits is that they’ve included minimum WiP limits. This is useful for upstream to make sure you have enough demand for the capacity, but also if you want to implement CONWIP style limits (ie the minimum and maximum would be the same).
The Solutions(s)
Can’t assign WiP Limit to a swimlane
There is no way in the tool to achieve this. The only way to do it is to establish a policy for the board and make sure when you perform replenishment that you do a count of the items to make sure you haven’t gone over the WiP limit for that lane. This becomes more difficult to manage for “on demand” replenishment as there may be other policies in place to allow the team to “pull” work into the system.
Can’t assign WiP Limit to different sub-columns
Here’s one way that you might want to deal with this – in this case I’ve added a WiP limit of 2 to the “Development – In Progress” sub-column / status using a Quick Filter:
Note that the limit is included in the filter so you can do a quick check / count of what’s on the board. I’m not aware of any other ways to make this more visible / obvious that the WiP limit has been breached on the board – it also requires you to actively click the filter to check for problems.
The “No Policies on Board” Problem
The Problem
The policies around how the board works is not able to be attached to the board in Jira. That is, things like “Definition of Ready” / “Definition of Done” can’t be placed onto the board.
Here’s an example in the Kanbanize tool:
What’s important here is that the definitions are present in their context (just hover over the column name to see it). Team members can see this right away and understand collectively “how the work works”. It’s useful for new starters and auditing as well because you’ve effectively made the system policies explicit in the workflow. It also means that when there is an issue, the team can collectively review the policies and make improvements to the system of work immediately.
Jira doesn’t allow you to do this and it often leads to confusion as to how the workflow works.
The Solution(s)
In the days pre-COVID, with a number of the teams I worked with, I actually replicated the boards in Jira with a physical board. You could put all the policies you like on the physical board and ensure understanding and improvements take place. However, since COVID this is not an option for most and we’re more reliant on the tools than ever. The other downside for this is that you’re now maintaining duplicate information and usually one will be out of sync with the other in some way.
Another possibility is to record the policies somewhere else. Teams with Jira often also buy Confluence, so this might be a natural place to store this policy information. However, this is less than ideal as it’s detached from the context of the board and in an “information refrigerator”. Oftentimes this is ignored, unknown and is just not used. It’s not ideal, but it’s really the best option I can think of without a physical board.
The “Single Assignee” Problem
The Problem
Jira, by default, doesn’t allow for more than one assignee per card. Using the Kanban practices, we often see improvements in collaboration and teamwork and often get to the point where multiple people could be working on a card. We should see that reflected on the board so that we can see the work everyone is working on.
The Solution(s)
One way to do this is to add an additional field. Now, you can either add a single field with the user picker, or add a Text Field and include people referenced by the name (using the @ character). Generally, the user picker is better because it has greater query ability and visibility on the cards, but it is restricted to one user. If you commonly have 3 people collaborating, you may want to add 2 additional fields.
You will need to be a Jira admin to add the new field and apply it to the necessary screens:
Once it’s available to projects, the users can see it in their issue view and assign it.
You will need to edit your board layout if you want to see this extra field on the cards:
You can now see collaborators on the board:
The “Poor Data” Problem
The Problem
There are a couple of key problems here:
There’s not many data reporting options – really on Cumulative Flow and Control Chart (the CFD is actually not too bad)
The Control chart is not particularly good
I’ve never been a fan of Jira’s control chart. I find just looking at it can be really jarring and I find it hard to get useful / actionable information from it. For example, here’s an image from Jira:
Note the Y axis – the scale is changing as you go higher up the chart. I don’t know about you, but when I was taught basic graphing skills in high school, this was always supposed to be a consistent scale. This assumes the interesting things will be at the bottom because it has the most real estate on the chart. In reality, it’s probably the items at the top that you need to focus on. This actually distorts your view on the data and limits, or even taints, what you can get from this kind of report.
The other is that it’s using standard deviation to improve “predictability of cycle time”. This assumes that predictability is the goal (“fit for purpose”). You may want to focus on raw speed rather than predictability, or perhaps something else such as profit / costs. This won’t necessarily help you with that. My opinion is that this is a manufacturing take on using data, rather than one that is specific for knowledge work where the Jira tool is aimed. I’d prefer to see other metrics such as percentiles so that I can make a decision on what to do based on the purpose of the team / service.
The Solution(s)
My first suggestion to anyone who’s using Jira and can’t move to another more suitable Kanban platform is to install the Nave plugin for Jira. This has fantastic metrics and will allow you to make a myriad of improvements using the data.
It has histograms and scatterplots for Cycle Time and Throughput, plus it has a great “Aging chart” where you can see problems in the system right now. One thing I find really useful is that if you use the “Flag” feature in Jira for blocking items, you can get additional data for this.
I know there are some people out there that can’t add plugins for various reasons into Jira. If you’re one of those people, then here’s another potential option for you (although it’s a bit manual). For each status, add a field with “Date Time Picker” type.
Create an automation to update that date every time a card moves into that status on the board:
Then, when someone moves the card, it will update the date:
You can query the data and pull out the dates you require using the CSV export on the “Filter results” screen. Then, you can use something like Troy Magennis’ Cycle Time Calculator spreadsheet to copy the key dates into which will produce charts for you. You can find the charts on his Github page http://bit.ly/SimResources
The only other option is to call the Jira APIs and extract the data yourself and create the visualisations – but if you’re doing that, you may as well buy the Nave plugin.
Conclusion
That’s all for now folks – there are other gaps, but I haven’t covered everything here. If there’s anything important that you think should be covered, please let me know.
Jira has a very basic Kanban implementation – it may be useful to get you started, but it will continue to hold back the maturity of your organisation unless you do some of the “outside of the box” solutions above. For anyone using Jira for Kanban, I would recommend using Nave. If you can, you might want to try one of the other tools such as Kanbanize and SwiftKanban which have Kanban front of mind when they designed the tool for those looking for greater organisation maturity without the workarounds.
I wrote this article a number of years ago, but I’ve been thinking about it again recently, so I thought I’d republish this with a few additions.
I have been pondering the Kanban commit point for some time and it occurs to me that there is a striking similarity between this and the formation of contracts in the eyes of the legal system. I’m taking this from my perspective here in Australia, however I believe that basics of contract law are very similar in many western legal systems. In all cases, if you are seeking to rely on opinions of the law applicable to you, please consult with your local legal professional. I found this as a useful way of understanding the commit point – I hope you do as well.
One of the key reasons for understanding this is the importance of the commit point to the operation of a Kanban system. This is the point from which we measure the Lead time and start to make improvements. It’s the point at which the understanding between customer and service provider have or should be of a common mind in terms of what service they’re getting and when they’ll get their output. In contract law this is referred to as a “meeting of the mindsâ€. This sounds simple enough, but from anyone who has been practicing service delivery in practice will know, real life situations are not necessarily simple.
There are some basic concepts in contract law that may assist Kanban service providers to better understand their customers and ultimately provide an improved service.
Offer & Acceptance
Two of the key aspects of contract law are offer and acceptance. The third is consideration but for the purpose of understanding when Kanban commit point, this is not necessarily important. For the purpose of this conversation, where consideration is mentioned take it to mean simply – consideration from the customer the price paid and for the service provider the consideration is the service. Just as in contract law, I would argue that the Kanban commit point requires both offer and acceptance to be in place in order for the commitment to be made. There is often a lot of confusion because people don’t active listen for acceptance and assume that because something is on a backlog it’s committed (see also Use Options Instead of Backlogs).
Offers
This is where one party – it may be the customer or the service provider in a Kanban context, communicates to the other the basic terms. For example:
Scenario 1
Customer offer – I’ll give you $100 if you can deliver me a widget by the first Monday of next month.
Scenario 2
Service Provider offer – Advertises that they can deliver anyone a widget of specification AxB for $150 within 10 business days of you placing an order on their website.
Note at this stage, there is no actual acceptance of either scenario. In the Kanban world this then remains an Option of the person receiving the offer.
Additionally, the offer needs to be communicated to the other party – in terms of the Service Provider offer this could be direct to a particular customer, to a class of customers or even the world at large.
Acceptance
This is where the party receiving the offer clearly communicates that they agree to it (verbally, written or through conduct). To continue the examples above:
Scenario 1
Service Provider acceptance – Yes, we’ll get this for you by that date.
Scenario 2
Customer Acceptance – Logs onto the Service Provider’s website, fills in an order form and clicks submit.
The form of the communication can vary from something as a simple nod of the head to a formal written contract with all the detailed terms and conditions. This is a key thing to examine in your Kanban system – are your customers getting a clear signal of the acceptance? Are they even aware that you have committed and do they properly understand what this means? Are they mistaking commitment for a “receipt of the offer”?
Counter Offers
In many circumstances, a party may come back with a counter offer, which similarly must be accepted before the contract is formed / Kanban commit point is reached. To continue the original examples:
Scenario 1
Service Provider Counter Offer – If you give me $150, I’ll deliver it 3 business days before that.
Scenario 2
Customer Counter Offer – I want a widget with specification AxC, I’ll give you $200 if you can deliver it in the 10 days.
Of course, at that point you may get count-counter offers and it may go back and forth until an agreement is finally made. For example, in Scenario 2 above, the Service Provider might respond by saying, “I’ll need to retool to provide that specification, therefore I can’t get it to you in 10 days, but 15â€. In Scenario 1 above, there may be indications that a different class of service is involved – this may become a fixed date class of service. This is where misunderstanding can occur – it’s worthwhile summarising what the work item / outcome being agreed to is before committing it to your Kanban system.
Keeping it small
A problem that commonly occurs in practice, which Kanban systems try to control, is batch size. However, often contracts are written on the basis that it’s simpler to go through the negotiation process only once and then wait for the end outcome. That is, the contract formation process is often based on large batch. However, you might want to consider the shape of the offer when creating contracts. This will allow your Kanban system to keep its options open for longer and preserve flow. Of course, you may lose some of the certainty that large contracts bring to a business – but with some additional negotiation as a Service Provider you should find a way around that. Indeed, the regular reliable delivery that often results from Kanban implementation, will often negate the need for larger batches.
Examples
These are further offer / counter offer examples that demonstrate keeping batch size small:
Scenario 1
Customer Offer – I need 1000 widgets at $100 each, but I’d like them in 5 months.
Service Provider – We can provide a maximum of 300 widgets per month. We’ll accept orders for 300 or less widgets per month at $100. Please notify our sales staff 1 week prior to the beginning of the month as to how many you need and we’ll deliver these by the end of the month.
In this scenario, the Customer tells the Service Provider that they’re happy with that arrangement because they get some of their widgets early. They then place orders on the first, second and third month of 300 and for 100 on the fourth month.
Scenario 2
Customer enquiry – I need 10 widgets of specification AxB, 10 of AxC and 20 of AxD, what can you provide?
Service Provider offer – we can produce a maximum of 12 widgets every 10 days. The price for AxC specification items is $200 and the price of AxD is $250. Our online order form will prevent more orders coming in for that 10 day period once we have reached our maximum and will accept an order for the next period up to 10 business days prior to the period commencing.
Customer response – No one else can make type AxC & AxD, plus your AxB widgets are of higher quality than your competitor, so we’ll go ahead with that. Expect to see our first order shortly. They put in an order for 10 AxB and 2 AxC in the first period, 8 AxC and 4 AxD in the second period, 12 AxD in the third period and 4 AxD in the fourth.
Breakdown
In both the above cases, there are multiple contracts at play. Each order is a separate contract, under the terms negotiated earlier. The first part of the negotiation is around the terms of contracts, as each order is placed a separate commitment is made. Until the order is placed and accepted, these are options for both the customer and service provider.
In the Scenario 1, there are flow control mechanisms being put in place. A maximum limit is described as well as the timing.
In the Scenario 2, the order form is shut down preventing the acceptance from being communicated – this is baked into the system of work ensuring the service provider doesn’t committing to items outside of it’s capacity.
Possible drawbacks of this approach are if it is no longer fit for purpose for the customer to break things down into smaller pieces of work, then you should be prepared for your kanban system to have a larger batches and the associated variability that comes with this. Often, the variability will result in higher costs to cover the inherent risk associated with it. You may wish to describe / quote these as different terms to your customer to highlight / make visible the risk of large batch. However, there may be reasons such as competitive forces at work in your context that prevent this, so of course you should also pay attention to these. Although, this does raise the question of whether this is the right type of option to pursue for your business.
Upstream Kanban
This is a different type of negotiation than normal service delivery. This is about exploring options and assessing risk. The nature of this kind of work and outcome is different, as are the parties and as such you should consider a different kind of agreement here – generally speaking, you’re “buying information†to assist with decision making.
If you’re part of the same company, often it’s for providing leaders the information they need to make the key decisions around the strategy for their company, as is often the case with product development. In the context of providing services to external clients and in the case of specialised or “one off” products, often understanding what the parties want is an essential first step. An “Idea” is often not enough to make a reliable commitment to deliver by – at least the variance for such things are often so large as to provide no solid guidance as to whether a commitment can be fulfilled.
Possible solutions to this problem are to agree to a different kind of work – it might be based on time and materials or constrained through timeboxes, number of experiments or other means. In the same way as the downstream kanban systems described above, it should be clear prior to pulling the Upstream Idea for exploration that the requestor and service provider both understand that this is the necessary first step in understanding what is to be delivered. The terms of this can also stipulate either the framework for delivery later on but should keep it options open for both parties – after all the idea may prove to be invalid for any number of reasons. Alternatively, it may leave this open for later agreement once the details of the Idea are known.
Service Delivery teams should not pull Options through the upstream discovery process without this in mind – that is, Ideas are options and should not be committed to automatically. It may also be the case that downstream systems will receive work items to explore this upstream process – you may need to ensure you have capacity to give the upstream process to ensure overall flow.
Cadences
Kanban has cadences set up for dealing with this kind of thing. Typically, the “Replenishment” meeting is where work items will be committed to. Thus, prior to having these meetings, it’s often useful to understand the details above so that this meeting is run relatively quickly with a pre-understood way of working together (essentially, the “terms”). The key parts will become “system policies” – such as “ready to commit”. For upstream, the commitment would be “to explore option A”, whereas for downstream its to deliver the final service. During these sessions, usually we move the ticket to represent the work over the commit point – a signal to all involved that the contract / agreement has been formed.
Summary
There are some similarities between Kanban commit points and contract law – I hope you find it useful. Indeed, gaining a clearer understanding of the request will assist in providing services that are fit for their customer’s purpose. This “meeting of the minds†is important and may be something you’re overlooking in your Kanban system. Accepting items of work onto your system of work without understanding the nature of the agreement may well expose your business & kanban system to potentially avoidable risk. Make commitment policies explicit and well understood and build them into your process for a better outcome for all involved.
The use of explicit policies will help you to scale. In the same way that protocols help technology to scale, such as the way the internet has been designed, explicit policies in Kanban systems will help you scale your services. Using explicit policies will not only help your managers ability to better manage their services, it will also benefit the teams involved by allowing them to further “self organise” to get the work done, guided by the policies.
When I refer to an explicit policy, it means a rule or protocol that determines / describes how the system of work operates. Explicit policies are known by all and consistently followed by those operating within the system. They’re effectively the “rules” of the system of work.
When scaling, I tend to think of the internet – here’s something that has scaled to the extreme with many people around the world now using it as part of their daily lives. So long as you follow the protocols defined by the system, you can become a part of it quite easily and start to interact with the other parts of the system.
Examples of policies are things like definitions of ready and done, WiP limits, the order in which items are pulled through the system and many others that may be customised to your work systems needs. By making the clear and understood by all, it allows teams to “get on with” the work without having to have detailed discussions at various potential touchpoints. The key here is making sure that there actually is that common understanding of those simple rules and practices that are adhered to by all. To assist with that, keep them simple – don’t make them massive “pre-flight” checklists that are too detailed to understand. Put them on the board or in other places where the team will see and refer to during their daily work – allow team members to see them and do a “spot check” when they’re moving a card. Having them hidden away in a large document that is rarely used, or only used for “audit purposes” won’t be sufficient.
Another key part to it is that these rules should never be 100% static – they should be revised. Through the kanban feedback loops, you’ll discover improvements and you may even iterate through STATIK to find new or updated policies that need to be applied. As these mature, you’ll more of them apply to situations involving scaling.
When scaling kanban you’ll start to move to different levels of abstraction for services across the organisation. At these different levels, you might discover new and different policies and making them explicit helps flow at that level. Furthermore, you might start to scale out – understanding how teams interact by coming up with “rules of engagement” (policies) that describe how teams collaborate to achieve a collective service goal.
Managers no longer need to direct teams in how they work, but they work to make the policies and interactions within the system explicit and understood so that the teams can self organise around the work. Being explicit on your policies when scaling up, across and down the organisation will help make it easier for all of the groups to interact together.
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.
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 Type
Class of Service
Lead time
A
Standard
Average lead time of 12 days, with 85% completed within 16 days.
B
Fixed Date
Average lead time of 6 days, with 90% completed within 8 days
B
Intangible
Average 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.
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!
