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

     , , ,

Are product owners a broken concept?

The question of using product owners is something that has plagued me for some time. I’ve always thought that there’s something not quite right about the concept and through my experience with this over several years, I have come to try and avoid formalising the product owner role where I can. When I say product owner, I mean it by the term used in scrum (see the scrum guide), as distinct from a product manager.

Some of the key problems I have with it include “The product owner is one person, not a committee”. What I often see is that this becomes (whether rightly or wrongly) a central point for decision making. Often this is a bottleneck and can start to disable flow in uncertain situations. For example, what happens when the decision maker takes leave and goes on holidays for a few weeks? What if this is unexpected medical leave and there’s no handoff? Usually what happens is decision making is greatly reduced or stopped and the organisation suffers from this.

Furthermore, I often consider “what if the PO is wrong” – what happens in this situation? I’m reminded of David Marquet’s work in this area where he encouraged leadership at all levels and decision making was more distributed to where the appropriate amount of information to actually make that decision resided.

Another issue that I have with it is at the adoption stage – in order for scrum to be effective they need experienced product owners. These kinds of people are not necessarily grown overnight and really need some intrapreneurial tendencies. It can often take several years to grow a good product owner. With many organisations, I often see people granted the “Product owner” role, but they don’t have any, or very little, understanding of what this is and how to make it a success. Often organisations pour a lot of time and money into this, which although it may payoff in the future, you are likely to have better spent that money improving the products and services for customers and getting them out to market more rapidly.

Another problem I have seen is the “part-time” product owner. If they are chosen from the business they’re often given these duties in addition to their “day-job”. Teams rarely get enough time to discuss things with the product owner and often their absent for most of the time. Teams flounder like a rudderless ship in a storm. In order for new product owners to learn they need to immerse themselves in their product initiative and take some of their day job tasks away. There is a balance here, because you want them to continually be in contact with the broader aspects of the business, but their focus needs to be correct.

I guess another thing to consider is whether to bring in outside help. In which case you have to deal with the fact that the folks coming in likely know how to be a product owner, but don’t understand your business. It will take them some time, perhaps a year in larger companies, to form relationships in your organisation and be able to understand the inner workings of your product or business. There’s an up front investment here and you have to wonder if the pay off will justify the outlay.

In larger organisations, particularly when you look at organisations that adopt SAFe or other like scaling frameworks, you tend to find that the product owner at the team level does not really resemble what scrum had intended for this role. Essentially, there’s little decision making at this level as things are usually sliced at a higher level. I’ve found that often in this context you’re better off making sure you’ve got a good Agile BA who understands the domain and can detail the work coming into the system who can work collaboratively with stakeholders around prioritisation.

Additionally, the statement “For the Product Owner to succeed, the entire organization must respect his or her decisions” is often hard to achieve. Many organisations appoint puppet product owners with no real authority, or what authority they have is often overridden.

Another point about the product owner is they often become a proxy sitting between the team and the customer(s). Although POs are intended to be this, which can work in some circumstances, it’s still good for the team to get out and interact with users and customers. Again, the PO is a single point of failure and only applies their own single lens to information coming through the system. Having different perspectives for customer / user / stakeholder interaction can provide a richer feedback loop and allow you to pick up on nuances and opportunities you would otherwise miss. I recall the XP framework being big on ensuring the team are talking to the customers / users. I think this is important and often a product owner, especially if they’re learning the role, may get in the way of this.

Are product owners a broken concept? In view of their implementation is often very problematic, enough for me to question the benefit of and avoiding their introduction wherever possible. I’m not saying the “committee” is the right option either – I really think you need to consider other options. If you haven’t introduced them, it might be worthwhile considering first ensuring your decision making policies are explicit and pushed down to the appropriate level in the organisation. See how distributed decision making can work and enhance you overall organisational agility before centralising it and introducing a product owner concept.

RETURN TO BLOG

 Posted on July 29, 2020 by

 Agile

     , ,

Escalations create longer waits

Escalations, whilst seemingly useful for creating a timely response, are actually a sign that there may be some underlying problem with the system of work. This can lead to a reinforcing loop of behaviour that will continually create longer wait times for your customers. You might not notice this at first, but some organisations get into a position where you have to escalate just to get anything done.

Escalations occur where teams run into issues and they need to bring it to the attention of various levels of management to get something done. There may be an urgent need that the service providing group in your organisation is not aware of or not aligned to.

Lets take an example where a team are running at their current capacity, as per normal, and a new request comes along. Although it may be more urgent, this team is already at it’s WiP limit and can’t take on anything more. They may not have different classes of service, or if they do, often these class of service items have already reached their WiP limit. An escalation occurs from the new requester. The team are asked to ignore their WiP limit “just this once” and fast track this item.

The result of this is that the team now have more WiP in their system. The lead times for every other work item are going to start to increase as the team fast track the escalated item. Lead times are getting longer and other teams waiting on work start to see their service level expectations slide past. So what do they do – they escalate. Now there are multiple escalations going on for the one team. Hopefully, sanity might prevail, but in many cases, this often leads to context switching by the team as they now try to service the other requests.

All of a sudden the team are now starting to struggle with all of the escalations and new requests. So, in an effort to try and get things under control, their manager attempts to reduce requests coming into the system. However, requesting groups also have obligations to meet, so guess what, they escalate.

What’s happening here is a self re-enforcing loop that see’s the level of service spiral out of control. Here’s a small diagram depicting what’s going on:

Urgent work, if handled correctly with WiP limits and classes of services can be manageable. When you get escalations for urgent work which ignore WiP constraints, you will likely fall into this kind of problem.

This is one of the things I learned from my Okaloa Flowlab training – if you’ve ever played the game you’ll get these kinds of insights and more (it’s a great experience). I’ll be including it in my upcoming Kanban System Design courses for those who want to experience it.

Try and break the loop by changing expectations to avoid further escalations, preventing urgent work coming into the system, or re-examining your capacity and policies around urgent work. They may also be hiding a larger problem in the organisation – around KPIs or lack of alignment more generally. Once you get the immediate problem under control, you may need to consider tackling the larger underlying issue.

RETURN TO BLOG

 Posted on July 22, 2020 by

 Kanban

     ,

Using Lead Time Distribution Charts for Improvements

Lead time distribution charts are very useful for making improvements to your system of work. Understanding what to target and when will ensure that you get the best “bang for your buck” in improvements. Making these improvement will help you stablise your system of work and improve predictability which will open the door for the next level of possibilities for your organisation.

Here’s an example of a lead time distribution chart:

