Manifesting Business Agility

There are many ways to look at Lean. Many people have taken the principles they've seen in Lean manufacturing and directly translate them into the product development arena. But manufacturing is not like product development. In manufacturing we're trying to limit variation and the only discovery is how to improve the repeatable process. In product development, we're trying to discover what is needed and how to create a physical manifestation of it if we're creating a product, a better process if we're if we're creating a new service or software if we're creating a software product. This process is considerably different than reducing waste in a manufacturing line. A metaphor can be in manufacturing we're cooking from a recipe, while in product development we're creating the recipe.

What we want to do is to look at the principles underneath Lean-Thinking. 

• Take a systems thinking approach
  • Attend to the entire value stream
  • Align the organization around purpose
  • Think long term
• Delight customers
  • Discover true value
  • Deliver incrementally to different customer segments
• Invest in your people
  • Give them a sense of purpose
  • Provide them with a great working environment
  • Acknowledge them
• Increase flow
  • Have efficient value streams
  • Avoid handbacks
  • Remove delays
  • Small batches
  • Speed, quality and low cost work together
  • Focus on flow efficiency, not resource efficiency
• Build quality in 
  • don’t tolerate defects
  • test-first
  • common cadence and integration
  • look to the source of your challenges
• Keep getting better
  • use the scientific method
  • look for emergent behavior
  • the role of management
  • Plan Do Study Act

Last blog I posted DOWNTIME, a common way to look at waste in Lean-Thinking. Here it is again:

• Defects
• Overproduction
• Waiting
• Neglect of Human Talent (Unused talent)
• Transportation
• Inventory 
• Motion
• Excess Processing (over/extra processing)

With a little reflection, it's clear that the O, T, I and M relate to manufacturing. Attempting to bridge Lean manufacturing to Lean product development is not as effective as looking at what the underlying principles to both are. I've converted this into waste of Lean Product Development. 

• Eliminate waste. Build quality in. When errors are found, stop the work and immediately get to the root cause of the error. This highlights that quality is important and is often due to the system. Not stopping the work means we're more than likely to keep repeating the error. Eliminating defects in product development means to be clear on what is needed before building it. In software development this means conversations between the product owner, developers and testers that create acceptance tests prior​ to construction. (Defects)
• Build in small increments to provide value quickly and to turn your attention to the next item that will provide more value. Building incrementally helps avoid building what's not needed. As we deliver value customers become more aware of what they want.  If they don't know what they want until you show them what they don't want, the show them something as soon as possible. Small things get developed faster. In addition, the return on investment of new features tends to level off. Make sure you stop working once the rate of return slows down. (Overproduction)
• Delays in workflow and feedback.  People tend to be always busy, but if you follow the work you will see that it waits much, even most, of the time. But work doesn't sit idly as it waits. It grows, that is, it takes more work to complete because of the waiting than it would have otherwise. When there are delays in feedback, we continue working thinking we're on the right track when, in fact, we're not.  This causes more work.  (Waiting)
• Learn as an organization. ​Lessons are often learned in pockets without any transference of knowledge. Effective organizations are learning organizations. (Neglect of Human Talent)
• Multi-tasking is one of the most insidious causes of wastes. It directly causes delays and lowers the effectiveness of people.It is most often caused by improper allocation of capacity to value streams. Avoid allocating people to more than one value stream whenever possible. (Transportation).
• Have the minimum amount of work in process (WIP) that you can have while keeping flow going. When work in process goes beyond capacity you are working against all of the afore-mentioned principles. (Inventory)
• People being in multiple value streams makes then multi-task. In product development, shifting ones attention from one item to another not only makes people ineffective but results in loss of information while adding delays. (Motion)
• Considering features too early usually results in overthinking. Incrementally designing a product enables you to attend to features that are truly needed. (Excess processing)

Most introductions to Lean focus on a variety of principles such as the following from the Lean Enterprise Institute (note the acronym)

