Use PROMISE as a Strategy for Managing Modern DevOps Transformation
Help your engineering teams, solution owners and stakeholders plan and manage DevOps transformation work aligned on pillars and value-based milestones.
Planning and incrementally delivering DevOps transformation work is a “black box” to engineering teams and solution owners who are responsible for delivering results. Non-functional requirements (NFRs) go along with DevOps transformation work but sometimes get overlooked during product planning and cause unplanned delays. Relying solely on backlog management systems such as Jira is an insufficient strategy for providing operations context and the overall big picture to stakeholders and engineering teams.
It’s, Well…Complicated
DevOps transformations have additional complexity as current products and services must ship while modernization efforts are undertaken. A visual representation of DevOps transformation work anchored on pillars and value-based milestones complements planning and helps “underwhelm” engineers with the amount of work that needs to be completed. To help smooth the way forward, we developed a series of pillars to form the foundation of a DevOps transformation. We call it PROMISE.
“Relying solely on backlog management systems such as Jira is an insufficient strategy for providing operations context and the overall big picture to stakeholders and engineering teams.”
DevOps Pillars
As a planning artifact, PROMISE defines a collection of guiding principles that scope a tactical, milestone-based delivery approach for DevOps transformation efforts. PROMISE builds awareness of hidden work that teams overlook when shipping code to production on new operating models. PROMISE elicits requirements that further improves delivery estimates.
The seven pillars that form PROMISE are:
Pipelines: Repeatable and convention-based build & delivery automation for infrastructure and products with an emphasis on moving security and quality to the left.
Reliability: Providing the highest, right-sized availability and performance of products measured by business and engineering service level objectives (SLOs).
Observability: Continuous operations transparency using contextual logging, error reporting, audit, metrics, and systems monitoring for operators and SEV1 first responders.
Maintenance: Ongoing care of systems including documentation, runbooks, upgrades, and reduction of operations toil.
Infrastructure: Provisioning and upkeep of code-first cloud resources and integrations based on tried and tested secure coding techniques.
Security: Ensuring the safest systems and products with a focus on sufficient hardening, encryption, and defense-in-depth approaches including robust handling of PII and PCI data compliance.
Environments: Independent operation of immutable nonprod and production systems.
“PROMISE elicits requirements that further improves delivery estimates.”
PROMISE Milestone Strategy
Treat DevOps transformation planning like any other product feature or tactical planning session. When planning an initiative that changes a current operating model to something new, use PROMISE to shape an incremental, three-phase delivery approach within these scoping milestones:
- M1: Independent build & publish of versioned apps/artifacts while providing continuous feedback to engineers, then…
- M2: Manual deployment of built apps/artifacts/infrastructure to non-production cloud environments, then…
- M3: Automated canary deployments to production environments and production readiness before general availability
Milestone 1 (M1) delivers a robust continuous integration feedback loop to engineers on the new operating model. However, be aware of ongoing legacy pipes and automation maintained by the team. Be wary of lift-and-shift approaches that move applications and delivery pipes between environments without a redesign. They may incur technical debt and propagate poor practices from the current operating model.
Milestone 2 (M2) focuses on delivering fully provisioned infrastructure as code (IaC) to non-production cloud environment(s) that supports “manual” deployment of published apps/artifacts/assets against the new operating stack. This milestone provides deployment feedback to engineers, enables testing of new product features on independent environments, and moves quality engineering to the left.
Milestone 3 (M3) automates the manual deployment steps in M2 and ships apps/artifacts/assets to production environments on a cadence. During this milestone, the apps and teams are production ready, with sufficient training, runbooks, documentation, monitoring, and escalation polices in place for program/product operations.
“Treat DevOps transformation planning like any other product feature or tactical planning session.”
We Still Need to Maintain the Current Stack
Effort will still be required to ship features on the current stack, so focus on bite-sized milestones that balance current operations with the future state. Look for planning opportunities that chip away at operations toil faced by the team on the current operating model. An intermediate planning state, or stepping stone approach, may deliver new value faster to the Team. Use the M in PROMISE for capturing ongoing legacy maintenance activities. This further improves capacity planning and delivery estimates as ongoing maintenance activities are explicitly captured. Formal recognition of current operations work is an empathetic nod to teams who are responsible for maintaining key business functions, while modernizing the infrastructure and apps that run on it.
“Formal recognition of current operations work is an empathetic nod to teams who are responsible for maintaining key business functions while modernizing the infrastructure and apps that run on it.”
PROMISE Transformation Template
Use this planning template to organize the effort. Vertically defined milestones on the template cut through the PROMISE principles. The horizontal swim lanes, aligned on each PROMISE pillar, capture key planning activities that scope the efforts of each milestone. Be on the lookout for empty PROMISE swim lanes during planning sessions!
Color-code spike or research activities that are important for bootstrapping work in later milestones. Use the planning artifact for story decomposition and presenting high level overviews to solution owners, engineers, and sponsors. No one wants to sit in a meeting all day and form a mental model staring at Jira tickets!
“No one wants to sit in a meeting all day and form a DevOps mental model staring at Jira tickets!”
PROMISE Transformation Example
In this example, a team has planned a milestone delivery plan for a container-based operating model hosted on a cloud provider. The plan captures key activities, dependencies, bootstrapping (spikes), and on-going maintenance work along the PROMISE swim lanes. Other work may flesh out during the course of delivery and other priorities may shift.
This team tracked milestone progress with a color coding convention:
- Green marks completed work.
- Blue denotes in-progress work.
- Yellow highlights deferred work (things change).
- Orange captures spike or bootstrapping work.
Use the PROMISE planning template as part of a recurring status readout to sponsors and stakeholders.
“Be on the lookout for empty PROMISE swim lanes during planning sessions!”
Post MVP
Once the new stack has baked and the team has built up its operating experience, consider planning a continuous delivery (CD) model post MVP. Use the PROMISE planning template to flesh out hidden complexity within a CD model.
Before embracing a CD initiative, give the Teams room to build their operating confidence on the new stack using a delivery with cadence (DC) approach — teams ship code on their terms. This adds an element of safety — things are in our control — while the team continues to work out the operating wrinkles. Humans push the delivery buttons first, then automation takes over later.
“Humans push the delivery buttons first, then automation takes over later.”
Summary
PROMISE removes the mystery of planning DevOps transformation work. Bring your teams and stakeholders together with a holistic planning artifact that anchors teams around a catchy DevOps mnemonic. PROMISE isn’t a panacea for all your operations/transformation planning work. What PROMISE provides is a different, higher level view of new and and ongoing operations/transformation work that is easy to consume, track, and visualize. Use PROMISE to validate your backlog and account for the complexities of a DevOps transformation that ensures the best possible outcomes for stakeholders and customers — on-time delivery with minimal disruption.
“What PROMISE provides is a different, higher level view of new and and ongoing operations/transformation work that is easy to consume, track and visualize.”
Contributors: Tienlong Pham, Bob Dorff (Chicago Build Center), Tyrone Osilesi (Washington DC Local), Rob Cummings (Seattle Build Center)
