Manifesting Business Agility

This post begins a series of blogs I'll be making on the good and weaknesses of Scrum and how the PMI's offerings of Disciplined Agile and FLEX will provide a better path.

Scrum is widespread because there is a lot of good in it.

Here's some of the good:

• Co-located, self-directed, cross-functional teams
• All team members are equally responsible for the quality of the code.
• Someone needs to have responsibility on what to build
• A coach outside of developers is usually useful

• Limit work in process
• Track completed work
•  Avoid interruptions

• Quick feedback
• quick pivots
• regular retrospections
• Cadence
• Small stories
• Regular demos
• Visibility of work

There are two things to learn from this list. First, regardless of your method, you should be achieving these values. Second, Scrum is a way of accomplishing these. Think of Scrum as a collection of ways to get things done. There may be a better collection that fits your teams. Don't worry about whether this better collection is Scrum or not.

First, let’s get clear on what a value stream is. It is the set of actions that take place to add value to a customer from the initial request through realization of value by the customer. The value stream begins with the initial concept, moves through various stages for one or more development teams (where Agile methods begin), and on through final delivery and support.

This definition is decades old and has unfortunately been redefined by Scale Agile Inc. Doing so has weakened its value. To be clear, a value stream is what is. It can be mapped but it can’t be defined. Value streams are affected by several factors. The most critical ones of these are:

• What’s going into the value stream (smaller is better)
• Visibility of the work (visible is critical)
• How people are doing their work and whether they have explicit agreements about how they are doing it (test-first, limited handoffs, explicit workflow)
• How many value streams people are in (1 is ideal)
• How people are organized to work on things (same type of work comes to same people)

Improving your value streams means to improve these factors that affect it. The reason product thinking is so important is that it makes it much easier to improve all of these factors.

This artile is within the context of software development. Eliminate was in the physical world makes sense because you can see it. Virtual worlds are different.

This was originally posted in February 2017.

Re-Thinking “Eliminate Waste”

A common refrain in Lean-Manufacturing is “eliminate waste.”  However, this can be very misleading when applied to software development (product or IT).  There are two main reasons for this.  The first is that manufacturing involves trying to refine a single repeatable process.  The other is that because manufacturing exists in the physical world (whereas software is more virtual) waste is more easily seen in manufacturing than in software development.   There have been many disagreements about what “waste” is in software.  Is planning, documentation and design waste?  Clearly, we need some of these but many people argue that they are waste.  Going for as little as possible is likely not the right answer. 

In Principles of Product Development Flow, Don Reinertsen said “If you only quantify one thing quantify the cost of delay.”  Although he was stressing the importance of quick delivery, it provides a clue to shift our focus to delay in delivery.  This, of course, is affected by many things.  But the causes of delay in the realization of business value are insidious in software development because most delays create additional work to be done (typically in the form of rework).  By eliminating delays, we eliminate much of this additional work – freeing up time for creating more value. 

So yes, we do want to eliminate waste, but we do so by eliminating delays in workflow, feedback and business value delivery.  Focusing on delay instead of waste shifts the conversation from “is this waste?” (something people often disagree about) to “is this delay causing problems?” (something we can mostly agree on).  Consider this – few people will argue for delays.

Re-thinking “Last Responsible Moment”

The mantra to make decisions “at the last responsible moment” has a similar challenge.  Many people won’t agree on what that last responsible moment is.  However, if we consider delays, what we want to do is to minimize the delay between making a decision and acting on it.  The greater this gap the greater the risk of it being a poor decision. Let’s consider requirements as an example.   Getting all of the requirements up front is clearly too early – as implementing some will affect others.  Shifting from “the last responsible moment” to “when will I need the information this decision entails?” will improve the timing of the decisions involved.

The Key Is Alignment

It is straightforward to begin a transformation to Agile at scale.  But after the initial training and kickoff, it quickly becomes more of a “how do I shift people’s mindsets?” than a “what do I do?” challenge.  We’ve all seen Agile “transformations” where people kept the same mindset adversely affecting real change.  Shifting mindsets is necessary to achieve alignment across the organization. We need to consider not just the end-result (eliminating waste and making decisions at the right time) but what questions can we ask that will have people work together better.  As has been said by many people in different ways “we will get better answers when we have better questions.”  The power of better questions is illustrated by Jonas Salk’s comment – “what people think of as the moment of discovery is really the discovery of the question.”

​This was originally written in June, 2012. Re-posting since recent conversations on LinkedIn made it relevant to share. 

