Lean into the stressor

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

 Posted on January 21, 2021 by

 Kanban

     ,

Kanban Campfire Retrospective

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

 Posted on December 8, 2020 by

 Agile, Kanban, Retrospectives

     , ,

Is it reasonable to work on 1000 things at once?

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

 Posted on November 30, 2020 by

 Kanban, WiP Limits

     , , ,

Should cards move backwards on a Kanban board?

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

 Posted on October 29, 2020 by

 Kanban

     , ,

Upstream and Downstream comparison

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

 Posted on October 20, 2020 by

 Kanban

     , ,

Scaling Agile Community Meetup Adelaide – Scaling Agility across your enterprise with Kanban

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

 Posted on October 17, 2020 by

 Events, Kanban, Meetups

     , , , ,

If only we had better estimates

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

 Posted on October 6, 2020 by

 Agile, Kanban

     , ,

The power of “Yet”

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

 Posted on September 10, 2020 by

 Approaches

     , ,

Kanban applies over the top of your existing process

One of the most common myths I hear about kanban is the “Are you doing scrum or Kanban?”. The assumption is these things are mutually exclusive. Kanban is not something that you “start with” – you start with your existing process – whatever that is – and apply Kanban over the top.

I’ve found that one of the sources of these misconceptions, at least in my local market in Australia, is the use of tools like Jira. When folks who are new to agile see the option to choose a scrum or a kanban board, they immediately think that the two things are mutually exclusive. Even though there may be a few articles floating around saying otherwise, the effect of this mechanism in the software has lasting impacts on teams. These impacts take some time and effort to unwind and can prevent teams from maturing to greater capability.

Indeed, the first change principle of Kanban is “Start with what you’re doing now“. This implies that you have an existing process. It doesn’t have to be massively complicated, but with whatever you’re doing in your business you can find services and the process to create / provide them. When applying Kanban, your looking to this, examining the key problems, and starting the evolutionary road continually becoming fitter for purpose.

Kanban can be applied to your existing services. Although it was originally trialled / used in software teams, you can use it for your existing services for all kinds of knowledge work. For example:

  • Marketing
  • Sales
  • HR
  • Legal
  • Product Development
  • Technology
  • Operational support

Indeed, often you may have a purpose or outcome that requires the interaction of many / all of these services. Kanban not only applies to the application of these services individually, but how these services interact.

You don’t need large transformation teams, just a little kanban knowledge and you can start tomorrow! If you’re not sure how, come along to one of my upcoming courses and we can get you started.

RETURN TO BLOG

 Posted on September 7, 2020 by

 Kanban

     , ,

Story Points – should you use them?

Story points is a journey that I started about 15 years ago. For teams starting out with agile, many think that you have to use story points as a “sign” of “doing” agile. I’m not so sure that’s the case. I first started with story points years ago, but over the last 5+ years I’ve started to stray away from them. I question the value of this technique and so should you.

Story points are relative values of sizes of work – an estimated value. I like to go back to some old texts like Mike Cohn’s “Agile Estimating and Planning” when understanding what were some of the original ideas behind story points where he talks about a “A user story estimated at ten story points is twice as big, complex or risky as a story estimated at five story points”. This implies that “size” in the estimate includes not just how big it is, but how complex something is and if there’s any / how much risk is associated with it. Now we’re dealing with multiple dimensions in the one value – this overload of meanings can often lead to issues.

The other point that gets me is that story points is an estimate. It’s our best guess at what might happen. When you’re measuring velocity your counting up how big “you thought things were”, not how big things actually were. All the bias and unknowns your team can’t see don’t factor in at all. For me, I’d rather deal with the actuals that describe team capability rather than guesses when making commitments.

