One of my favourite gifts last Christmas was my fitbit. For those of you who do not know the product, it is a small monitor that keeps track of your activity through the day. Since I work from home, I have spent entire days in front of the computer without moving, so the fitbit motivates me to move and provides a report (available anytime on my phone and emailed to me weekly) of the days I did not.
My biggest frustration with the fitbit is the connector it uses to charge and communicate. The three small copper contacts get dirty and because you use it when you exercise, it gets dirty a lot. The function of the fitbit is not impaired. It continues to count steps and store the data each day and will communicate with my phone via Bluetooth to upload statistics until it runs out of battery. But when the contacts get dirty, I spend time and effort cleaning them, distracting me from the function that the fitbit is supposed to help me achieve (the exercise).
In some ways, DevOps promises a solution to a similar problem. It promises to help an organization optimize processes inside teams (for example, a dev team’s use of agile practices) and to enhance the connection between teams such as the development and support teams.
The following definition of DevOps is my favourite, as it suggests both promises.
DevOps is a new term emerging from the collision of two major related trends. The first was also called ‘agile system administration’ or ‘agile operations’; it sprang from applying newer Agile and Lean approaches to operations work. The second is a much expanded understanding of the value of collaboration between development and operations staff throughout all stages of the development lifecycle when creating and operating a service, and how important operations has become in our increasingly service-oriented world - http://theagileadmin.com/what-is-devops/
Much of what has been written about DevOps applies to the first part of the promise. Organizations are reworking their internal processes very effectively, accelerating the pace and effectiveness of development organizations. They also provide a great deal of motivation inside the development teams because the results are tangible (like the fitbit).
One significant challenge for DevOps, however, is how to measure the collaborative relationship between development and operations, including professional services and support. The challenge is two-fold. First, the organizational outcomes that DevOps is seeking to make happen lag behind the activities that drive them. We do not know whether or how much we have improved efficiency until we see the results, which can happen perhaps as long as a fiscal quarter after we have implemented a change like DevOps. Second, the operational measures for development and operations organizations are often significantly different, sometimes to the point where they come into direct conflict.
What DevOps requires to fulfill its second promise is a new measure to make sure that the connections are made effectively and do not become a source of wasted time and increased frustration. I recommend a specific measure, focused on the process of knowledge handoffs between development and operations. Verna Allee, in her works on Value Network Analysis, suggests that one way to determine if a process is effective or not is to count the number of times a process loops back.
Why is this looping behavior critical in the case of DevOps? If operations does not get the knowledge it needs to deliver value to the customer/end-user, team members have to go back to development to get the knowledge. The costs are significant – lost time, higher backlogged demand in development and operations, frustration on the part of both teams. Also like the fitbit, the measurement and display of tangible progress is instrumental in sustaining effective behaviors.
To measure the hand-off between development and operations, we have to know three things.
- When development hands-off knowledge
- How many clarifications are requested
- When operation accepts the knowledge
Tracking these three moments in time will give us two related numbers:
- The number of clarification loops
- The total cycle time from knowledge creation to acceptance
Both of these are actionable measures. Development and operations teams can work together to reduce the number of clarification loops and the time each loop takes to resolve. The act of measuring the loops itself will help to drive change. If all the teams involved in DevOps adopt this connection measure as one of their operational metrics, it will improve. The results will be observable and significant in critical organizational outcomes like efficiency and profitability.
Have you or your organization used DevOps when managing your operations? Do you agree that it enables development and operations teams within the business to work together effectively? Please share your thoughts and experiences in the comments box below.