The Story of Unified Backlog, Value Streams, Maturity Models to implement DevOps…

Often people ask me about how we do we operate a development team and an operations team in a DevOps or a DevSecOps way? How different is DevOps from the Agile way of product development?

By DevOps don’t we just mean automation via some platforms and tools to accelerate product development and reduce the manual way of integration, release, and deployment? What are the metrics that truly differentiate and justify the ROI for investing in DevOps or DevSecOps or DevSecBizOps?

The answer is all the above but in a fashion that’s well-threaded, well connected and towards a single common goal with an organization-wide sponsorship and clear definition of business objectives. Most organizations take one or more of the above or try to implement DevOps because everyone is doing it or it’s cool to be called a DevOps team. It isn’t really limited to two groups – development and operations but can be extended to other associated groups like security, infrastructure, biz ops, etc.

So, how do we go about this journey? How do we build a team that will operate in such a way? What are the key success factors that drive the effectiveness of a DevOps Transformation? How do we manage the change?

We start with the overall business objectives or goals. Some examples could be –

• Speed: Time to Capability
• Experience: Ease of Use
• Quality: Satisfaction of Use
• Reduced Operating Cost: Economical to Build
• All the above, this is what most people want.

Next, the baseline metric for each one of them and establish a target metric and a time frame to achieve the same. Here are some examples

At this point, a very critical step is Change Management. If this transformation must succeed, it will need active participation and collaboration of the team it’s going to impact plus a very clearly articulated set of goals/targets. This is where the executive leadership announces their sponsorship to the transformation, articulates the goals and paints the vision of the benefits this transformation will bring to the people on the ground.

Now that we have our goals setup and the stakeholders are aware of it, the next important thing is creating a set of unambiguous Business Value Streams (BVS) each with objective(s) to impact one or more of the above Business Metric (BM). This needs to be followed by communication to all the stakeholders on a continuous basis keeping them connected and briefed on how the work they do is or is not impacting those set-off business metrics.

Designing a business value stream model could be tricky as it needs a clear understanding of the group of stakeholders involved, their current state/way of working and their idea about the transformation. It is common that each one of them will have their own perception, understanding, beliefs, and idea about what DevOps is and how they will go about implementing it. At this point, the overall DevOps Transformation Lead should introduce a DevOps coach who job is to work with each team member and define the concepts of DevOps – the building blocks for them to leverage and use, the learnings from other groups or organizations and best practices to avoid known pitfalls and setbacks. At the end of it, the team should be presented with a set of options like a set of Lego pieces and asking them to form the most meaningful structure aligned to their business, their environments, constraints with a focus to impact the business metrics in a positive way.

Let us look at some examples of Business Value Streams –

• Stakeholder Journey Map/ User Experience
• Build & Deployment
• Enhanced Security
• Platform Health

Once we have established the Business Value Streams, we need to identify Product Owners for each one of them and have them map their value streams with the Business Metrics. It’s possible that each of the value streams can map to multiple Business Metrics and vice versa. For example, the Build and Deployment BVS can impact 3 Business Metrics – Faster time to Capability, Reduce Operating Cost and Improve the Quality of the Product. Hence, it’s important for the Product Owner to devise a simple dashboard or report the progress of their value stream to their own team or teams. At the end of the day, they are accountable to ensure that the value stream metrics are connected to the business metrics and impact the same in a positive way.

At this point, the Product Owners are ready to get their hands dirty and start engaging with various groups.

For our discussion, let’s say there are 3 groups – development team, operational support team and security governance teams who are working together to build a new product or continue to incrementally enhance an existing product.

At this point, the Product Owners create something called a Unified Backlog for the Business Value Stream.

This backlog gets inputs (read epics, features, user stories) and priority from a variety of stakeholders like business teams, operational support teams and the security teams when the product gets developed.

The Product Owner is expected to triage the requests and ensure that the value Streams gets a prioritized list during sprint planning. This model of operating a DevSecOps team takes time and maturity to operate.

Now that we have established a model, let’s understand a little more about how different organizations achieve a level of maturity while implementing DevSecOps for their product development. Interestingly, change in “culture” is sometimes the largest focus area while transforming a team to operate in DevOps fashion

“Culture does not change because we desire to change it. Culture changes when the organization is transformed – the culture reflects the realities of people working together every day.”

Managing the change of culture is accompanied by a change in skills when it comes to DevSecOps transformation. As part of the DevSecOps transformation, it’s critical to have a well-defined strategy of change management synced with the overall DevSecOps transformation. This means keeping stakeholders apprised of changes proactively on the progress the team is making in terms of change goals along with the impact the team is bringing on the overall DevSecOps teams.

Let’s look at a few cultural changes that an organization may have to undergo –

• Continuous Improvement: Refinement of the agile processes and tools
• Continuous Integration/Delivery - “Automation First” & “Everything as Code” mindset
• Continuous Learning - Align, train, certify on required skills and concepts

Often organizations establish baseline metrics for these and then continuously measure to ensure that there is progress on the various parameters that impacts the overall culture of the organization and aids to adopt DevSecOps. This is what drives the overall maturity model of DevSecOps transformation across people, processes, security, and technology. The maturity model is a set of criteria defined and aligned to organizational needs. It reflects the progress made on the product design/development process, delivery of a product and the overall business metrics. Here is a sample framework of a maturity model, which can be leveraged by organizations to assess, plan and improve their overall maturity.

To summarize, the true motive of DevSecOps transformation should stem from a critical business need sponsored by an executive leader who is accountable for that business need. There is no “big-bang” change or “one-size-fits-all” formula for DevSecOps transformation. It’s an iterative evolution of a team leveraging the best practices, frameworks, and models available to leverage, some of which I discussed above.

Disclaimer: This article is an output of my personal research, experience, compilation from various sources online and offline. The recommendations are my personal opinion and not that of any organization. All the information herein is intended as general comment and not a substitute for professional assessment and advice.