There’s also another level of indirection with story points – at the end of the day your customers don’t care about how many points something is. They care about how long it’s going to take and / or how much it will cost. To figure out duration (and ultimately cost), you need to use something else known as velocity – ie how many points the team can get through in a given timebox. If you’ve been around agile teams for a little while, you’ll notice that their velocity is often not constant – you can often get a “saw tooth” chart if you track velocity per sprint. So how do you figure out what the estimated velocity is? Well, often teams take a “3 sprint rolling average” to figure that out. My big concern is that there’s so much indirection going on here that it can be hard to predict accurately using this mechanism.

Where I find story points valuable, is where teams, particularly when they’re just starting out, talk about the work and get an understanding of how big items are and “where the dragons are”. The conversation and understanding is valuable, the estimate becomes fairly meaningless after that. Indeed some teams I’ve worked with who were already using story points, all I cared about is that they wrote a number on the card. To me, that was a signal that they had that valuable conversation.

So what should you do instead? Perhaps just count the number of done stories or work items per timebox. Perhaps you don’t need to use the quasi-standard 2 week sprint boundary either – count items per week or per month. That’s what’s known as throughput or delivery rate. Getting an understanding of throughput and how to use it can be useful, because you get away from the agile abstraction theatre and start talking about things in the same language as your customers. Some time ago, Neil Killick stopped by the Melbourne Kanban Meetup to talk about slicing heuristics – you might want to consider this in lieu of doing story point estimates.

Should you be using story points? If you get some value out of them, then yes go right ahead. But please don’t do it because you think you have to in order to “be agile”. Here’s a safe to fail experiment to try – don’t change anything except look at you throughput count over the last several time periods. If you don’t have that data collect it for the next month or so. Compare that to story points – if you think you can predict through throughput, or lead times for forecasting, then perhaps you don’t need to estimate in points, you can use your actual data!

RETURN TO BLOG

 Posted on August 28, 2020 by

 Agile

     , , ,

Focus on core problems

Focusing on the problem is something that I continually come back to and remind myself of. There are so many instances that I hear people where they understand a solution and are determined to bend the world to their view of the solution rather than focusing on the problem. Staying in the problem space for a little longer and really exploring and understanding the problem(s) is really valuable, rather than prematurely converging on solutions.

One of the most common things I’m hearing nowadays in technology is around the use of large frameworks. For example, I’ve often heard things like “just install SAFe, SAFe has this feature so you just need to apply it”. Thanks, but I don’t think that’s very good advice. I don’t want to install a large framework to solve my immediate problem. Even if you’ve already bitten the bullet and installed SAFe, do you really think your context always requires the “just follow this recipe” approach? Do you think the framers of SAFe understood your customers and your business when they came up with the framework? Should you really use a “one size fits all” approach? No, this is a solution – let’s spend some more time in the problem space.

Another space I think about this is in sales. I’ve come to learn over the years that sales is about listening to customers and really understanding their problem and their context. Staying in the problem space, listening and asking probing questions only when required is really important. Your customer will tell you about their key problems if you let them and help them with a little bit of guidance. My sales coach has a wonderful article about this entitled “Shut up! Let your customers speak and win more sales“.

Something that I really like in the agile space is the work done by Neil Killick – particularly around slicing. Again, he encourages folks not to converge into the solution space too early. In his article “The essence of story slicing in an agile environment” Neil asks the question of “What are some options for delivering value to a customer as soon as possible”. I like that for a number of reasons – one is that he’s talking about options – again not yet converging, but exploring the problem space. I’ve talked about options thinking in a number of my blog posts as well. He also uses simple techniques for doing this – you just need a basic understanding of English (or whatever language your customer uses!) and you can start to explore the problem space. His focus on customers and timeliness is also another great aspect. He stays in the problem space for some time, finally choosing an option on which to focus, then, and only then, starting to think about solutions.

I also like Kanban’s approach to this. One of the early steps in STATIK (Systems Thinking Approach to Introducing Kanban) is to understand points of dissatisfaction. Both from a team perspective as well as a customer perspective. This is about understanding the core problems before installing a solution. Stay in this space for a little while – explore it, listen and ask those poignant questions. What’s even more powerful is that this is not the end of the process. Once you’ve implemented the solution to those problems, new problems will surface. Iterating through the process regularly will ensure you’re continually focusing on key problems. If you want to learn more about this, come along to my Kanban System Design course and learn all about it.

