A featured contribution from Leadership Perspectives: a curated forum reserved for leaders nominated by our subscribers and vetted by the Construction Tech Review Advisory Board.
Nationwide
On the Evolution of Agile to DevOps
Carmen DeArdo
The basic problem companies are facing is: how to more quickly react to meet the needs of their customers and be competitive in the marketplace. So the delivery system that needs to be designed is one which reduces the time from idea to customer delivery and feedback, which we define as lead time. It is critical that an enterprise agree on this definition because history teaches us that without this type of True North to guide their activities, it is likely the system designed will fall short of this objective.
An example of this is the agile implementation in most enterprises. Agile can provide better quality and predictability. But because agile is almost always implemented in the design/develop/test cycle of the value stream, it doesn’t provide any true increase in speed of delivery. Large enterprises typically fall into a “water-scrum-fall” model where they still do work as large projects and only go fast through development team iterations.
As shown above, this means that there is still a large delay in getting work to the teams and there is also a delay in getting completed development work into production. So while this approach is a good first step, it generally will not reduce end to end lead time.
Value Stream Focus
What’s more important is that teams are taught concepts which can help them continuously evaluate what is stopping them from delivering more quickly so that they can identify areas for improvement. Key to this is the lean concept of value stream analysis. If you walk up to a team and ask them why they can’t go faster, they will typically say they are waiting for something. They could be waiting for more work to flow into their backlog. They could be waiting for infrastructure needed for development or testing. Or they could be waiting for another team to develop a service they need to consume.
Many teams don’t spend time in retrospectives talking about how to overcome these types of blockers or wait states and developing counter-measures as continuous improvement initiatives. One reason for this is the lack of objective data that can be analyzed to provide insights on this.
It is necessary to move mindsets to think about different ways to solve devops problems
This is where the lead time metric comes into play. By providing teams with this measure, broken into process times for development and testing and wait times as noted above, they can then determine what counter-measures or continuous improvement initiatives are needed to accelerate their delivery capability.
Culture
“Culture eats Strategy for Breakfast” – Peter Drucker
Cultural changes are needed to empower teams to have more self-service and control over their delivery journey. A key cultural component is to achieve a balance between ensuring a capability and the underlying technology can be supported for the entire enterprise while still allowing teams to be empowered to use it in the way that best suits them to serve their business.
A good example of this relates to deployment. In the past, the model might have been to centrally govern and control how deployments were done. This created several problems. It meant that teams which needed more flexibility would be motivated to find ways outside of the tooling to do what they wanted. These types of local optimizations created variations which increased waste and inefficiency. A second problem was that the team owning the tool became a bottleneck for any type of change needed for a specific team’s configuration. This added an SLA to the process which increased the delivery lead time.
A third problem was that any technology changes were evaluated from the basis of comparing tool ‘A’ vs tool ‘B’. This results in decisions primarily focused on financial costs of the tool rather than how the tool impacted the ability of teams to delivery more quickly and efficiently. The evaluation needs to be based on what value is added to the integrated delivery pipeline supporting the value stream.
In some cases, there were actually disincentives built into how tool usage was internally charged back to the teams using them which incented the team to utilize less of an automated tool to reduce the charge-back and resulted in resorting to more inefficient manual activities.
These are the types of true cultural issues that have to be addressed in order to be successful at not only reducing lead time but creating a more efficient delivery value stream and underlying technology foundation that reduces overall costs and improves quality.
Moving Mindsets
As we continue our DevOps journeys, it’s necessary to move mindsets to think about different ways to solve these problems. Everyone in the company needs to think about how they are supporting the goal of being more responsive to the business needs. Reducing lead time and deploying more frequently can’t just be the focus of the IT delivery teams. Optimizing the delivery value stream has to become the focus of the entire organization.
The articles from these contributors are based on their personal expertise and viewpoints, and do not necessarily reflect the opinions of their employers or affiliated organizations.
