Straightening out your value stream

The value stream is the set of actions that take place to add value to a customer from the initial request to delivery. 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.

Value streams are what they are, you don’t specify them. There are several ways to change them, however, including changing:

  • what goes into them
  • how people collaborate
  • the order of the work (e.g., test-first)
  • how teams are organized, the size of the work done
  • the amount of work being done by the people in the value stream

The idea is to remove handoffs, delays and handbacks in the value stream. Doing so will lower cycle times and increase process cycle efficiency resulting in quicker time to market and realization of value.

Handoffs, handbacks, holdups and multi-tasking- discovering impediments without value stream mapping

Back in 2006, I would always incorporate value stream mapping into the training or engagement. Over the years, however, as Scrum teams have become predominant, I have found doing to to be of less value. Not because value stream mapping isn’t important – it is, but because people don’t seem to be able to do it well.

Continue reading “Handoffs, handbacks, holdups and multi-tasking- discovering impediments without value stream mapping”

What role do value streams play in your approach?

To be clear, I am referring to Lean’s (not SAFe’s) definition of the value stream – the set of actions that take place to add value to a customer from the initial request to delivery. The value stream begins with the initial concept, moves through various stages for one or more development teams and on through final delivery and support. You can’t define value streams – they are what is. You can, however, map them, define a “to be” value stream and you can improve them.

Continue reading “What role do value streams play in your approach?”

10 Lessons from 20 Years in Agile: Lean Thinking

This podcast is part of a series, The 10 most important things I have learned from 20 years in Agile (June 3, 2019)

In this series, Al Shalloway shares some of the most important insights he’s had over this time and how they relate to each other.

This episode is about Lean Thinking. Continue reading “10 Lessons from 20 Years in Agile: Lean Thinking”

Intermediary Practices vs. Practices That Work Directly on Flow

An intermediary practice is a practice that works indirectly on what you are trying to achieve. Before discussing examples and the risks of intermediary patterns, let’s look at some of the things needed to achieve flow (realizing value without delay):

  • Removing delays in workflow (hand-offs and waiting for others), feedback, learning, and between getting and using information
  • Manual testing
  • Interruptions
  • Technical debt

By working directly on these, here is what you would have. Continue reading “Intermediary Practices vs. Practices That Work Directly on Flow”

Don’t Worry About Process Waste; Worry About Delays & Output Waste

Errors are going to happen. Trying to prevent them is helpful, but it is often more effective to minimize the impact they have by detecting them quickly.

In software development, waste can be thought of as “unplanned work caused by errors which are usually exacerbated by delays in feedback.” It can come from several sources. Continue reading “Don’t Worry About Process Waste; Worry About Delays & Output Waste”

Agile is Here to Stay (Or at Least the Being of It)

The most important words of the Agile Manifesto are, “We are uncovering better ways …” This should continue to be true.

Agile is often thought of as a way of being. But getting people to “be” Agile is hard. And it’s not clear what “doing Agile” is. Being” is good. But getting there is another issue. It requires us to continue to be “uncovering better ways.” Continue reading “Agile is Here to Stay (Or at Least the Being of It)”

Something has Happened to Me (Not My Normal Rant)

I’ve been having a very interesting two weeks. I would like to say that whenever I go into a client, I am always on, and always get my clients to see new opportunities. But I’d be lying.

However, for the last two weeks, that’s been what’s been happening… with five clients. While I feel I’ve been “on” and empathetic, that only explains half of it. Something else has been going on.

Here is what I think has been happening. In all of the cases, I started out with:

  • Depicting a value stream representing what they’d like to happen
  • Adding their team names, relating this to what people were doing now (making it less theoretical)
  • Identifying the client’s problems in this ideal flow

At this point, they started asking how to solve their problems. Often, they are stumped about how to work with non-Agile teams or how to create predictability. They would ask, “How can you do this in Agile?” “What do you think about LeSS?” Essentially they were taking solutions they knew, or had heard of, and were trying them on.

It’s like shopping for clothes. Every company is shaped differently. There may be lots of clothes (solutions) out there that don’t always fit. That’s when you want to learn to be a tailor.

This is the first of a series on the implications of these insights.

Using Lean to Focus on Your Work

The reason I am not a fan of frameworks is that they mostly have us focus on activities that are proxies to what we need to do to achieve what we really want to do – realize value quickly, predictably, sustainably and with high quality. Lean provides us insights on what to directly work on. Consider these 5 aspects of product development:

Focus on what’s of value to the company. Much of this will be providing better value to the customer some will be on how the organization builds them. This must be quantified for it to be relevant since everyone in the organization must see these driving factors. Use OKRs (objectives and key results) as a basis with strategies and initiatives being spawned by them.

Understand your value stream network details the steps and who does them that it takes to actually create the value.

Focus on lowering the cost of delay which is the time lost to delays in value realization. Organizational structure, development method, size of the work to be done and how people collaborate are significant factors.

Manage the flow of work and the ecosystem through which all of this flows. This includes when work is started and how decisions are made for how people work together.

Continuously improve the above.

Why You Must Look for Best Practices in Complex Systems

The two major lessons of complex systems are:

1) small events can lead to big challenges

2) you can’t predict if attempts to improve things will work

But this doesn’t mean there aren’t best practices in complex systems. In fact, it means in complex systems you must look for the few best practices there are.

By a “practice” I mean something that:

1) takes little energy to do

2) simple enough that everyone can do them

3) provides value enough of the time to make them worthwhile

Here are some Agile Best Practices:

when given a requirement ask “how will I know I’ve done that?”

  • before starting a new task see if there’s a task you can finish or help someone else finish
  • have explicit work policies (i.e., have team members know what each other is doing)

While there are others, let’s consider the value of these. The first helps avoid misunderstandings. The second shortens development time. The third helps avoid misunderstandings.

All of these are clearly valuable. All too often we worry about managing big things, and overlook the little things that can make a big difference. While we can’t control complex systems, we should do what we can to avoid chaotic events.