Manifesting Business Agility

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 be​ing 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.

All approaches provide a starting point- I call that a prescription. The key question is how many different prescriptions can they write? If they only have one, or if part of their prescription is immutable, then they are prescriptive, To avoid being prescriptive one must provide choices and how to implement them.

Scrum's prescription is cross-functional teams, time-boxing, certain roles and events. Scrum was designed for a team building a product, not for a group of people who are working on many projects. It's a good prescription for already capable teams, but not necessarily a good prescription to create teams or to get devs & testers working better together.

The Kanban Method has its own prescription that becomes prescriptive if one doesn't consider changes to where they are that might be useful at the start.

In practice, SAFe has a prescriptive starting point at the team level. This may work well when are not collaborating well. But SAFe's higher level prescriptions are pretty expensive and going from bottom to top is not always the right way.

Disciplined Agile & FLEX provide prescriptions, and only after a diagnosis. And they teach organizations how to write their own in order to continue to improve

Most frameworks are rolled out in a prescribed manner. One intent behind this includes the desire to create consistency across the organization. Saying which parts of a framework to implement based on size of the org is still prescriptive which is not consistent with systems-thinking. Systems-thinking is a foundation for Lean and Flow. Adding Lean and Flow practices to a non-systems thinking approach doesn’t make it a systems thinking approach.

In development efforts, systems-thinking suggests a value stream perspective. This facilitates alignment around adding value to customers both within and across value streams. Management facilitates education and provides an environment within which workers can self-organize to get their job done.

When the framework is the territory, tailoring is delayed until the framework is understood. But a framework not adapted to an organization becomes overhead and because how or when to adapt is not included in the framework, it often doesn’t happen.

DA FLEX believes in early adaptations. Even when the choice is not ideal, this attitude promotes learning. The goal is not to follow the framework but to continuously improve an organization’s business agility.

I often hear people say as you scale things get exponentially more complicated. That state as unassailable truth that if you have 'n' people or teams and add one more you now have n times as many things to attend to. While I agree it is this way when you build around organizational layers or off of team relationships, it doesn't have to be this way.

Imagine, for a moment, you were responsible for a development group building a new product and every time a new feature was added it took longer than the one before. You decide to talk to the team coach and team lead. They respond that for every new feature added you have to attend to its relationship to all of the other features. As there were now more features there were more relationships to attend to.

I am sure your response would be "have you never heard of architecture?"

We need well thought out framework architectures as well. They need to have clear, visible relationships between the framework's components. We need to be able to see if a local change has an overall positive impact. It must be robust in the face of errors.

The architecture of a framework will determine if it gets simpler or more complex over time. And whether people stumble with its implementation.

Scrum is designed to be incomplete. Its philosophy is based on empiricism and confidence people can figure out what’s needed. Scrum was formulated when many universal truths of product development were not well known. However, they are now, and the downside of not providing these concepts at the beginning is that it requires extra work for the team while adding the risk they never figure out what’s needed.

Scrum was also designed for cross functional teams working on developing products. It requires teams be cross-functional and is based on time-boxing with the presumption that incoming requirements are longer than the sprint length.

The challenge is when cross cross-functional teams aren’t present, it doesn’t provide guidance on creating them. Furthermore, if you are in IT and are dealing with a continuous stream of small requests, sprint planning adds extra work without providing value.

Disciplined Agile takes a different approach. It provides an underlying model that both enables teams to choose a good starting point and how they should work. This underlying model also provides guidance on improving. By being based on Lean and Flow principles, guidance is provided without being prescriptive.