How do we answer how long it will take to add a new feature, fix a bug or change a workflow in an application? We often provide answers in terms of how long it takes to complete the development work alone, all while ignoring the total time required to complete the request before and after the actual "work" takes place.
In the Lean Value Stream Map, Process Time (PT) is the time it takes to do the work. Lead Time (LT) includes the Process Time and everything else outside of that for that step. In the case of software development this can include time for ideation, QA testing, deployment time, etc.
Image copyright 2016 The Karen Martin Group, Inc.
Deployment lead time at a typical corporation can be weeks or even months. This is because deployment is often more complex than just dropping some code onto a server or running an upgrade overnight. We are now forced to consider the time “required” to provision a server, or cutover into a new environment, or meet some other requirement that is necessary for deployment in the infrastructure's current state.
Have you ever found yourself asking “Why does it take so long to get a server?” I have been asking that question for over a decade. Every time I go to a customer that builds applications for large teams deployment is a large undertaking. It seems like the wheel keeps getting reinvented each time. (We'll cover some tools that help teams solve these problems in a future article.)
A Common Scenario: Multi-Month Deployment Lead Times
Many large organizations support monolithic apps that rely heavily on manual testing. These apps often have minimal test environments that require a lot of time to set up & manage. If you were to create a Value Stream Map of the development and deployment process it would be incredibly complex.
What happens in these scenarios? Completing work can - and usually does - require heroics from your teams at all stages of the development and deployment processes. Fixing problems in the application can require days or weeks of effort. That effort usually results in poor outcomes for your customers. It's not a recipe for success.
An Ideal Scenario: Multi-Minute Deployment Lead Times
What if we strove for fast, constant feedback on our work? What if every dev team did small atomic code changes? Wouldn’t it be nice to have automated testing in the application so the QA team could concentrate on the hard problems? How about regular code deployments into Production on a weekly, daily or hourly basis? What would the Value Stream Map look like in this scenario? Certainly it should be much simpler.
Let's consider the outcomes in this scenario. For starters, shorter lead times enable a high degree of confidence in changes introduced into the application. No longer do your development and ops teams live in fear of breaking existing features or losing customer confidence. Agile development practices and automated testing regimes passively drive development teams to build modular, loosely coupled architectures so small teams can work with a high degree of autonomy. With smaller changes that are tested and pushed regularly, failures that do get through tend to be smaller and more contained.
Initial Metrics To Begin With
What are some metrics to start measuring to determine where pain points are prior to starting or monitoring your DevOps journey? A few suggestions...
- Lead Times - As previously discussed, the total time from when a request is made to when it is deployed.
- Process Times - Limited to the time it takes to complete the development of the feature or fix.
- Percent Complete and Accurate - For a given Value Stream Map step (ie. coding/unit testing, UAT testing, etc.) this is the percent of Complete/Accurate work items received from the previous step in the Value Stream Map.
The 3 Ways: The Principles Underpinning DevOps
In the book The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win, the authors mention “The 3 Ways” as principles that they have found involved in all successful DevOps practicing organizations. I will briefly cover them and we can go into more detail in future articles.
1st Way: Flow of Work
We should first strive to have fast flow of work, per our Value Stream Map, from development to operations to your customers.
2nd Way: Feedback
What good is running really fast in a direction if you don’t provide fast and constant feedback from the right to the left at all stages of our Value Stream Map?
3rd Way: Continuous Learning & Experimentation
Flow and feedback at all stages of the Value Stream Map can then allow you to create a culture of continuous learning and experimentation. This allows your teams to innovate, share their learnings, experiment on new ideas without fear of retribution, and contribute to moving the organization forward on all levels.