There has been a tendency to translate the seven wastes of manufacturing into wastes of software development. Not a bad start, but just that - a start.  There are several things about software development that is not at all like product development in the physical world.  These include:

• waste cannot be seen directly
• the appearance of a developer is the same whether they are writing bug free code and buggy code
• errors in software tend to take more energy to fix as the time between making them and finding them increases (this is true even prior to deployment)
• errors in manufacturing tend to repeat themselves, errors in software are unique, although they repeat a pattern

The point is, we need a new list of wastes for software development.  Here is a first cut:

• The Cause of Waste
  • Too much work in process
  • Delays
  • Handoffs
  • Bureaucracy
  • Interruptions
  • Unclear workflow
• Waste Produced (note how this adds to the cause – endless cycle)
  • Extra features
  • Defects
  • Complexity
• Waste in Work (note how this adds to the cause – endless cycle)
  • Lowered efficiency due to interruptions and improper methods
  • Fixing bugs
  • Redoing requirements
  • Thrashing due to out of synch integration
  • Re-learning
  • Poor technical practices
  • Improper order of work
  • Duplicating code
  • Overbuilding frameworks

 Much of the source of the problem is doing too much work. This can be too many things in play or the things in play are bigger than they need to be.  There are two general ways of managing the work of a team:

1. Plan it out ahead and give it to them
2. Let them pull the work when they are ready

 Waterfall and pre-agile planning uses the first.  All Agile methods use the second. The challenge is how does one get executives to understand that there is an inherent capacity of the teams and that this must be respected?  From their perspective we need to provide the following information:

1. Evidence that the teams are working well
2. Evidence that they are working at capacity

We’re trying to learn a better way.   Undergoing a change can be hard on us, as well as the people we are providing services too. In situations like this, exposure into one's methods is always a good idea.  Both for the teams to learn how to better work and for others to understand why the changes represent a true opportunity for improvement.

For a more recent, related post on this see The Software World Is Not Like the Physical World and What That Means

This article was originally posted in September 2011

"Eliminate Waste!" This is one of the earliest mantras of Lean that people learn. It is easy to say but it can cause problems if we consider it a means - instead it is actually a goal. Forgetting this sets the student up for a long bout of wasted effort or at least incomplete results.

When I first started teaching Lean, I began by talking about eliminating waste. It was fine. But my students were not seeing the fruit that I knew they could. It was through our extensive coaching with Lean software development that we came to see that much of what we consider "waste" is a result of over-burdened and uneven workflow. In other words, although we want to eliminate waste, most of this waste is actually caused by something else. 

Years ago, Jim Womack made this same observation in an interesting blog called "Mura, Muri, Muda?" In it, he observed that muda ("waste") is caused by "muri" (overburdened workers) which is caused by "mura" (unevenness of work).

Eliminating waste means looking at something else.

So, what do you look at? It takes a shift in perspective.

Prior to Lean, if you were in a factory, you might focus on idle machinery. In a software development environment, you might focus on idle developers. Such underutilized resources are waste, right? It is why in software development, management creates schedules based on utilization rates. That is the traditional, mass production or waterfall approach to efficiency.

The manager in a Lean software development environment has a different focus: cycle time (loosely thought of as the time from start to finish). In a Lean environment, the waste is in delay, delay in delivering value to the customer.

The one sees slack as waste and focuses on utilization. The other sees delay as waste and focuses on the cycle time to value delivery. Which would you select to best assist your business and/or customer? How you answer this depends on your mindset, that is, the paradigm from which you work.

This is not merely a philosophical exercise. As I wrote in The Importance of Mindsets, I believe much of the nonsense we get in the software world is due to the fact that few people seriously challenge their mindsets and why we do the things we do. And that keeps us from being able to shift to new paradigms that work.

For me, the shift in Lean thinking deepened when I went from "eliminate waste" to "optimize the whole." Optimize the whole is the deeper, more fundamental mantra for Lean. Eliminating waste may produce local optimizations that do not produce any system-wide benefit and sometimes may even cause harm.

Here are some ways to eliminate waste by getting to the cause of it: 

1. Eliminate delays that induce work. See How Delays Cause Waste: A Main Tenet of Lean.
2. Focus on the systems, making it more helpful to people and less likely to generate errors. This mirrors the lean mantra of "build quality in." One manifestation is Acceptance Test-Driven Development.
3. Focus on improving learning in the organization such as Toyota Kata and continuous learning.

And, of course, you still gotta think.

Be clear, I'm not saying "eliminate waste" is incorrect. It is the goal, not the means.