Part I: Understanding What Is Needed

This section is in both the Amplio Development book and the Being a Professional Coach book. The reason is that this information is in here is critical both for a person learning Amplio as well as for a professional coach. While the coaching book can be used with any approach, it is still based on the mindset of Amplio.

This section of the book focuses on the Amplio approach. In

• Why we need a different approach than frameworks
• The mindset of Amplio
• The capabilities required to be effective
• How to get started and continue learning

This section is in all of the Amplio at the team level books. These include:

1. Amplio Development: The Path to Effective Lean-Agile Teams
2. Being a Professional Coach
3. The Amplio Scrum Guide

Why We Need a 21^st Century Agile Team Approach

I am enthusiastic over humanity’s extraordinary and sometimes very timely ingenuity. If you are in a shipwreck and all the boats are gone, a piano top buoyant enough to keep you afloat that comes along makes a fortuitous life preserver. But this is not to say that the best way to design a life preserver is in the form of a piano top. I think that we are clinging to a great many piano tops in accepting yesterday’s fortuitous contriving as constituting the only means for solving a given problem. – Buckminster Fuller

You never change things by fighting the existing reality. To change something, build a new model that makes the existing model obsolete. – Buckminster Fuller

Agile as a community working to find better software development methods started in the mid to late 90s. Innovators and early adopters were the first people to use it. Most teams adopting Agile were developing software products and were mostly autonomous and cross-functional.

Scrum is Agile’s most popular framework. It continues to be a framework geared towards identifying your impediments and having teams figure out how to solve them. But times have changed. Agile, and therefore Scrum, is used almost everywhere now, most of the time not where it was designed for. Most of the teams using it are not cross-functional, autonomous, or working on creating a new product that Scrum was initially designed for.

Whereas 20+ years ago we often knew what worked, we didn’t know why it worked. This had early practitioners adopt frameworks that spelled out how to start but provided little guidance on how to customize the approach to the needs of the teams involved. As organizations adopting Agile have shifted from early adopters to the late majority, and as the adoption of Agile has moved from single teams to an entire organization, the early philosophy of Agile has proven to be insufficient.

The demand for people trained in Agile has created what many sarcastically call the “Agile Industrial Complex,” referring to the churning out of certifications by several organizations even though those certified do not really know how to run an Agile project. These organizations have little incentive to provide quality training on evolving methods – and so they don’t. Agile is losing its glitter in the face of a 2-decade old approach being taught in an even older teaching style – one exacerbated by the Pandemic, which has had people use in-person training methods for remote training.

Furthermore, the issue of training people in how to convey the ideas they’ve learned has been ignored. This has left even those who understand what to do with the challenge of how to convey that to others.

The result of all of this is that Agile has devolved into a difficult situation for many – not unlike a person driving backward, on the wrong side of the road, complaining about how difficult it is. Fortunately, we can now correct this situation.

What’s Been Missing That Can Now Be Provided

Over the last 15 years, there have been major advances in understanding. Lean has been migrated to both product and software development, Flow has both extended our understanding of Lean and been applied to product development, and the Theory of Constraints has been migrated to product and software development while providing us a way to integrate how to deal with complexity. This wealth of knowledge not only spawned many practices and approaches (Scrumban, Kanban, Kanban Method), but has provided a deep body of knowledge in the theory underlying why Agile works. While Scrum and SAFe have adopted some of this wealth, it’s been a relatively paltry amount.

In particular, the opportunity that theory provides to align people has been virtually overlooked. Both Scrum and SAFe have been content to lay out their frameworks and have people focus on how well they implement the framework instead of learning how to think for themselves.

Flow, Lean, and the Theory of Constraints also create a new opportunity – to build from a foundation of understanding first principles. First principles are principles that stand on their own. They partially describe how the world works. First principles are not defined, they are discovered through observation and relentless evaluation. Violating them has consequences. They can be used to provide guidance as what individuals, teams, and organizations should do.

Basing approaches on first principles enables those not familiar with Agile to relate to their past experience. They no longer have to trust the “gurus” but can listen to discussions of what to do and relate their past experience to the first principles being proposed. First principles provide both constraints on what we can do as well as guidance on how to improve. A coach/consultant who learns these isn’t forced to convince people of things. Instead, they can relate these first principles to the past experience of the people they are working with and come up with effective practices together.

What Needs to Happen – The Amplio Approach

Amplio, Latin for “improve”, is based on a job task analysis created by Al Shalloway over almost two decades of analysis. As CEO of Net Objectives, Mr. Shalloway observed a dozen top consultants while having conversations with scores of others. By reflecting on their engagements, as well as his own, he discerned what successful and unsuccessful engagements had in common. While there were few universal practices, there were many common objectives that needed to be met. The challenge was to take what worked for very different styles of consultants/coaches and create an approach that could be used by almost any style.

Amplio’s name is a double-entendre. We must improve how we work, and Amplio itself must continue to evolve and improve. Since Amplio is based on the required job-task analysis, I will describe what is needed (the JTA) and the reader should understand that this is what Amplio does and allows for.

Approaches are not just values, principles, and practices

Most approaches to Agile limit themselves to the values and what to do aspects of the work. But there is a lot more that is needed. Amplio recognizes that there are 5 areas that must be addressed. These are shown in the following figure.

