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
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
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?
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
So yes, we
Re-thinking “Last Responsible Moment
The mantra to
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?”
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
The point is, we need a new list of wastes for software development. Here is a first cut:
Much of the source of the problem is doing too much work. This can be too many things in
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
We’re trying to learn a better way. Undergoing a change can be hard on us,
For a more recent, related post on this see The Software World Is Not Like the Physical World and What That Means
"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"
Years ago, Jim Womack made this same observation in an interesting blog called "Mura, Muri, Muda?" In it, he observed that
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,
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
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:
Be clear, I'm not saying "eliminate waste" is incorrect. It is the goal, not the means.
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 "