This last weekend, I was at a DevOps summit that included a wealth of different perspectives, from some of the early founders of the approach to many people who are applying it to their organizations today. For those of you who aren’t familiar with DevOps, it’s a set of practices that apply Agile and Lean (popular in development) to operations teams. It also seeks to leverage these same approaches to speed the handoffs between these groups.
My particular approach to DevOps has focused on the second part, measuring and speeding the handoffs between these two groups. Sometimes, I talk about these handoffs in formal terms – like traditional documentation like manuals or formal knowledge articles. In the summit, Ben Rockwood (the Director of IT & Operations at Chef Software) rightly pointed out in our session that the one of the goals of creating great software is to make the manual unnecessary.
But that doesn’t mean that there isn’t knowledge to hand off, both internally to the operations teams and externally to customers or end users of the solutions we build. But that knowledge will look different than it does today.
Matt Hooper (Product Evangelist – Service Management ITSM DevOps at LANDESK Software), in this same summit, points to a critical distinction that we need to make when we talk about knowledge in DevOps.
DevOps knowledge is contained in artifacts not articles
In knowledge management practices (like Knowledge-Centered Support or KCS), an article is a short, formatted slice of knowledge. Artifacts are containers for knowledge in any form. Some of these artifacts are purpose-built for hand-offs between organizational units. Stefania Bandini (et. al.) discusses specific forms of knowledge that are boundary artifacts. They say that artifacts “… can also play the role of boundary objects (Bowker et al., 1997) living at the border between different groups (CoPs) and supporting the coordination of the activities performed by the actors constituting them.” In most organizations, boundary artifacts that deliver knowledge from development to operations (and eventually to support) teams already exist and vary in complexity and formality.
You can think about an article as the invitation to a wedding. It conveys specific information very quickly. What time is the ceremony? Where will it be? Can I bring a plus one? The guest book is an artifact. It contains information that the maried couple will need later – to write thank-you notes, for example – but not in a pre-formatted way. In development activities, there are lots of these artifacts, some of which look like articles, but most of which do not.
These artifacts will change AND we still need to measure them
As our approaches to developing and implementing products change, so will these artifacts. We are likely to see many more artifacts that don’t look like any of the ones we have seen before, like
- Short videos explaining user experience context to help with infrastructure sizing
- In-application “orientations” to features and functions
- Workflow templates in release management tools
But their purpose remains the same – to capture and transfer knowledge and aid in the coordination of activities between groups, like development and operations teams. As a result, we need feedback loops in place to ensure that they are provided the needed knowledge with a few clarifications as possible. Counting those loops and trending them over time can form the foundation for a proxy measurement of the handoff process, itself (as you can see in my article on measuring knowledge handoffs in DevOps) and the effectiveness of the artifacts in facilitating that process.
In my next blog, I will talk about the challenges that this capture and transfer represent and some specific, actionable ways to address them.