Stories have played a central role in the Agile transformation of software development teams around the world. Really, stories have been with us since the dawn of communication amongst groups. From cave walls to fairytales recounted and passed down through generations. They have evolved in delivery, but their purpose remains the same: to share common experiences, to teach, and to pass on wisdom.
With Agile as a central tenant of DevOps, we have all been exposed to stories as a concept to get work done on our projects. But they can also enrich reports provided to stakeholders outside of the engineering team. Storytelling and story listening are something you can add to your current processes to make the DevOps results and benefits of relatable for less technical stakeholders.
Just as you would define user stories to help connect design, engineering, and QA to deliver features users receive value from, you can also use them to successfully deliver information to stakeholders they receive value from. There are a couple of ways stories make the quantitative information from sprint statuses, program increments, incidents, and other engineering operations, more relatable.
Use stories to create a richer picture of how, when, and why the efforts of DevOps matter. Knowing a build server does not mean anything without the context of how it impacts engineering's ability to deliver features on time. You can begin to craft the story to:
- Put this data into a human context
- Show actions and behavior of the DevOps team in that context
- Enable external stakeholder to understand the motivations and key results
When stakeholders have context, they can more readily digest the quantitative data of DevOps activities.
By thinking about reporting and communications as a story, it forces you to think about your audience and helping them make necessary connections. The story guides your audience through the data, how it is connected to activities and gives them a clearer picture of how it all fits together.
For example, a marketing executive may not know that delivering a feature depends on the alignment of quality research, design, development, testing, and delivery. As you share your activities, blending the facts and information to make a connection with your audience, the stories can bridge the gaps in their understanding of activities.
You Do This Already
While it may seem out of place, the reality is you do it already. You create stories to give context for the development work. Those same stories will often work when grouped together and used to provide context to reports.
As DevOps continues to expand beyond just software development teams, the importance of making its far-reaching impacts relatable will become critical. Stakeholders across the organization will benefit from understanding what activities go into the DevOps method, and like the stories passed between generations, will adopt some of the method themselves.
Originally posted on DZone.com: