A Simple Guide to See if a Change Will Be an Improvement

Making Changes in a Complex World

While software development takes place in a complex environment, it doesn’t mean we can’t make reasonable accurate predictions about potential changes. This chapter talks about how to use some basic Flow and Lean principles to gauge whether a projected change will be an improvement or not.  When considering a change, it’s worth seeing if the change works with or against these principles. If they work against them, it is unlikely the change will be good. If it works with them, then it is more likely to.

Sometimes our changes have more to do how people work together. In these cases the accuracy of our predictions may be less because the changes have more to do with the people than the work itself. In any event, it is worth treating these changes as experiments that you must validate. Even when the principles give you a good indication of what will happen it is possible you’ve neglected to attend to something needed.

Frameworks are not enough

While frameworks are often a good start, people encounter challenges that either the framework doesn’t address or even seems to exacerbate.  How to get out of this dilemma is often difficult because people usually start with a framework in the first place because they don’t have a deep understanding of the principles underneath Agile – Flow and Lean.

But they usually have a greater experience of some of these principles than they give themselves credit for. At least, when these principles are pointed out to them. It’s not unlike (for Americans) wondering why driving in New Zealand is so difficult until someone points out they drive on the left.

This chapter lists some key principles that you can almost certainly validate from your own experience and then use to deduce potential improvements or validate suggested ones. This is a simplified guide elided from The Value Stream Impedance Scorecard.

Key Principles of Flow You Likely Already Know

Practices are usually explicitly or implicitly designed to reduce impediments to flow. Here are some common impediments:

Interruptions in workflow. These occur when someone is needed and not readily available. It is often caused by people working too many things, being spread out across multiple time zones and focusing on the work of their team instead of what’s most valuable for the company. Typical root cause: working on too many things.

The time between getting information (e.g., requirements) and using them is long.  This requires redoing the information or using old information. Typical root cause: planning too far ahead.

The time between a misunderstanding and it’s being discovered.  Misunderstood requirements have developers write functionality only to have to rewrite it. Typical root cause: requirements not being done in a collaborative way (e.g., ATDD) across the roles involved..

The time between writing a bug and it’s being discovered.  This is even if the bug never escapes the team. It will take more time for the developer to find what s/he did that caused the bug if it is discovered late. Typical root cause: developers and testers not working closely together.

Anything that increases the time from starting the development of a story until its completion. The longer a story takes to complete the more the above impediments will likely be made worse. Typical root cause: working on too many things and not having a focus on finishing.

Chunks of work being too large. Large chunks of work take longer to do clogging up the system. The exacerbate all of the above. Typical root cause: not following a concept such as the Minimum Business Increment.

Common Root Causes of the above:

Each of the above have multiple root causes (I listed the most common one). Here are typical root causes across an organization.

  • Working on too many things
  • Batches of work being too large
  • Insufficient collaboration
  • Not having a focus on finishing
  • Not having clarity on what value can be realized quickly
  • Handoffs
  • Interruptions

Using This List When Considering Making a Process Change

When you are considering making a change to your process, this short list can be quite useful. It may surprise you to see how most of these will get better together or worse together when you consider a change. The reason is that they are all interrelated.  Let’s take a couple of examples:

Testing is falling behind development so we’re considering batching our testing to be more efficient in doing them.

I have often seen companies look at their bottlenecks (where work is delayed) and assume that’s where their problem is.  It often isn’t. This is one of the reasons we must consider the entire value stream. In any event, this attitude often has companies think if testing is the bottleneck we must make it more efficient and they decide to batch the tests to enable testers to just run through testing the system.

Let’s consider the above as a checklist:

Interruptions in workflow. Moving test to later will cause interruptions when test comes back to developers and tell them what they found. This delay will also require more time of the developers to fix the bugs.

The time between getting information (e.g., requirements) and using them is long.  This likely won’t be affected.

The time between a misunderstanding and it’s being discovered. This change will definitely going to impact the developers.

The time between writing a bug and it’s being discovered. This change will definitely going to impact the developers.

Anything that increases the time from starting the development of a story until its completion. This change will almost certainly increase the time it takes to complete stories because any savings to the testers will be more than paid for by the developers.

Chunks of work being too large. This change will not affect this.

Overall it looks like this will be a bad move, and this matches our experience as well.

We can’t get everything done in a sprint so we’re considering going to Kanban

People struggling with Scrum often have problems getting everything done in a sprint. Much of what they know about Kanban is that it doesn’t use time-boxing (sprints). But you can’t just not do time-boxing and think you are doing Kanban. Kanban does a lot of other things that are required because it doesn’t use time-boxing. Let’s see what happens if all we do is stop using time-boxing.

Interruptions in workflow. This may not change much.

The time between getting information (e.g., requirements) and using them is long.  This can also be readily managed.

The time between a misunderstanding and it’s being discovered. This time could expand considerably. Unless a real focus on finishing takes place the time from starting a story until its completion will expand without the focus sprints provide.

The time between writing a bug and it’s being discovered. This time could expand considerably. Unless a real focus on finishing takes place the time from starting a story until its completion will expand without the focus sprints provide.

Anything that increases the time from starting the development of a story until its completion. Again, without the discipline the sprints provide, this will almost certainly expand.

Chunks of work being too large. This change will not affect this.

Overall it looks like this will be a bad move, and this matches our experience as well.

 


Note

Two onlinen FLEX coursees are now being offered – FLEX for SAFe, and Adopting FLEX (the first course in becoming a FLEX trainer).

If you want to learn about how to adopt FLEX in your organization please contact the author, Al Shalloway.