• Defects
• Overproduction
• Waiting
• Neglect of Human Talent (Unused talent)
• Transportation
• Inventory 
• Motion
• Excess Processing (over/extra processing

This is definitely a useful way of looking at Lean. But another way is to look at what these would suggest you look at, want to achieve and something you have to do to achieve it.

Attend to how workload relates to capacity. Workload should never exceed capacity. Doing so creates multi-tasking, delays and waste. This requires having a well-defined intake process and do portfolio/product management to ensure working on only the most important items.

Assess the efficiency of your value streams. The people in most value streams are multi-tasking due to them being in multiple value streams. This causes delays and waste. Have people allocated to only one project as much as possible.

How large are your batches of work? As a rule, smaller increments that realize value is better. Do your work in small increments and use iterative development to discover what’s needed. Decompose strategies into initiatives into small business increments. See Minimum Business Increments for more. 

Is collaboration taking place across the value stream?  Teams should not be geared towards local optimization but should be looking at improving the effectiveness of the value stream as a whole. Create a common cadence for planning, coordination and synchronization.  Institute DevOps or the equivalent across all value streams.

What is management’s role? Management needs to attend to improving the environment so that people can get their work done. Management must look up the value stream to see what the direction of the company is and then collaborate with those downstream to interactively build a great environment within which they can work. 

How long are your planning cycles? Plan in short cycles. Work on removing impediments to shortening the cycle. Work should flow from initiatives to realization of value. Consider whatever requires an increase in planning times to be an impediment and work to remove it. 

What is the quality of your product? Quality includes both internal (how it’s been built) and external (what customers think of it). Build quality in. Get clarity on specific acceptance criteria that can be used to validate what's being created before starting work. 

These suggestions are based around Inherent Simplicity. More on this at Dealing with Complexity by Creating a Bias For Simplicity 

We hear so much that we can’t make predictions in complex adaptive systems that we start to believe it when we have a huge amount of counter evidence. Complex systems are those in which a perfect understanding of the individual parts does not automatically convey a perfect understanding of the whole system’s behavior. This means one can’t be certain what a change in one part of the system will have on another. But this doesn’t mean that there isn't a large degree of cause and effect for the system as a whole.

Let’s consider the following situations:

• Product managers pushing more work on their teams than they can handle
• People working on multiple projects projects being staffed by part time people
• People working on large (3 months or more) batches of work
• Teams being motivated to focus on their own interests
• Managers micro-managing their teams
• No planning across the teams that need to work together
• Product quality is low

When you see these things I suggest you can readily predict the results. And that you can reasonably accurately predict improvement if you improve them. The question is how? But the first step is seeing these issues.

What’s forgotten in the complexity conversations is that seeing what our problems are is looking in the past – which complexity theory does not say we can’t do. We can see cause and effect after the fact. While we can’t accurately predict what our changes will be, we can accurately see what’s causing our problems.

I read many articles from Agilists about the difficulties they have with management. I believe that many of these problems spring from many in Agile (Scrum in particular) being based on empiricism alone and not the scientific method. That is, focusing on the how while leaving out the objective and the why.

Empiricism is a theory that states that knowledge comes only or primarily from sensory experience. The scientific method adds rationalism to add theories as to why we get our experiences. The scientific method includes empiricism to validate its hypotheses. Without this ‘model of understanding’ people tend to discount new ideas – especially people who have been successful and think highly of their own ideas.  See Evidence Without Theory Is Often Ignored.

i think much of the challenge with enrolling stakeholders and management in Agile is that many Agilists don't present a model that they can understand. Stakeholders and managers have often risen to where they are by being competent and fixing problems. Agile not only has a history of ignoring them, but with Scrum, for over a decade vilifying them in a subtle way (chickens and pigs). This hasn't fostered trust. 

This background should not be ignored - it certainly isn't by many managers. When the time comes where a manager feels they need to get something done, they probably don't feel very included or respected by the team.  So managers having a bad attitude with Scrum teams shouldn't be a surprise. But let's look a little deeper. How can the team convince the manager that interrupting them is a bad thing? What rationale can they use? The answer is - "it's against the rules of Scrum." Do you really think a manager cares about this? They may feel they are against the rules of Scrum."

What managers need to know is why the interruption would be a bad thing. Not from the team's perspective, but from the organization's perspective. This is where Flow and Lean thinking are quite useful. They present a scientific hypothesis on why injecting delays add waste, slow development down and increase the chance of errors. Now, I'm not saying managers will necessarily listen to this either. But a good one would - at least if the cost of the interruption were higher than the cost of not doing the interruption.

It also provides a basis for conversation and collaboration between the manager and the team. Empiricism alone won't enable this conversation - at best it would only create an agreement to try things. But managers have certainly experienced problems with imposed delays. If the situations are quite different, the abstractions (theory) that Flow and Lean provide may bridge the gap between manager and team. But without that, the manager may feel compelled just to impose his thinking on the team instead of just trusting them.