Foundations and mindset

Edwards Deming tells us that “Experience teaches nothing. in fact there is no experience to record without theory… Without theory there is no learning… And that is their downfall. People copy examples and then wonder what is the trouble. They look at examples and without theory they learn nothing.”

By “theory,” we don’t mean plans to follow. We mean a model that explains why and how things work. Of course, as Georgy Box says, “all models are wrong, some are useful.” We must recognize that our understanding is always incomplete, and we must always be striving to be less useful.

Amplio is built on first principles – essentially how the world works, not what we think. Scrum’s lack of first principles causes most new Scrum teams to repeat the same mistakes. The lack of systems thinking makes learning harder and take longer. These principles can guide us in choosing practices that are best for the situation at hand. Not having these also makes it hard to talk to executives effectively.

Organization of Practices

Frameworks are possible because they are easy to build and convey. But if you use a framework as a structure you lock yourself into the framework. A pattern language, however, can be expanded or shrunk as needed.

The patterns of the language can have multiple implementations and shown as needed. This enables having a large set to choose from without it being overwhelming.

The beauty of this approach is that patterns provide multiple solutions depending upon the context involved. By being organized as a pattern language you can add to Amplio’s set of patterns or remove things as behooves the situation.

How to Convey the Practices and Theory of the Approach

Knowing what to do is not enough. You must know how to convey concepts to people. This includes how people learn and how to teach complex concepts.

It’s also important to know how to talk to people so they don’t resist new ideas.

Amplio has a companion book Being a Professional Coach. In this book I talk about how people learn and how to talk to them in a way to increase their understanding.

Incremental Learning

Half and full day training has an incredibly low retention rate. It also doesn’t provide for an opportunity to learn something, try something, and then get help.

Without incremental training over time expect to need a lot of coaching.

How to Start

You always need to see where you are. But where and how to start varies based on the organization involved. Starting too slowly or with too much of a jump can doom a transition to Agile. The speed of change depends upon where it is being applied.

Tools

Collaboration tools are essential to enable remote and asynchronous collaboration. They also work to document what’s been done.

Amplio attends to all of these

Consider for a moment what happens if you don’t attend to any of these.

Organization of Practices

Frameworks are possible because they are easy to build and convey. But if you use a framework as a structure you lock yourself into the framework. A pattern language, however, can be expanded or shrunk as needed.

The patterns of the language can have multiple implementations and shown as needed. This enables having a large set to choose from without it being overwhelming.

How to Convey the Practices and Theory of the Approach

Knowing what to do is not enough. You must know how to convey concepts to people. This includes how people learn and how to teach complex concepts.

It’s also important to know how to talk to people so they don’t resist new ideas.

Incremental Learning

Half and full day training has an incredibly low retention rate. It also doesn’t provide for an opportunity to learn something, try something, and then get help.

Without incremental training over time expect to need a lot of coaching.

How to Start

You always need to see where you are. But where and how to start varies based on the organization involved. Starting too slowly or with too much of a jump can doom a transition to Agile. The speed of change depends upon where it is being applied.

Tools

Collaboration tools are essential to enable remote and asynchronous collaboration. They also work to document what’s been done.

Foundation

The core needs

We must recognize the need for the following:

1. We want to be able to take advantage of what’s been learned so that teams won’t be forced to re-invent known practices.
2. We must incorporate theory to explain why things work. This will enable us to adopt practices that work for our situation since few practices are universal.
3. We must provide team leads with the ability and means to convey these ideas to their teams.

The challenge with accomplishing the above is that the number of practices, theories, and ways of conveying ideas is incredibly large and ever-growing. This puts in a fourth requirement: a manageable set of the above must be able to be used to get teams started, and have a way to expand it as needed must also be provided. To be candid, this last requirement was the most difficult one to achieve in creating Amplio.

With this combination of experience, theory, and how to talk about them Amplio can be used to create a simple, appropriate starting point while providing for improvement as the team learns.

What to align around

The essence of Agile is to provide value to customers in small increments while learning in an incremental fashion. For people to work together, they must see both what they are working on and how they are working.  The natural candidate for this is attending to the value stream. Value streams refer to the steps required from start to finish to accomplish something.  Value streams can be thought of as comprising:

1. What ideas/requests go into the value stream to be created
2. How the people in the value stream are organized
3. How the workflow of the value stream is done

This decomposition enables us to work on these aspects of our work in very well-defined ways.

Different parts of the value stream

While this book focuses on the development part of the value stream, Amplio is defined for other parts of the value stream including portfolio and product management. These will be covered in future books and workshops.

It’s Not That Simple

Product development is not straightforward. While how to improve our work methods can be based on the cause and effect we see, defining the products we want cannot be. Furthermore, no company is separated from the outside world. Black swan events occur more often than we’d like to think. Amplio is designed to enable companies to be able to pivot with little waste when markets change due to events outside of our control.

What Amplio Provides

1. A way to look at what’s happening so the appropriate practices can be selected
2. A set of practices that can be used by the team
3. A way to provide a tailored, quick start for the team
4. A method to improve practices after the start
5. Methods to fix problems as they come up
6. How to reflect on the general approach
7. A set of capabilities for:
   1. doing product management
   2. managing the value stream
   3. creating high product quality
   4. organizing people to be effective
   5. learning and improving
   6. needed roles
