It's not easy to measure something that is largely subjective. Many DevOps teams recognize this difficulty when they try to assess their productivity.
If your goal is to measure a software delivery project from start to finish, then you want to look closely at flow efficiency. Flow efficiency is a DevOps metric that allows you to see how long it takes to deliver a project, and it helps to determine how a project could become more efficient.
Let's examine how you can identify and measure flow efficiency in DevOps through an understanding of value-adding time and lead time.
How to approach flow efficiency
Like many DevOps elements, flow efficiency comes from the lean framework. Flow efficiency is the practice of gauging value from a time perspective and the lead time it'll take to add that value for the required end state. As for who can do this work: It can be a person -- like a developer writing efficient code -- or machine, such as a DevOps pipeline.
Another example involves optimizing the programming language you want to use to write an application. If your team is considering Python or Go, first run some benchmark tests. Then, review those tests and see which language yields the faster application. Once the team has that information, developers can optimize the route for future development.
However, don't think of flow efficiency as only about speed. Development teams should remain focused on the quality of the software.
How to measure flow efficiency in DevOps
Once your team has an optimization strategy in place, the next step is to consider the mathematical approaches to the measurement of flow efficiency.
The key elements in a flow efficiency calculation are the following:
- lead time
- working (active) time
- waiting time
Development teams want to track all the work that goes into planning, building and delivering the software project. Keep careful track of this data; as always, quality results depend on quality data.
Once your development teams know how many hours go into lead time, work time and wait time, they can divide the working time by the lead time and multiply the result by 100%. The resulting number will represent flow efficiency for the time spent.
Organizations will want to view this data and see how dev teams can improve their processes.
How flow efficiency tools can help
Once the development team has empirical data on flow efficiency, developers can turn to tools to properly document it for all the involved parties. The best way is to use a Kanban board. These are available through collaboration tool suites such as Asana and Trello.
A Kanban board allows you to track key aspects of a project, such as time spent and who is assigned to which task. These boards enable teams to track lead time, working time and waiting time. Further, each board can have tickets or cards attached that identify times for each project in a given column.
Along with identifying and managing flow efficiency in DevOps, Kanban boards allow development teams to estimate when a project will be done, when it's complete and other scheduling information.
Another important element of a Kanban board is the ability to manage and watch elements throughout the project. If multiple people are assigned to the same card, you can also assign watchers to receive notifications whenever a team member changes a card. Kanban boards also allow for other members of the team -- such as project managers, engineers and senior managers -- to keep an eye on flow efficiency throughout the duration of the project.
Why measuring flow efficiency is so rare
While it's an appealing idea, flow efficiency is not typically one of the development metrics most organizations focus on. Managers tend to consider flow too time-consuming to measure.
There's also a financial constraint. Many organizations won't want to dedicate a salaried position to flow efficiency. Management might view flow efficiency as a task that an engineer or developer should handle.
Management will usually be the first to bring in flow efficiency numbers, unless an engineer or developer is particularly interested in the added task. Some engineers will enjoy this duty, while others will prefer to focus on coding.