The consequence of not doing this can be quite grave. You could tank on that sales call, even lose the potential customer. You could waste your time installing a solution but realise that you haven’t solved your problem. Time is the one thing you can’t buy more of, so you need to use it wisely as there are opportunity costs of focusing on the wrong thing. There are not only customer impacts, but there are potentially team impacts. Wasting your team members time can be frustrating – usually the best folks will tend to leave and find somewhere else where they can align better to their customer’s purpose and see the fruits of the labour valuably impacting peoples lives.

So please, don’t prematurely converge on solutions. It can be hard, but stay in the problem space for a little longer. Listen, question, understand. Focus on the core problems and win!

RETURN TO BLOG

 Posted on August 24, 2020 by

 Approaches, Kanban

     , , , ,

Kanban board design: sub-columns

Some years ago, I learned about a key part of Kanban board design. The usage of sub-columns and WiP limits is important to get right to help your process and ensure transparency. This is really simple to do on physical boards, but if your electronic system doesn’t have this basic capability, it can really only support very low maturity Kanban implementations.

Why would I use this? Often there may be different skills / capabilities within the team and showing where they are in the overall process will signal those downstream when there is something available for them to work on.

In the above you can see an example of what I’m talking about taken from the SwiftKanban product (I zoomed in on one section). You can see Develop is split between “In Progress” and “Done”. This tells us when things are under development, but also tell the testers downstream when items are ready for them to pick up. This allow you to put a WiP limit on top of both these sub-states to ensure developers don’t pick up additional work if there’s already enough queued up for the testers.

If you don’t have something like this, then you’ll likely be pulling more WiP into the system, or you can’t transparently see where items actually are. For example, consider if I instead had separate columns for “Development In Progress” and “Development Done”:

In this case, both columns have a WiP limit of 5. Another example is where we reduce both to ensure no more than 5 overall:

In the first example we just made both items have a WiP of 5, which increased the overall WiP in the system. This can be detrimental as lead times will tend to increase and developers will focus on starting more work rather than helping testers complete work.

In the second example we reduced the WiP. In both of these examples, we’ll run into problems with the “Done” column filling up. Let’s say a developer pulls work into “Development In Progress” and keeps moving items into Done when they’re ready. At some point, using the second example, we’d fill up the WiP of 2. The we end up with items in the “Development – In Progress” column that have actually completed the development. This is impacting transparency and brings some confusion to those doing the work who may have to figure out where things are when the “Development Done” column frees up again. Plus you don’t really get that sense or feeling of flow.

Furthermore, even if you have sub-columns, if you put the WiP limit on those, rather than controlling from above you will run into the same sorts of problems as those described in the last two examples.

Having this sub-column split also lends itself to other modifications. For example, you may have a situation where testers / downstream people are a “non-immediately available resource” and you want to make sure that when they are available, there’s plenty of work for them to do so that they’re not sitting idle. Furthermore, you still want to remove burden from developers so that they don’t task switch. You can increase the WiP limit overall for Development to allow for a larger buffer before the testing bottleneck, but keep the “In Progress” low to ensure developers are not overburdened. For example:

More detail:

These kinds of modifications are really easily done on a physical board, just move things around how you want them designed. There are a number of tool vendors out there that do these basic Kanban functions – if yours can’t then you might want to look for something else as you’re limiting the flexibility and maturity level of your team. Here are the same examples in Kanbanize:

And LeanKit:

There are many design improvement that you can do to your kanban system to better enable flow and ensure that it’s predictable. These are some of the little tips that I give in my Kanban Management Professional courses. For further information and registration, please refer to:

 Posted on August 14, 2020 by

 Kanban

     , , ,

Evogility