Software development is easier than ever but building something that customers love is still really hard. This might sound simple but the first step in building great products is ensuring that everyone is aligned on what you are trying to achieve. Software is a team sport and it takes a lot of effort to ensure that everyone is rowing in the same direction. If you believe that everyone is aligned in your organisation try asking your team three questions:

1. What customer needs are we solving? (What)
2. What business objective are we delivering? (Why)
3. Why are we following the process we follow? (How)

Creating a high performing and productive team is hard. Everyone intends to do well but in the absence of clear alignment on the what, why and how of working some initiatives might end up working against what you are trying to achieve.

Identifying your customer needs and aligning them with your business objectives are challenges in their own right but in this article we are going to focus on how to get alignment in your team on the process that they follow, and why.

Is there a way of working vision that can work for teams that vary from for-profit companies, to charities, to government teams? I believe so, but I’m not going to tell you what it is…….  yet. If I tell you straight out you won’t really “own” it and the likely reaction would be “That sounds good” and you’ll forget about it as quickly as you read it. So instead we’re going to work through why this is the Vision and why teams should adopt it. So let’s get started!

Why do organisations exist?

Organisations are created to serve a need for a set of customers. Governments serve the needs of their citizens, charities serve the needs of their recipients and private companies serve the needs of their customers.

Principle 1: Organisations exist to serve the needs of their customers

So the primary purpose of a product team derives from this; teams must deliver solutions to the needs of their customers. Since teams deliver different "products" - a novel new service, a lower cost offering, a luxury good - I will shift the language in our vision to say that teams must provide “value” for their customers.

Vision attempt 1:
Teams must deliver value for their customers

This is a good start but it’s too high level to guide how teams should work. Organisations invest money on the assumption that the teams return more value than they consume. This means that teams need to both align with the business goals and they need to work as efficiently as possible.

Vision attempt 2:
Teams must efficiently deliver value for their customers in ways that align with business goals

Can the team use this to guide how they work? What does efficiency mean to you? I've previously written about how to measure efficiency in teams. To summarise, even though it is counter-intuitive, optimising the efficiency of the parts of the process (e.g. dev efficiency, design efficiency) actually slows down the overall delivery. Instead, you need to optimise the throughput of the system - the speed of delivering software to customers.

Principle 2: You need to optimise the throughput of the whole system rather than the efficiency of the individual parts

The key learning around optimising the throughput of the system is that batch sizes needed to be reduced because large batches amplified problems too much and they trapped too much cash flow. The benefits of minimising batch sizes outweighed the perceived loss in efficiency at individual workstations.

Principle 3: Smaller batch sizes deliver value to customers quicker and release capital back to the organisation earlier

So let’s update our vision to replace the word efficiency with what we have learned from the manufacturing industry and their focus on flow.

Vision attempt 3:
Teams must deliver a rapid flow of value for their customers in ways that align with business goals

So why do I still call this an attempt? What is wrong with this? I could game it.

There are plenty of things that I can do to speed up delivery but they involve incurring technical debt or other items which will eventually catch up with me. I could stop focusing on bugs or code maintenance and my delivery of features will increase. But over time delivery will slow because I will have to pay down the technical debt or do “the big rewrite”. So we need to make sure that any initiatives taken are sustainable.

Often people see speed and quality as competing objectives. When we release large pieces of code there is more surface area for things to go wrong. And finding bugs becomes exponentially harder based on the scale of the changes made. So by releasing small pieces of code regularly we can minimise the risk of having issues while simultaneously making it easier to fix issues when they arise.

Principle 4: Smaller batch sizes improve sustainability by reducing the risk of failure and minimising time to recover

Vision attempt 4:
Teams must deliver a rapid and sustainable flow of value for their customers in ways that align with business goals

This is looking good. Now we need to follow through. What would you do to action this vision?

A standard way would be to set up a business process improvement project. Bring in a group of highly qualified people to investigate the As-Is process, identify the problems, theorise over the best solutions and report back on their recommendations. A review committee could analyse the findings. If approved a change initiative would be ramped up a few months later to implement and embed the new processes over a period of months to years.

Have you spotted the problem yet? This is a large batch approach to solving the problem - there will be a lot of value tied up in the process until it finally gets realised. Unfortunately things change so quickly in business that by the time that the changes are implemented they may no longer be the best solutions for the challenges. These big batch change initiatives lead to conflict and resentment in the teams where the changes are being implemented because they ignore the context of each team and impose generic approaches that are not locally optimised. People don’t actually hate change, they hate being forced to change.

Clearly this isn’t an ideal, efficient or sustainable approach. But what alternative options are available?

Back to Manufacturing and Toyota

In the 1980s Toyota needed to start producing cars in the U.S. due to tariffs and they decided to partner with GM as they had no experience in the U.S. labour market. They took over an old GM factory that had been the poorest performing factory in the U.S. before it was shut down. They hired back most of the same workforce and it instantly became the top performing factory in the U.S.  