8. A set of Miro boards to help people work and learn together
9. Amplio includes a number of coaching methods to convey needed concepts to others

How It Must Be Provided

1. It’s impossible to provide practices for everything but principles can be supplied to enable people to see what to do in new situations.
2. Our approach must not have boundaries on what can be done except that all actions must have a positive impact.
3. We can’t overload teams with too much information, but we need to make more information available after starting so people don’t need to reinvent practices.
4. We want the approach to be simple to those adopting it. However, we recognize that the person leading the team in their approach may need to know more than the members of the team.

The benefit of this approach is that teams and their associated management will understand what is needed. It enables them to work together better and assist each other. It also accommodates the shifts in who and where Agile is being used.

The Amplio Approach

Amplio is Latin for “improve.” Amplio is Success Engineering’s approach to helping organizations effectively deliver value to customers that align with the organization’s strategies. Amplio Development focuses on that part of Amplio about implementing the selected strategy after product management. The focus is on improving the team’s ability to do their part in their organization’s efforts to achieve business agility – the quick realization of value, sustainably, predictably, and high quality.

It builds off the theories of Flow, Lean, and the Theory of Constraints and is designed to teach teams how to do Lean-Agile effectively. Its approach is to:

1. Provide some essential Lean-Agile theory
2. Provide a core set of practices tailored for the team to enable a quick start.
3. Present a way to improve and learn continuously

This is not another framework. Instead, it is an approach based on the science of product development and knowledge work. The concepts put forth here are not just my own. They have been corroborated by dozens of other senior consultants and thought leaders in many fields. This is not meant to be a personal journey but rather a discourse on what is effective. It is based on evidence, but, as George Box said – “all models are wrong, some are useful.” Pushback when you disagree with this, is welcome. Questions, comments, and challenges to assertions put forth are welcomed. A LinkedIn group, The Amplio Community of Practice, has been set up to enter/ask these questions.

The Design of Amplio Development

Amplio Development takes this approach and applies it to the development part of the value stream. It is designed to meet the requirements stated in the previous chapter.

Amplio Development accomplishes this by:

• Starting with a foundation of first principles based on Flow, Lean, and the Theory of Constraints
• Presenting Factors for effective value streams, which can be used to both identify challenges and evaluate which suggestions for improvement will work best
• Provide a set of objectives explaining why it is essential and multiple methods of achieving the objective so the selected practices can be fit for purpose.
• Showing how to create a fit-for-purpose quick start.
• Including critical practices useful for most teams doing knowledge work. These are primarily in management requirements, team formation, and improving workflow.

While this may require more knowledge for coaches to understand, Amplio also provides default starting points that can speed up the process of starting.

The Mindset of Amplio

This section presents the mindset, or underlying belief system, of Amplio, of which Amplio Development is a subset. This mindset is fundamental to all Amplio curricula, not just Amplio Development.

If you are not using Amplio, this section is still important to read. The issues discussed in this section are based on first principles that underly all knowledge work – whether they are acknowledged or not. Learning these can help you as a coach using any framework, methods, approach, etc.

This section is included in both Amplio Development: The Path to Lean-Agile Teams and Being a Professional Coach. Regardless of your approach or role, understanding the theories of Flow, Lean, and the Theory of Constraints is essential.

Systems Thinking and Complexity (ASG)

“Today’s problems come from yesterday’s ‘solutions.’” 5^th Discipline, Peter Senge.

Systems thinking is the foundation of Flow, Lean, and the Theory of Constraints. The essence of systems thinking is that a system is not merely the sum of its components but rather reflects the relationship between them. For example, a car is not merely a collection of tires, an engine, transmission, etc., on a chassis but rather the relationship between these.

Consider taking the best parts of the best cars and putting them together. You wouldn’t have a car – you’d have a pile of junk—car-ness results from how car parts work together.

There are a few other critical concepts involved here. A change to one part of a system can affect other parts. But not just one on one. It can affect how other parts of the system affect even other parts.  Sometimes these interactions are clear. Sometimes they are not. While we can understand these interactions with cars, in other systems, we cannot. We call these complex interactions. The presence of these interactions is why many systems are complex. It is often impossible to tell what change one aspect of a system will have with all the interrelationships present.

Systems can be thought of as a combination of known, well-defined relationships and those that involve complex interactions.  Amplio Development will discuss improving knowledge work by attending to the known, well-defined relationships. It will deal with the complex interactions by showing how quick feedback cycles can mitigate challenges arising from non-linear events during development. Non-linear events are when a small action results in a significant impact. The “straw that broke the camel’s back” is an iconic example. While we often hear of disasters occurring due to complexity, we have more control over what is happening in knowledge work. This enables us to decouple the effect of complex events and avoid disaster or wasted effort.

A very salient aspect of systems thinking is that the system people are in causes almost all the errors and waste. It’s easy to attribute bad behavior to individuals, but it’s more likely that the system they are in is causing the problems.

An important distinction

Creating new products is an emergent process. It requires adaptation, and we must acknowledge the lack of predictability. But this does not mean that our work methods can’t be well-defined.

Essential Lessons of Systems Thinking:

