Attending to the Customer’s Value Stream

This section of the portal is for supporting the Disciplined Agile Value Stream Consultant Workshop (DAVSC), currently under development. Discussions on the pages here will take place on the Disciplined Agile LinkedIn group.

 

The first principle of the Agile Manifesto is, “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” Given the Agile Manifesto’s team perspective, this is well stated. Note that the “our” in the first principle refers to the development team. However, we should be going after the quick realization of business value predictably, sustainably, and with high quality. This is a business focus whose first priority is to define who customers are. In addition, “deliver” is different from “realization.” Many companies get software developed only to wait for that last inch required for business value to be done. Business Agility requires both a different perspective and a systems-thinking view.

This is one of the reasons that the use of Minimum Business Increments is so important. MBIs can be selected on the basis of who our customers are. By attending to the relative importance of our customers we can better select MBIs. This is a key to portfolio management – understanding your target market.

Once we’ve established that our target is the customer it is important to realize that our development efforts are one or two times removed from it. In most Agile adoptions our initial focus is on technology. We’re working on our systems and trying to improve them. We have talked about the value stream and different ways to improve it. While we are trying to improve the development value stream, that is more a move of efficiency. The systems we build are also creating other value streams.

If your software is being used directly by the customer then it is important to notice that it is creating the value stream for your customer. That is, how they use your software to add value is their value stream. If your software is used by internal folks, as most IT applications are, then your software is impacting their value stream. And of course, the way they work with your clients again impacts them.

So there are two or three different value streams involved in your work (indicated in Figure 1).

  • The software development value stream
  • The customer value stream created by the development value stream
  • The product value stream (whether end customer or internally used) affects the real customers

Figure 1: Software development value stream

If the software being written is used directly by the customer then the two relate as shown in Figure 2.

Figure 2: Development value stream creating a user value stream.

Now, if you are writing software for internal customers or if you are writing software for people to use to create software for others, you have something like Figure 3.

Figure 3: Development value stream for “intermediate products” (being used by internal customers or being used to build another system) .

Why this is important

When selecting what you are building it is important to remember who your real customer is. This provides for true innovation. Extending software usually focuses on improving our existing systems. True innovation focuses on creating new value streams for your customers, and if those customers are internal or have customers, then their customers.

Additional Resources

See Value Streams Main page for more.