Step 3 to get started with DevOps: Prioritize your improvements
I regularly work with clients who are interested in implementing DevOps principles to improve their software delivery, so in this series we’re discussing how to get started. In the last of my first two posts on this topic (see step 1 and step 2), I discussed how to assess your current practice maturity and identify practice improvement goals for your initiative. At this point you have defined the direction you want to take your organization, you have outlined measurable goals and you have a benchmark of your current state. Now it’s time to connect the dots by prioritizing your changes and driving to measured milestones that include quick wins.
Remember, when you introduce improvements to your DevOps capabilities, it’s always a good practice to use a soci
DevOps capabilities and practices model
When one of our consulting teams works with a client during an asse
The example shown to the right identifies current and recommended practices and gaps. We facilitate a discussion to identify and validate considerations including pain, complexity, priorities and maturity objectives. These considerations help clients to create a consistent prioritization of the improvements. Once prioritized, we define incremental releases or groups of changes designed to achieve specific and measured value.
For clients whose improvements can be limited to changes you could adopt at once, you would then lay out a roadmap to adopt (which I’ll discuss in my next blog post). For medium or large initiatives, you want to group changes into incremental improvements and then adopt through piloting and release rollout until you achieve your objective goals. This pilot and release model is briefly introduced in “Ado
A client recently completed a project of implementing a centralized repository (definitive media library, DML) to use for their application development (AppDev) teams and their outsourced data center management team for governing and deploying. Their goal was to standardize and reduce costs by consolidating onto one technology or process. Their original adoption plan included a governance model for all binaries and an automated deployment capability. The deployment automation process fit nicely into the operations teams’ business model and was very easy to adopt.
After introducing their approach to the AppDev teams, they received immediate feedback: “How were the hundreds of AppDev teams going to deliver the binaries without an automated process? They would have to create their own solution or perform the deliveries manually.”
Fortunately the core team responded immediately and decided to provide an automation service for all AppDev deliveries. This was used on their first pilot. The ease of use was socialized by the teams and helped to improve AppDev acceptance. Considering priorities from different stakeholders (when there is value and differences) can help you to achieve the key wins during adoption and have your improvement go viral.
Sometimes pain is in the eye of the beholder. One example of a client’s pain was their inability to measure defect root cause effectively to take corrective action. For example, they used “environment” to denote anything outside of the application or quality assurance teams’ influence. Corrective action, in these cases, was inefficient and most actual causes were deployment actions, configurations, infrastructure or the differences between environments.
Other pain may only be seen from the outside. An example from a few years ago was an organization that resourced an integration and build management team that performed all integrations and builds at the component team and application levels. During our engagement we proposed a practice to move to a continuous delivery, merge, share and build approach. The initial view was “we don’t see this as pain and always plan for the costs.” After a short bit of math to explain the cost to change or maintain current practices, they relabeled it a pain.
Complex versus complicated changes
A complex change affects a group of obviously related practices, people or technologies that have a relatively large number of relationships or in which the degree and nature of the relationship is imperfectly known. A complicated change is hard to understand, plan and execute. The latter is what causes the most problems and usually results in reduced value or added costs to get similar results of other complex changes. Therefore, avoid complicated approaches to simple event changes and weigh the complexity as a variable in your heat map.
Deploy improvements incrementally
At this point you have a set of priorities with an understanding of their value and potential impact on your practices and software delivery. What we really need is a package of improvements we can adopt in phases or incrementally. These increments should produce specific, measured outcomes to our software delivery.
During our facilitated workshops, our consultants bring improvement patterns that our clients recently used to achieve specific, measured outcomes. For a do-it-yourself improvement, you will want to consider your top priorities against how much change you can effectively absorb. Then summarize each of the changes into a specific set of measured outcomes. I find that most clients define each of their outcomes in one of these four groups: accelerating time to market, improving quality, reducing rework, encouraging collaboration.
Always remember that outcomes are meaningless without a means to measure them. Once you agree on measures, set a benchmark for how and what you do today then work toward a metric. Continued support from your peers and organizational leadership is always available when you can explain the results with quantifiable measures.
With your priorities packaged into measured outcomes, you now have what some would call an improvement backlog and release plan. Our next step is to outline these releases and plan our first actions toward a quick win!
I would like to hear your ideas on this and any related subjects. Please post your comments here or message me on Twit
Are you trying to plan DevOps improvements where you are today? Check out IBM’