• Systems are more about the relationships between their components than the components themselves
• Systems are comprised of other systems and interact with systems outside of themselves
• Local changes to a system cause global, sometimes unpredictable, side effects.
• Most of the challenges we encounter are due to our system.

Systems thinking in knowledge work.

In systems thinking, we must look at all aspects of knowledge work. This means we look at the people, the customers, the other stakeholders, management, and the workflow. Everything.  One aspect is not more important than the other because all of these are intertwined. This has often been ignored in the Agile community with its focus on people. People are, of course, critical. But the system within which people work affects their behavior. In Amplio, it may appear that we are over-emphasizing production mechanics. But Amplio believes a balance between all these factors must be achieved. Any failure in one will likely lower the effectiveness of the system.

A Fundamental Belief that Separates Many in the Agile Community

A fundamental belief separates those proposing different Agile approaches. Many believe it is impossible to have a well-defined approach effectively solve complex problems. Underneath this is the idea that cause and effect cannot be seen in complex situations except in hindsight. It results in an approach where we look for impediments and then use “inspect and adapt” to remove them. We try experiments and see what happens.

Amplio, on the other hand, is based on the belief that while complexity can obscure what is happening, taking effective action is possible. That we can discover a set of principles that provides us with a model of understanding and enables us to take actions that either provide us with improvement or a deeper understanding of what is happening. Furthermore, this “model” enables us to create new practices consistent with the model and for which we expect them to be helpful. Instead of running experiments, we come from established theory and improve our workflow based on it. Of course, we must validate that improvement has occurred. When it doesn’t, it is almost always the case that we’ve learned something new in our situation.

In knowledge work, we can create visibility via feedback and decouple events to avoid non-linearity in our workflow. While discovering what to build may be complex, our approach to it doesn’t need to be.

The following sections give an overview of such a model. This model is used to drive improvement and deter the risks of complexity. This integrated approach means that when you learn how to improve your workflows, you also learn how to deal with the risks of complexity.

This concept is very important as it allows us to specify many of the principles we find valuable as a series of causalities that can be readily explained.

Attend to Value Streams (ASG)

What are value streams?

Value streams refer to the steps required from start to finish to accomplish something. There are many different types of value streams, but all have the main concepts in common. Value streams shift the focus from the people doing the work to the work being done, both its sequence and timing. There are many different types of value streams. For our purposes, we’ll classify them as:

1. customer value streams
2. operational value streams
3. business-enabling value streams
4. development value stream networks

Customer value streams are the value streams of the customer, that is, the actions they and others when necessary, take for them to get value. Innovation is primarily about improving these value streams. These include using the product/service, getting support for the product/service, and setting up to get (or getting) the product/service.

Operational value streams are those workflows for marketing, selling, deploying the product/service, and supporting customers.

Business-enabling value streams are the workflows for the internal process of the company. These activities include buying and maintaining a server network, stocking shelves, HR, and Legal.

Development value streams are the value streams creating the ones just mentioned. However, they are not linear as the others are and are better thought of as value stream networks. But the concepts and what to look for in them are very similar.

The Benefits of Attending to Value streams

“Attending to value streams” means:

• being aware of them
• notice how they interact with each other
• when making a change, see how it will affect the overall productivity in the value stream

Consider how Apple changed how many of us listen to music. The iPod and its supporting music services changed how people listened to music. By creating products and the systems people used, customer value streams changed. Breakthrough innovation usually comes from providing value to the customer by attending to how they work and designing our systems to influence that positively.

In most organizations, people are busy, but the work often moves at a snail’s pace because it continually stops and starts. By attending to the value streams, we can see what is happening and how to improve it. This also highlights system constraints across all the value streams mentioned.

Attending to value streams guides us in improving our development work while lowering its costs.

This book is primarily about the development value stream network in which the team is embedded. We will learn to work on smaller items, focus on removing delays, avoid overloading people in the value streams, and get people to be in one value stream to avoid multitasking. Flow, Lean, and the Theory of Constraints all attend to the value stream for several reasons. Mapping value stream networks:

1. Provides visibility on what is being worked on and how
2. Illuminates the delays in value add. These delays also create waste in the process
3. Identifies the constraints in the system

The Different Benefits of Value Stream Mapping

Mapping value streams is getting to be in vogue. But there are many ways to do it. These include:

1. A high-level view to get a general sense of what’s going on and to teach what flow is. This does not involve breaking the workflow down into small steps as much as it shows who the work flows to.
2. Detailed mapping with steps and times. This can be done in days or even weeks. It has two purposes, and the time it takes to do this will depend on that. One purpose is to learn where the problems and and what’s causing them. The other is to have people collaborate with each other and see the cause of their problems.
3. Use an idealized value stream map which shows what good value streams look like and denote where the company is being effective and where they aren’t. This is a kind of Pareto analysis of the value streams. It gets everyone on the same picture while identifying where the challenges are.

An Inherent Problem (ASG)

Most organizations are structured in hierarchies to manage the work. But the work flows across the organization. Management attends to the efficiency of these hierarchies instead of attending to the delivery of value. This has adverse effects.

Managing within a hierarchy

Hierarchies tend to have those responsible for the hierarchy see if the people under them are:

1. working on the right things
2. working well
3. fully occupied

