When working with some of our larger customers we frequently run into common barriers to change. Change is difficult and, no matter how often we say it, there is no silver bullet for how to get there. However, we can say there are commonalities in approaches, things we’d look for and actions we’d take in response to those findings. When we look at the delivery of technology within organizations we often come across the barriers within how the teams are organised but even more frequently, how the organization is working with technology is the bigger barrier. Developing powerful roadmaps is valuable and greatly helps with generating alignment and a common vision.
In my last post I spoke to blame culture. In this post I’m going to talk through the second of three common organizational problems we encounter, not looking at the entire system, and how attaining visibility will help you overcome barriers to better achieve your business outcomes.
Not seeing the system as a whole
When looking to change their organization through the adoption of modern delivery practices, people can make the mistake of not looking at the complete system they are looking to change. For example, they adopt a framework such as Scrum to organise their delivery teams but fail to consider how the value a team generates will get into the hands of a customer. In short, they only look to optimize a part of the overall system by which the organization delivers value.
This leads to disappointing results from the introduction of these practices and often a backlash from the existing organizational system. To overcome this we have to both look at and improve the entire system and not just a part of it.
Let’s take a simple example, taken from The Goal by Dr. Eliyahu Goldratt: Consider an organizational system consisting of three stages, manufacturing, operations and sales. On average, manufacturing generates 10 units a day, operations can ship 10 units a day and sales sells 10 units a day.
So what happens if we make improvements that increase manufacturing capacity by 50%? We made more units so we must be more efficient?
However, it does not make the system 50% more efficient. Even though you can manufacture more, if there is not sufficient capacity in operations to test and ship product and in sales to have sold it. What will happen is you will end up with more product in your inventory (you’ve introduced a bottleneck to the system). To truly increase throughput we need to improve all parts of the system.
We also need to consider the impact on people. If strong barriers exist between the different parts of the flow, often only changing the system in one place causes animosity as the subsequent parts of the flow feel a fault for not being able to meet the demand. It also has a tendency to create additional work within these areas as they try to satisfy the new input with their existing tools and processes, causing yet more frustration and resentment.
This problem manifests in large organizations who, when adopting practices such as Agile, fail to consider the entire system and end up with product (within software development areas the product would be code) sitting waiting for operations. Operations in turn is frustrated by trying to put changes into production faster than they safely can. Even worse the delay in getting these products in front of customers means there is no feedback in the system as to whether what was created delivered value.
So what can you do?
The first step in solving this is to start considering your entire delivery system as a whole, and applying the principles we call modern delivery here at Xodiac. This can be achieved through conducting a value stream mapping exercise with all stakeholders to truly map out the delivery process and identify waste (if you want to read more about value stream mapping and applying lean practices to software development in particular, take a look at Mary and Tom Poppendieck’s seminal book Lean Software Development). Once we understand the system better we can identify where we should make improvements. Following the theory of constraints, first written about in The Goal, the output of a system will be determined by one constraint. To improve the throughput of the system we must focus our efforts on fixing this bottleneck.
Another way of stating this is that a system is only as strong as its weakest link. Local optimization or optimizing anywhere except at that weakest link will have little effect on the throughput of the overall system and may even have a detrimental effect. Even if people look busy and engaged we may still not be reaching our goal.
Secondly, we need to determine metrics that we will use to identify the health of the system. Determining metrics that will be meaningful to the organization is one thing, creating a common understanding throughout the organization as to how to interpret those metrics is another. All metrics can be “gamed” and this needs to be taken into account as driving towards the wrong metrics can badly impact your desired outcome.
Thirdly, we provide capabilities for teams to solve problems themselves in the delivery pipeline. We do this through the delivery of tools backed by training, guidance and coaching. We can help teams adopt and drive change by providing a safe environment to experiment and learn. In large complex environments it is often key to also provide guard rails to teams initially, allowing them to focus on solving targeted problems and not get distracted by the vast array of possible solutions.
Conclusion
Overcoming the lack of understanding of how work gets delivered within an organization is a change that affects everybody and not just the delivery or operations teams. Organizations frequently struggle with this due to the cultural barriers, physical separation, and, as above, from simply not seeing the entire picture. The consequence of which is implementing changes that don’t achieve the desired results.
In the third and final article of this series I will talk to why organizations form into silos the way they do and how to work to generate alignment across disparate groups.
