Manifesting Business Agility

This blog concerns itself with organizations moving to business agility—the quick realization of value predictably and sustainably, and with high quality. It includes all aspects of this—from the business stakeholders through ops and support. Topics will be far-reaching but will mostly discuss FLEX, Flow, Lean-Thinking, Lean-Management, Theory of Constraints, Systems Thinking, Test-First and Agile.

About this Blog


Recent Posts

Improving Value Streams

Re-Thinking Eliminate Waste

Wastes of Software Development

Saying "Eliminate waste" is not useful

"I am" vs "I have"

Improving Value Streams

Categories: lean, value streams

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.


Posted on: October 15, 2019 09:27 PM | Permalink | Comments (4)

Re-Thinking Eliminate Waste

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.”


Posted on: October 14, 2019 09:30 AM | Permalink | Comments (2)

Wastes of Software Development

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

Posted on: October 12, 2019 11:48 AM | Permalink | Comments (4)

Saying "Eliminate waste" is not useful

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 work flow. 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 which 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. 

Posted on: October 11, 2019 11:30 PM | Permalink | Comments (5)

"I am" vs "I have"

When you describe yourself, you should be careful about whether you are describing yourself according to your career or according to a path in that career. For example, to say "I am a doctor" or "I am a PMP" makes sense. That provides some identity of your goals, values and knowledge.

In the Agile space, however, we often hear people identify with a particular approach to a larger goal. For example, Scrum is one path to being an effective team coach. ACP is another one. Kanban yet another. Identifying with a path to a goal is not a good thing - it limits your possibilities and can create dogma and tunnel vision.

There is a big difference between saying "I am a Certified Scrum Master" and "I have been certified as a Scrum Master." One is an identification of who you are, one is a statement of knowledge you have. I prefer someone who says "I have an ACP" over "I am a Certified Scrum Master" because it's easier to learn something new than to change your identity.

Posted on: October 11, 2019 09:54 AM | Permalink | Comments (7)

"O, it is excellent To have a giant's strength! But it is tyrannous To use it like a giant."

- William Shakespeare



Vendor Events

See all Vendor Events