This seems so natural that we don’t even think about it. However, it also means that the focus is on the silo, not across the workflow. This results in delays when handoffs are made between the silos. It is common for silos to prioritize work within the silos over cooperation between them. In fact, along with the hierarchical structure are reward and compensation systems that set these silos up to compete, instead of cooperating.

Reflect for a moment on projects you’ve seen in the past. Let’s look at the people doing the work and the work itself (when it is being worked on and when it is waiting to be worked on). See if what you notice matches the following table. Feel free to add to it.

When we make these observations, we often see that no one is managing the work itself but are instead managing the people. Work is seen where it is, but the time it spends waiting is not usually seen.

When we look at the people doing the work, we focus on local steps in the workflow. This is the most significant difference between waterfall and Flow/Lean. In waterfall, we try to maximize the efficiency of the work at each step. The presupposition is that we can do this. Flow and Lean have us look at how long it takes to go from concept to consumption. A project that would take one month if all the people working on it worked on it alone can easily take six months to accomplish when they are busy working on many things.

The actual cost of multitasking.

Many people point to multitasking as a significant problem. It is a significant one, but not the key one. A significant cause of multitasking is people working in multiple value streams. People are being interrupted and are interrupting others. Correlated with multitasking is work waiting in queues. While multitasking may cause a 10-20% drop in efficiency, work waiting in queues can create unplanned work in the form of bugs; working on the wrong things, rework, etc., is much larger.

Focus on delays – not eliminating waste

A common Lean mantra is “eliminate waste.” The problem is that mantra comes from looking at manufacturing. In this context, you can see waste. A car is being built, and errors are visible. Planning can be considered waste because you already know what to do. In knowledge work, the situation is different. First, you can see everything. You often don’t know when you have an error or not. Also, things like design and planning are not wasteful. Overdesign and planning are, but these are still necessary functions. On the other hand, re-doing requirements, working from old ones, building unneeded features, fixing bugs, overbuilding frameworks, duplicating components, and integration errors are wasteful.

These wasteful activities create delays in getting the information and using it or when making an error and detecting it. This is yet another reason for quick feedback and reduced delays. The mantra needs to change from “eliminate waste” to “eliminate delays in the workflow.”

It’s not bottom-up or top-down, it’s attending to the value stream

Many people recognize that hierarchies can be problematic. Many Agile proponents suggest starting at the team. Most are now recognizing the getting executive to buy into Agile adoptions and suggest that a top-down bottom-up approach is required.

While top-down bottom-up is better than just bottom-up, this is still a focus on hierarchies. It often is a “starting at the team with guidance of management approach” – not a true value-oriented perspective.

A direct focus on value streams is essential. Otherwise we’re working on improving local optimizations.

Getting executives to understand the value of quick flow (ASG)

Here’s a way to get executives to understand the value of focusing on the most important work in order to shorten delivery time. Let’s pretend we have an enhancement to a very important product to your company that took six months to build but would have taken only two months if the people working on it had focused on it. Imagine you asked one of your top executives: “would it have been worth paying 20% more to get this enhancement out the door in two months instead of six?” He’d almost certainly say “sure.” But now ask yourself, how would you get to do it in two months instead of six? You’d have to cut down delays between steps. Doing so might require adding a little slack to the system, but other than that, removing delay is more likely to reduce unplanned work. In other words, instead of taking longer to reduce the build time to deployment, it’d take less time to get it out the door.

This shows another shift that’s needed: stop focusing on the utilization of people and focus on removing delays in the workflow.

What Analyzing the Inherent Problem Teaches Us

• We must shift our focus from people doing the work to work being done.
• We shouldn’t manage hierarchies; we should manage the value stream.
• We shouldn’t try to go faster; we should focus on eliminating delays by having fewer and smaller queues.
• To align people around the value to be realized.
• To shift from focusing on people’s utilization to removing workflow delays.
• To stop striving for local optimizations but attend to the throughput of the value stream.

Why this shift is necessary

The shifts above will enable us to focus directly on creating value for our customers. This is more effective and empowers people doing the work.

Consultant’s Corner

Value streams are not business processes.

There is a difference between value streams and business processes. While there are some similarities, the differences are significant. Especially when going into an organization that thinks they understand their value streams because they have documented their business processes.

One significant difference is that business processes are what you are suggesting to be done. Value streams are what is happening.

There is much value being lost by conflating these two concepts. This post points out some of the differences. One difference is focus—a shift from process to flow of creating value. Value streams are based on lean thinking – business processes stand alone. The context of lean thinking creates a focus on time and value. This reflects the importance of attending to Edgar Schein’s observation that “We don’t think and talk about what we see, we see what we are able to think and talk about.”

Here are some specific differences:

1. Value stream mapping can be used to untangle value streams – that is, not have them cross each other. This occurs when people are in the same value stream
2. Value stream mapping can be used to improve the value creation Structure of an organization
3. Value stream mapping pays particular attention to the delays in workflow and feedback
4. Value stream mapping shows what is. You can also create a future value stream map to create guidance for improvement.
5. Value stream mapping is useful to identify the constraint in the workflow
6. Value streams have an integrated way of identifying if a change will be an improvement to the workflow (i.e., Factors for effective value streams)

