This Fall, my daughter came home with an assignment for her social studies class. She was supposed to create a replica of the headdress for the ancient Egyptian goddess Hathor. She had to study each element of the headdress and understand what the snake, the sun and the horns meant to the people who worshipped Hathor. As we constructed the headdress out of foam, paint and metal, we talked about the meaning of the pieces. We were building an artifact – a physical thing that represented the beliefs of the ancient Egyptians and still carries a meaning for us today.
In DevOps, we also build artifacts that link development and operations activities together (for more on these artifacts, see my earlier blog post). These artifacts are “boundary objects” that facilitate both team’s functions. In the case of DevOps, they are the concrete documents/articles/videos that represent the development team’s context and knowledge about this project or deliverable.
Creating DevOps artifacts is challenging
So, why are they so challenging to create? There are two reasons, both of which give us a clue about how we can construct DevOps knowledge artifacts.
- Traditionally, operations teams get too much knowledge/context from the artifacts the development team delivers. Operations teams have to spend time unpacking the key elements they need from the knowledge they receive. Worst case, the operations team ignores important elements because they are buried in a formulaic document.
- As artifacts persist through the service lifecycle from deployment to support (e.g. incident management), the insights are less fresh in the mind of the developer or professional services consultant. It takes time for both to reconstruct what she was thinking. Also, this lag time means that constructive feedback on content or structure of the artifact misses several (or even dozens) of sprints. There is still value for the feedback, but it’s less than you would expect.
How to make effective DevOps artifacts
There are many ways to address the challenges of creating DevOps artifacts, but there are three rules that will make them much more effective.
- Get the consumers to define the needed artifacts. Development teams don’t always know what the operations team uses (or reuses) in an artifact. The Operations team needs to identify what it needs to know and then let the development team provide it in a consistent way.
- Define the needed artifacts based on experience, not wish-lists. Operations teams shouldn’t hold their development counterparts to an idealized set of knowledge. The best way to define the need for content is to look at what the operations team found that was useful in existing artifacts and what additional content they needed.
- Build feedback loops as close to the delivery of the artifacts as possible. Even if the support team might not answer questions about a release for days, weeks, or even months, a representative should provide quick feedback on relevant artifacts so changes can be made before the next sprint.
Following these three rules (which mirror the Agile techniques at the foundations of DevOps) will create more effective artifacts and should reduce the number of loops required for an effective hand-off of a new product or service (counting the loops gives you a good sense of the effectiveness of your handoffs, see my blog on measuring these handoffs).