Processes need visions too

Processes are just a collection of best practices based on the context that we are working in. The thing is that the context that we are working in is always changing - so our processes need to change too.

When we examine how we work there are always lots of things that can be fixed. But how should we prioritise among completely separate but equally interesting sounding options?

We have the same problem with prioritising product development initiatives. What if our research tells us that there is potential in an adjacent product line, a new geography or in streamlining the onboarding of the product? Each of the three appear promising but we only have resources to pursue one of them.

This is where a product vision and strategy come into play. We’ve all experienced how products keep adding more and more features until tehy become like those useless novelty Swiss army knives that are no longer fit for purpose. If we want our products to remain focussed and streamlined towards solving particular customer problems then we need to actively fight against the urges to pull the product in every direction. Someone needs to make the hard choices that say where we are going to invest our time and resources - even when other areas look promising. The product vision is the outputs of those hard choices.

For process improvements we need a similar vision.

Lean Manufacturing

Toyota managed to dominate the automobile market with a simple vision: one-piece flow. Instead of having large backlogs at each assembly line station, they wanted to have no backlogs at all. Their insight was that if a problem gets identified they could potentially have to rework all of the items in all of the backlogs. So minimising backlogs increased quality as well as the elad time for each car.

One-piece flow was a completely radical change to how assembly lines operated so they knew they could not implement the new process over night. But by having a clear vision it meant that every improvement idea could be compared to how it helped Toyota move closer to one-piece flow. Over years, and many small improvements, their processes steadily improved until they were leaps ahead of the competition.

Many people tried to implement a similar approach to product development by copying lean manufacturing. But while Lean is perfect for improving repeated processes it is not great for innovative design processes like product development. Work should not travel back upstream in an assembly line, whereas, during design, ideas should bounce around as we learn and try to implement them. That is why we need a different vision for our process.

A vision for product development

90% of features fail to deliver the expected business value. Similarly to lean manufacturing, we need to reduce the end-to-end lead time so we can get ideas in front of customers early and pivot as needed.

When you analyse where most of the time is spent in product development is in handovers between different functions. The time spent working on the feature is tiny in comparison.

But we can’t solve it in the same way as we do for lean manufacturing. Reducing backlogs will speed up overall lead time but it introduces a number of problems. Backlogs allow different people, with different specialisations, to dip in and out of a process and execute their part. For example, you might have senior leadership signing off initiatives, architects designing systems, security analysts signing off releases, SME’s sharing their insights and more. Reducing the backlogs would mean that these people would have to do more frequent small batches of work instead of less frequent larger pieces of work.

Working in smaller batches increases the overhead involved in coordinating the movement of people. Smaller batches means more movements which means that there would need to be ever tighter and more complex planning to ensure that people are available when needed.

There comes a point where the overhead does not justify the improvement in lead time because the system becomes too brittle - like a row of dominoes small delays can have long, and costly, knock-on impacts.

You can’t manage dependencies, you need to remove them

These challenges around coordination become even more pronounced as a company grows larger and the number of people involved in the end-to-end process increases.

Many frameworks and experts suggest a dual approach to solving this. More planning and more managers. By doing larger planning exercises like quarterly PI planning people can become aware of the dependencies between initiatives and plan around them. The challenge is that things never go according to plan so you need to constantly adapt your plans as the realities of work continue to cause unexpected outcomes.

The frameworks tend to recommend new managers to deal with these problems. Whether it is a Release Train Engineer, a Chief Product Owners or a Scrum of Scrum Master the approach is the same - have a person responsible for maintaining order out of the continuous change to the upfront plans.

But the truth is that dependencies cannot be managed. There are too many variables. Changes will always pop-up and even with people trying to manage them these changes will continue to have costly knock-on effects.

Instead of trying to manage dependencies we need to go the other way.

We need to remove dependencies. This means that we need to move all of the steps, from initial idea through to satisfied customers, under the control of a single team.

By using this process vision, teams should be able to compare and contrast different improvement options. Whichever moves the team closer to the vision should be prioritised.

In the same way that removing all backlogs overnight was not possible for Toyota, we do not expect companies to empower teams end-to-end overnight either. New challenges will emerge as we empower teams, particularly around alignment, but the slow and methodical approach to empowerment gives teams time to solve those issues.

Over time, the teams and companies that adopt these processes will continuously improve and build better products than their competitors. And, after all, that is the end goal of why we build products.