It may be that business processes can be modified to include this, but an approach that inherently does it is more useful. We have seen too much of what results from “intentionally incomplete” – not many people fill in what should be present.

Additional Resource: Why Leaders Should Focus on Value Streams

First Principles, Mindsets/Values (ASG)

Experience teaches nothing. In fact, there is no experience to record without theory… Without theory, there is no learning… And that is their downfall. People copy examples, and then they wonder what is the trouble. They look at examples, and without theory, they learn nothing. W. Edwards Deming

First Principles (Flow, Lean, Theory of Constraints)

First principles are principles that cannot be decomposed into other principles but stand on their own.

Here are some first principles for knowledge work:

1. We can complete smaller items faster than larger items.
2. Local changes sometimes make the overall performance worse.
3. We cannot manage what we do not see.
4. Delays in workflow, in getting feedback, and in taking advantage of lessons learned cause waste.
5. We only see what we think and talk about
6. When people work beyond their capacity, it creates delays in workflow and in feedback that create additional work to be done (waste).
7. Handoffs cause a loss of knowledge and information.
8. People doing the work have more insights into how it should be done than those managing them.

First principles are used to provide a basic understanding of what is happening and why. Thinking from a first principle standpoint means to try to understand the most fundamental truths in a particular situation and to reason up from there. You test your conclusion on what you think are fundamental truths. In knowledge work these would testing to see if you’re creating delays in your workflow or in getting feedback (amongst others).

Underlying Mindset and Values

Our mindset and values filter what we notice. This is often called ‘cognitive bias.’ We must continue questioning our mindset and ensure it’s helping us.

• Take a systems thinking point of view.
• Assume you are working in a complex system and attend to the symptoms of complexity (lack of visibility and potentially non-linear events).
• Have an attitude of doing things just in time.
• Focus on the delivery of value to the customer.
• Continuously improve your mindset by using both double and triple-loop learning.
• Have a positive attitude towards management. If they are not cooperating, ask yourself what they do not see and provide that to them. Notice how this requires improving their understanding.
• Respect people.
• Those close to the work usually have the best understanding of what needs to be done.
• Have those close to the work make decisions, but provide them with the information they need to make good decisions
• Attend to and mitigate risk.
• Use metrics to see if you are progressing in the right direction.
• Recognize that work is not complete until the customer has received value from it.
• Make learning a habit.

Guidance (ASG)

There are four main dimensions to effective workflows:

1. what is being worked on
2. how the teams are organized
3. how the work is being done
4. how much work is being done

Success and Value

• Get clarity on what success means for you and your organization
• Focus on value creation for your clients, staff, organization, and society
• Focus on delivering high value quickly that is easily consumable
• Attend to the quality of the product

Attend to the effectiveness and efficiency of your workflow

• Use pull, manage queues, and focus on finishing
• Work on small items of deliverable value
• Have short feedback cycles at all levels of the work
• Organize your people to eliminate delays and handoffs in the workflow
• Start with a fit-for-purpose starting point

Leadership and Management

• Have leadership provide clarity on the why of the organization
• Have management work to create a great working environment for the people of the organization
• have those close to the work make decisions and provide them with the information they need to make good decisions

Overall Guidance

• Understand the customers’ value streams
• Design a customer journey that improves their operational value stream
• Align your efforts around improving your development value stream
• Focus on value delivery with high quality. Then see how your team works within that context.
• Recognize that those parts of an item to be released that are not finished represents incomplete work. The more incomplete work that is present, the more risk is present.
• Look for ways to work with others.
• Work on small items of value.
• Minimize delays in the workflow by managing queues, focusing on finishing, and avoiding handoffs.
• Organize people into teams to reduce handoffs within a team and between teams.
• View handbacks as symptoms of misunderstanding or discovering a prior step was not done correctly.
• Attend to the constraints in the system. Don’t try to improve everything at once.
• Focus on global improvement and be aware of local improvements that don’t address global improvements.
• After completing something, look to finish something else before starting something new.

A Note About Amplio’s Focus on Workflow and Systems

Theories of Flow and Lean suggest that we must attend to the workflow across the organization, not just the people creating the value. This provides a holistic perspective that can shorten the time to market.  The Theory of Constraints is also consistent with attending to the workflow. Edwards Deming (the person the Japanese credit with bringing quality to Japanese manufacturing) provided evidence that 96% of errors were due to the systems people used – not so much the people themselves. While this evidence was for manufacturing systems, it also holds in knowledge work.

The focus on workflow instead of people is not a degradation of the importance of people. It is just the opposite. It is based on our trust in people, so we don’t need to manage them. Instead, we want to give them an effective, efficient, sustainable environment.

A Sidebar on the Differences between first principles & Scrum Theory (ASG)

First principles are fundamental truths that stand on their own

Amplio mentions a few:

1. We can complete smaller items faster than larger items.
2. Components of systems interact. Improving one aspect of a system may adversely affect others, so the overall system’s performance worsens. In other words, local improvements sometimes makes the overall performance worse.
3. We only see what we think and talk about.
4. Delays in workflow cause additional work to be done due to slow feedback and lack of timely application of information.
5. People working beyond capacity causes delays that create additional work to be done (waste).
6. Handoffs cause a loss of knowledge and information.
7. People working on too many things will cause delays.
8. You can’t manage what you can’t see.