To recap what your looking at here (for more info, please refer to https://evogility.com.au/lead-time-distribution-charts/):

  • X-axis: Number of days from when something was committed to, to when it was completed (ie the Lead Time). Note that in the above they are recorded at 5 day increments. So, the value for 10, represents the number of items greater than the last measure (5) and 10.
  • Y-Axis: Count of the number of items that fall within that range. The number at the top of each column represents the total count for that item.

Lets look at how you can use these to make improvements.

Long Tail

You can see there are a number of items coming through at the 70-85 day mark. We need to be genuinely curious about what is going on here. There may be a couple of things going on here:

Different class of service – Perhaps these are items with a low cost of delay that are continually getting pushed back. Perhaps it’s worth capturing this in a different lead time chart so that you understand the lead times for each class of service independently.

Different work item type – Similar to class of service, maybe this is the lead time for a certain work item type – it may be naturally longer than the others. Again, you might want to separate those out into their own chart and create different lead time expectations and control WiP for them.

Refutable demand – Looking at these items, is there a way that they can be identified and not accepted in your system? Is their cost of delay valuable enough or is there some other organisational imperative that is pushing this into your system needlessly. Keeping out undesirable work and not “auto-commiting” to every piece gives you better ability to manage your system.

External dependencies – This is often one of the most common causes for delays – a dependency external to your control blocks these work items. Is there a way you can remove the dependency (perhaps you can upskill one or more of your team to do this work)? If you can’t do this, then is there a better way to identify the dependency early and coordinate with that group to avoid the delays?

Once you get rid of that outside tail element, the end of the tail shifts, and we’re now looking at the 30-50 day range. All of the above are still applicable. With a larger volume of items, you might want to also try:

Blocker Clustering – There might be multiple different causes for blockers that you want to explore and prioritise for removal / reduction. See this article by Klaus Leopold and Troy Magennis to learn more on blocker clustering.

Once you’ve gotten through these things, congratulations, you’ve now “trimmed the tail”, let’s look at what else you can do.

Simple Requests

Look at the left hand side of the chart. The bulk of the requests are in the 10 day or less mark. There may be something you can do here:

Automation – There are lots of these items and they are fast, perhaps they don’t necessarily need a lot of brain power to actually get done. A subset of these you may be able to remove from your request queue through automating the process. Try to categorise these requests and look at what your automation options are for these.

Avoidance – Avoidance of these requests might also be possible. A great example of that is an IT service desk that put together a process for people to automatically, or through their manager, reset their own password. This reduces a great deal of calls to the service desk and frees up time for more important requests.

Work Item Type – As we saw in the XIT case study in our Kanban System Design course, you can often identify a particular work item type and negotiate it out of the system.

All of the options above free up capacity for your team to do more “knowledge work”. That is, the kind of work that is human intensive and valuable to customers. These improvements will help you “trim the tail” and make it more predictable.

If you want to learn more, become a Kanban Management Professional (KMP) by completing these courses:

RETURN TO BLOG

 Posted on July 15, 2020 by

 Kanban, Metrics

     ,

Kanban Unconference

On Thursday 9th July 2020 the Melbourne Kanban meetup, the Sydney and Wellington Limited WiP Society meetup groups got together to conduct a Kanban Unconference.

In conjunction with my co-facilitators Ben Hogan and Silke Noll, we undertook to do a virtual unconference on Kanban with our meetup groups. An unconference is quite simple, we make up the topics on the day and there’s a few basic rules to it:

1. Whoever shows up are the right people.
2. Whatever happens is the only thing that could have.
3. Whenever it starts is the right time.
4. It’s over when it’s over.

Remembering the “Law of two (virtual) Feet” which means if you’re not getting or giving value in some way, you’re free to continue to move around.

Here’s the schedule we came up with:

Here’s a great shot of Ben facilitating the session:

We’ve done this before in person in the Melbourne Kanban meetup, but never done it virtually. We used VideoFacilitator and Mural for the tools and they were perfect for this kind of setup. If you’re thinking of doing an virtual unconference yourself, you should check these out.

I really enjoyed the session and I think my co-hosts also got equal enjoyment from it. Our attendees also responded positively to this. It’s more personal than a regular conference, and with everything being remote lately, we’ve been doing a lot of presentations in the meetup, so small conversations were a welcome change. It was so good, we’re thinking of doing this on a slightly larger scale in the future.

Here is a link to the output from the session:

https://www.dropbox.com/s/e8yiziawhmq75fr/AU%20NZ%20Kaban%20Unconference%209th%20July%202020.pdf?dl=0

RETURN TO BLOG

 Posted on July 12, 2020 by

 Events, Kanban, Meetups

     , ,

Using Work Item Ageing Charts

Work item ageing charts are particularly useful for solving issues that are currently impacting your teams. Whilst other charts such as Lead Time Distributions and Scatterplots can be useful for coming up with countermeasures for issues that you experience in the past, Work Item Ageing charts are useful for the present issues.

Lets look at an example below:

To break it down:

  • X-Axis – This is the date that the item was started
  • Y-Axis – This is how old the ticket is (how many days since it was committed to)

Each dot represents a work item that is currently in progress.

For the purpose of this post, lets assume that our lead time expectation with customers is 90% within 50 days. We can see one work item approaching 80 days! This is something that should have been actioned earlier, but without a chart like this we may not see those things. This will likely need some customer alerts if that hasn’t already happened and some work to regain our customers trust. Although it falls within our 10%, it has far exceeded the expectation and needs rapid action.

The two items approaching 40 days also need action as our lead time is fast approaching. This case is not as dire as we are still within expectations, but as a leader you will need to offer support to remove blockers, plus you might also want to think about other ways to get this done. For example, you might need to increase their class of service to get the team swarming on these to make the date.

The item that’s at 25 days is not necessarily a problem yet, but may be a problem in the not too distant future. Keep an eye on this, but no need for anything drastic yet.

The Work Item Ageing chart is really useful for helping you see issues that are in your system right now. You may need to create policies to ensure that your lead time and other customer expectations are being met. It can also be useful for ensuring that you have a stable and more predictable system to benefit your customers.

RETURN TO BLOG

 Posted on July 3, 2020 by

 Kanban, Metrics

     ,

Option / Backlog item expiry date

Backlogs often become a dumping ground for ideas. Some of those ideas are good, others might need some exploration before we understand if they’re worth it or not, but many of them are often not worth pursuing. After some time, it can be cumbersome to start to trawl through an ever increasing backlog to find the right value item that you should start to explore.

If you’re using a backlog and not thinking of them as options, please refer to an earlier blog post that talks about using options instead of a backlog (from here on, I’ll refer to them as options):

https://evogility.com.au/use-options-instead-of-backlogs/

Options have a value at a point in time. Generally they have a cost of delay. There’s also a cost of retaining options for too long – think about a options list that has a thousand items in it, how long is it going to take for you to find the top 10? You need to regularly trim your options list to make sure it’s lean and gives you insight into what are real options you need to spend your time on.

Put it another way, if you’ve had an option in your list for a year and haven’t taken it up, how likely is it that you’re going to take it up in the next year? For that matter, if you’ve had an option in your list for six months and not proceeded, how likely is it that you’ll take it up in the next six months? Or three months? If you’re thinking to one / all of these that it’s not very likely, then you’ve really just hit on your option expiry date. After a certain amount of time those ideas have expired.

Think about your answers to those questions. The one that’s the shortest to which you answered “unlikely” is your option expiry timeframe. Record the date that an option enters your pool of options. After the amount of time you discovered above (say it’s six months), that becomes your option expiry date.

Periodically remove those options that have exceeded that timeframe. Just throw them away. Even better, if you have an electronic system, set a rule to do it for you. Don’t worry, if it’s really important it will come back and you can create another ticket.

Doing this will save you time and help keep you focused on things that are important right now.

RETURN TO BLOG

 Posted on June 24, 2020 by

 Agile, Backlogs, Kanban

     , , ,

Using Input / Output charts

These are not very widely used, but are one of my favourite charts for helping to manage flow. I find it quite simple as well, which once you finish this article I hope you also find it equally simple and useful.

When managing flow you often want to make sure you team are not taking in more work they can handle, plus you also want to make sure they don’t “starve” for work. Continually looking for balance can often seem difficult, but using this chart you can help achieve the balance your looking for.

Here’s a look at a net flow chart:

Essentially, the green points above the line mean that for that week you’ve gotten more items done that what you’ve started. The red points below the line represent weeks that you’ve started more items than you’ve completed. Those weeks that don’t have a line in them (with a zero) are weeks where you’ve balanced input and output (well done!).

Where you see build ups of several weeks of the one colour, that’s usually a warning sign that you’re flow is out of balance.

You can see in the early part of this chart there is a lot of red. That indicates that WiP is increasing and is often an indicator that you need to start to choke the input to your system or it will be overwhelmed. However, there is often an exception to this where teams are bootstrapping / starting out – you want to start to pull work into the system and it will take some time before the first item flows out.

Alternatively, if you get a number of weeks of all green it means that you’re team are finishing a more work than they started. This is an indicator that you need to get out and start some more work. In the event that you have an upstream, you may have a lead time before that work comes to your system. It’s important to see these signals early and can respond to it.

In first diagram above, you can see in the middle there were a period of time where it was back and forth. Then towards the end you can see balance starting to be achieved. This is an important part of how you use this chart – often with a large board and different work items types / classes of service, it’s hard to see important details of this without the data representation. I hope that you can now you can see the value in this chart and can try and use it.

It’s freely available here if you wanted to download it:

http://bit.ly/SimResources

RETURN TO BLOG

 Posted on June 16, 2020 by

 Kanban, Metrics

     , ,

Evogility