Given the stellar performance, GM representatives went to the plant to study the setup to see how they could make similar efficiencies elsewhere. With their newfound knowledge the factory managers mirrored the Toyota setup. But the efficiencies didn’t come.

Trying to figure out what was wrong they returned to the Toyota factory to see what they missed. To their surprise a number of things had changed. One example was that instead of all of the parts being placed on shelves around workers at each workstation the parts were attached to the assembly line and moving along with the cars. Confused by this, the GM factory owners asked which configuration was the best setup. The Toyota factory manager explained how the plant expanded from four models to eight models. There wasn’t enough space on the shelves to stock all of the parts for eight models so they had to change as the number of models increased.

The GM managers asked a lot of questions about the way of working but they never asked about the actions that led to these ways of working. Toyota had a different management approach which elevated the authority of the people on the line and encouraged continuous improvement.

Authority

In the GM plants, the golden rule was “never stop the assembly line”. Stopping the line was one of the offences that could get you fired. Even if workers spotted a problem they had to keep going, maintaining the workstation efficiency was more important than defects (and defects were another team’s responsibility anyway). Defect reports would be filed and sent to management who would do root cause analysis on the problem and instigate new procedures, weeks or months after the defective cars had been processed. And those preventative measures always seemed to be additive instead of removing previous steps which increased the burden on the staff.  

In the Toyota plant they had the complete opposite approach: stop the line the second you find a flaw. You can’t sell a faulty car, and since throughput is based on sales, allowing the problem to continue will directly hit the performance metrics. Small batches can stop problems from being amplified but people also need the authority to act on the information that they are receiving. Faults will make their way into every system so when they are uncovered the people working on the line need to be able to react quickly and decisively. Therefore people are authorised to stop the line until they fix the source of the problem.

Principle 5: Move authority to the information instead of moving information to the authority

Continuous Improvement

The graph for productivity improvements shows a steady growth over time, until the imposition of tariffs in the early 80’s impacted sales. Is this the pattern that you would expect if there were change initiatives being implemented? Large scale change initiatives should result in step changes in productivity, but that's not what happened. Change isn’t something that periodically happens in Toyota but rather it is part of how they work. Every person is expected to suggest ideas on how improvements can be made. Rather than asking a committee for approval, the idea is evaluated on whether it moves the company closer towards their vision. If it does then an experiment is started to see whether the initiative delivers on the expected vision. Like above where the teams are authorised to stop the line the teams are empowered to identify solutions and put them into practice. They don’t need to wait for a management review or outside analysis.

While this sounds fairly straightforward this is incredibly hard to build into the culture of a team. Let's think through the example from above. When the number of models increased they moved from having parts at each workstation to putting the parts on the assembly line. There is effort required in preparing the parts for each model and somebody has to do it - but this effort has shifted from each workstation preparing their own parts to an upstream team preparing the parts for all downstream workstations.

In your company, what would be required to get an agreement like this between departments or functions? How many sessions would you need to run arguing over the pro’s and con’s? In Toyota they don’t look for consensus, they measure each initiative on whether it helps them get closer to their vision. If it does, then teams need to work through the impacts of that decision, even if it means some teams taking on more work.

Principle 6: Continuously iterate towards better processes and ways of working

With this we are ready to finish our vision.

Vision:
Teams must continuously optimise towards a rapid and sustainable flow of value for their customers
in ways that align with business goals.

Principles:

1. Organisations exist to serve the needs of their customers
2. You need to optimise the whole system rather than the efficiency of the individual parts
3. Smaller batch sizes deliver value to customers quicker and release capital back to the organisation earlier
4. Smaller batch sizes improve sustainability by reducing the risk of failure and minimising time to recover
5. Move authority to the information instead of moving information to the authority
6. Continuously iterate towards better processes and ways of working

Some criticism I have received about this vision is that it conflates what we do (“rapid and sustainable flow of value for customers”) with how we do it (“continuously optimise”). This is an important point to highlight because they can't be separated - in order to deliver rapid and sustainable growth we need continuous optimisation. Processes suffer from process debt just like code and designs suffer from technical debt and design debt respectively. Over time the conditions that led to the current process change so it is no longer the best process to follow. Continuous optimisation needs to be embedded into the teams to avoid slowing down over time. Put another way, continuous improvement is as much what we do as the delivery of software.

I would love to take credit for this vision but I have borrowed this directly from Dan Terhorst North, who in turn has built upon the work of Eliyahu M. Goldratt, author of the book The Goal, and many others.

I hope that I have been able to convince you that this vision provides a “mission statement” for teams to create alignment on how the team should work and why. If not, the future articles on how to deliver on the vision won’t be as interesting as I had hoped!

I’m always keen to learn from other experiences so if you have any questions or Let me know your thoughts on twitter @roryuxdx