This is not a complete list. Take a few minutes to review them. See if you can come up with something in your past experience that validates or invalidates them. This way you don’t need to believe them because you were told them. You should believe them (or not) based on your own experience. Note how this process you do here can also be used to explain things to people who don’t have experience in Agile.

You may notice that Scrum doesn’t mention any of these. Although, if you reflect on the practice of a cross-functional team and pulling work every Sprint, you can see that Scrum is tacitly following these to some extent. I have found that being explicit about it is useful. This is why back in ’07 I said it was useful for Scrum teams to think of Scrum as a partial implementation of Lean. Ken and Jeff rejected that, btw, although Jeff changed his tune before his book “Scrum: The Art of Doing Twice the Work in Half the Time.” Even so, these thoughts have never made it into the Scrum guide other than a frivolous statement that Scrum is based on empiricism and Lean thinking – much of Scrum is inconsistent with Lean thinking.

I propose the theory that if you are consistent with these first principles you will do better than if you are not. This has them act as a guide without restricting you on the practices you do. So, while Amplio does say you need to be consistent with first principles, it does not say you have to follow any practices but instead should use the first principles to decide what practices will work best in your situation.

Now, let’s look at Scrum theory. Scrum suggests you should have transparency, inspection, and adaptation. These are not first principles, however. They are practices that Ken and Jeff suggest you take. And yes, the theory part is that if you do these, things will be better. And I agree. The question is, can you do them?

But these do not explain why or how things work. So if you have trouble with the Scrum practices you must follow to be doing Scrum, you will only experience these guidelines as constraints and not something that provides guidance on how to improve your practices.

Let’s take an example. Scrum’s using pull to determine how much to do in a sprint is an implicit reflection of the first principle of not overloading teams. But it doesn’t mention limiting WIP within the sprint. Consider having too many stories open at the end of the sprint. OK, we have an impediment. But what caused it? First principles can guide us – especially the factors for effective value streams based on them. Possibilities include:

1. stories too large
   2. too many stories attempted
   3. stories not clear enough
   4. too many handoffs
   5. too much WIP within the sprint causes waste

This is a key difference between first principles and Scrum theory. Scrum theory is like saying “buy low and sell high.” Good theory. But how? First principles provide guidance on what will directly make things better. It’s worth noting that people new to Agile will be able to relate to and understand first principles because they will have experience in working with or against them. Talking about Agile is uncomfortable for some because it’s new and they don’t want to admit they don’t know its concepts. But everyone can relate to first principles even if they haven’t been applying them. Most first principles fall into the category of “what people already almost know.” Very often they just need to be pointed out and people understand them. This can provide a bridge of understanding between teams and management. Without this, you have to explain to people why Scrum works. They don’t really care and often don’t want to admit that they don’t know.

Without first principles, people are left to follow until they understand. While a team may be willing to do this, many managers won’t be.

Factors for Effective Value Streams (ASG)

Purpose

Provide us with a way of looking at complex situations where we can make decisions based on a few factors. Making decisions on how to do our work is complicated. We need a guide to help us see which of two or more options is better. Factors for effective value streams indicate how well we are doing and whether a new way of working will be an improvement.

Why

It is not always clear how to improve our work in complex systems. It is helpful to have a guide that can help us make better decisions on whether a change to our way of working will be an improvement. The set of factors for effective value streams presented in this book can be used to predict whether a speculated action will improve the current situation. The decision is guided by taking actions that improve the factors of the scorecard and avoiding actions that make them worse. The contention is that the more we abide by these factors, the more excellent value we will achieve.

While suggested changes still need to be validated, with a deep understanding of the factors for effective value streams, we can make changes with high confidence that they will be an improvement. Otherwise, we’ll be left to try things we have less than full confidence in. This often leads to stasis in our methods, as people don’t like to fail. If an intended improvement doesn’t manifest itself, the issues we look at will provide us with learning.

Description

Time for reflection

Consider when you were introduced to an organization where your immediate reaction was, “Wow, this place is cool. I can see why they get so much done!”

Now consider when you were introduced to an organization where your immediate reactions were, “Wow, this place is horrible. How do they get anything done?”

You are likely reacting to your tacit knowledge –what you know but are not always consciously aware of. Consider what factors you are looking at. For example, are people talking to each other? How busy are they? These factors are likely present in both situations, but in one direction, they are being done well, and in the other, they are not.

Consider how consistent these tacit judgments are in different places. While each may appear different, a set of actions should be taken that make places easier to work in.

The factors for effective value streams indicate how well we’re doing in specifying, create, and realize business and customer value based on observing several factors. These factors relate to what work is done, how it is done, and how people are organized to accomplish it.

There are five aspects of value streams. These are:

1. What is selected to be worked on (what goes into the value stream).
2. How much people are working on at any one time.
3. The workflow of the value stream.
4. How people in the value stream are organized.
5. The mindset we have.

These are shown graphically in the following figure.

Each of these can be described in more detail:

What goes into the value stream

1. Are small items of high value being worked on?
2. Is what is being worked on visible?

Workload of people in the value stream

3. Are people’s workloads within their capacity?

Workflow of the value stream

