I had to stop myself half-way through writing this blog and start over. I had written a very bland and well-worn introduction to this topic – measuring the organization’s wasted time and effort with ineffective knowledge hand-offs between development and the support team. I had football references, baseball analogies and even a short story about relay races in track. Wow. Boring. If that’s your speed, this isn’t the blog you are looking for.
That’s because handoffs aren’t boring. They are critical touch points between one team and another that can either speed us to great results or trap us in endless back-and-forth loops. As our organizations evolve and adopt new practices, like DevOps, the knowledge that support teams receive from development will change in both volume and format. How do we capture whether we are handing off knowledge better or if we are backsliding?
As this definition of DevOps points out, an important part of the practice is the collaboration and connections between the development team and the rest of the organization.
“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 lifecyclewhen creating and operating a service, and how important operations has become in our increasingly service-oriented world [emphasis added]” –http://theagileadmin.com/what-is-devops/
So, how do we start measuring the effectiveness of this second trend?
I believe that there are two things that we have to do to capture the effectiveness of handoffs in a DevOps organization. The first is to change our understanding of documentation (the most common format for knowledge exchange) and its handoff. For a lot of organizations, documentation is a checkbox on a project plan. It’s a to-do item and sometimes it’s not even on the critical path. Second, we have to change the perception that documentation is something to be handed-off. Documentation isn’t something that can be given, it has to be received. Making this small change has a huge impact. The quality of the documentation (and whether it is complete or not) is judged by the person who will use it. The receiver has to affirm that the documentation is complete for the project to be considered complete.
This affirmation of completeness is the gold standard for evaluating the effectiveness of the knowledge hand-off. It’s a stake in the ground that is the foundation for a new measure, called the looper (see my blog on the specifics of how to create and use the looper metric). The time and effort the organization expends on both sides – development and support – getting to the affirmation is the baseline for handoff effectiveness. Then it’s up to both the development and support teams to work together to reduce that time and effort.
The work will pay off on both sides with more effective handoffs and less wasted time. Productivity gains like that have a direct impact on the organization’s cost and scalability, neither of which your boss finds boring.
Check out another blog in the series on DevOps – Why support organizations should care about DevOps.