4. Is there quick feedback as well as few delays in workflow?
5. Is the quality of the product (both its behavior and Value Creation Structure?

How people in the value stream are organization

6. Are people organized in a way that reduces waiting for others?

Mindset

7. Are people attending to the value streams?
8. Is there attention on managing the eco-system and not the people?
9. Is there a focus on continuous improvement?

They are asked in the form of a question to see the direction of what helps (when answered with yes) and what hurts (when answered with no). The selection of these factors is not sacrosanct, and they can be adjusted as you learn and for your context. The factors have the following characteristics:

1. Each factor is apparent and can lead directly to action that will lead to improvement.
2. The set of factors provides us with enough information to make good decisions for almost all challenges faced by teams doing knowledge work.
3. We’ve identified a minimal number of factors to provide coverage while keeping things as simple to understand as possible.

In other words, are they of use while providing coverage and not being too complicated?

A deeper “why” these factors for effective value streams are so important

Doing things poorly will slow us down. But consider that other things are taking place as well. For example, not getting quick feedback will create extra work for us since we’ll make a mistake and work on the wrong things and the wrong way. Therefore, attending to the factors for effective value streams can enable us to work without delays and not create much extra work we don’t need to do. Therefore, attending to the factors for effective value streams enables us to eliminate the creation of waste.

All but the last factor are based on following first principles. The last factor is driven by the fact that we want to create value for our stakeholders.

Key point

It is worth considering that there are two different types of waste. The first is work we didn’t need to do, for example, overplanning.  The other is work we created that we now need to do but only because we created it—for example, fixing bugs.

The Factors Work Together

It is essential to notice how the factors work together. As you improve one, it either improves the others or makes it easier to improve them. For example, notice how working on small items will help us achieve quicker feedback. This is consistent with Dr. Eli Goldratt’s (creator of the Theory of Constraints) view that work principles are harmonious. He called this “Inherent Simplicity” in his and his daughter’s seminal book “The Choice” and contends that complex problems are more straightforward than they look if one knows where to look.

Let’s look at a few of the interactions between these factors:

• Small work items are easier to get feedback on.
• Pull methods are the best way to keep workload within capacity
• Having work and workflow be visible enables collaboration
• Working in one value stream makes it easier to keep workloads within capacity

There are of course, many many others. The key point is that they usually enhance each other and virtually never work against each other. They are in harmony.

The factors for effective value streams provide a holistic view by attending to different aspects of a system. This makes it very useful.

How we use the factors for effective value streams

These factors can be used in two ways.  First, they will help identify what we’re doing causing our problems. The second way it will be used will be to verify if a new practice being considered to replace a current one will be an improvement. If the change works against these factors, we shouldn’t try it.

Examples of Each Factor

1. Are small items of high value being worked on? You accomplish this by working on small items that will provide value in and of themselves or are small slices of functionality that will provide feedback. We’ll learn business artifacts that will assist with this later in this book.
2. Is all work and workflow visible? Have all the work being done visible. Also, have the agreements of how you are working be clear to everyone.
3. Are people’s workloads within their capacity? Avoid having people working on too many things. Don’t overschedule people with work. This is usually achieved with pull methods since the people doing the work have the best knowledge of how much can be worked on without overloading them. One should also attend to the presence of handbacks[1] as they will result in delays to completion.
4. Is there quick feedback as well as few delays in the workflow? Communicate with product owners as often as practical. Build things in a way that enables quick feedback. Minimize delays in the workflow.
5. Is the quality of the product (both its behavior and how it’s built) high? Get clear on what it means to achieve a requirement before working on it. Use the feedback when you complete anything to ensure you’re working on the proper functionality.
6. Are people organized in a way that reduces waiting for others? Cross-functional teams are one way of doing this when they are practical and achievable. Consider delays, handoffs, and handbacks symptoms of a poorly organized team structure. Attention should be given to keeping people in a minimal number of value streams while ensuring their skills are available if they are scarce.
7. Are people attending to the value streams? When making decisions look at the overall effect the action will have. Local optimizations rarely affect overall value add unless the action relieves a constraint.
8. Is there attention on managing the eco-system and not the people? Is micro-management avoided? Are people being given the context within which to make good decisions? The focus should be on improving the environment.
9. Is there a focus on continuous improvement? We must improve how we’re working (single-loop learning), while also choosing better practices (double-loop learning), while also learning how to create better practices (triple-loop learning).

[1] A handback is when one person hands some work to someone else, and then later they come back

The factors for effective value streams are about what works, not how much resistance there is to change.

The factors for effective value streams are focused on what helps or hurts the flow of value. It intentionally leaves out factors like how we got here, how we can change it, or what factors help change it. These are critically important. They have been left out because we want the factors for effective value streams to measure the effectiveness of our practices and indicate what we can do to improve things. In later chapters in this workbook, we will deal with these other issues of how to change things.

Key Points

• We can use each of the factors to see how well we are doing
• The factors for effective value streams provide a way of determining if a change in actions will improve the effectiveness of our value stream

How We’ve Manifested the Purpose

We started this chapter by stating, “we need a guide to help us see which of two or more options is better.” The Factors for effective value streams ask us questions about how well we are doing. Each question points out whether we follow the first principles of knowledge work.

<< What is a professional coach? 

Part II. The Disciplined Way to Talk With People >>