Asking teams to improve the software delivery lifecycle (SDLC) tends to be either a hyper-specific or nebulous request. When hyper-specific, leaders must spend a lot of time in the trenches to understand the behaviors, tech, and processes that need to change. This isn’t sustainable. When nebulous, the most eager people start making changes based on their opinions. Without a clear strategy, everyone ends up freestyling. Opinions clash, priorities diverge, and progress stalls. Real change requires alignment, not just initiative.
Improving your team’s SDLC isn’t as simple as flipping a switch; it’s more like rewiring an airplane mid-flight. This complex challenge demands a clear strategy to guide what changes matter most, when to tackle them, and how to do so in a way that brings the team along. Without that, even the most motivated teams get pulled in different directions, and progress fizzles out.
So how do you build a strategy that aligns teams, prioritizes the right changes, and actually works in the real world? That’s where DORA comes in.
Enter DORA
DevOps Research and Assessment (DORA) is a research program that’s spent over a decade studying how engineering practices influence organizational performance. Founded as an independent initiative and later acquired by Google, DORA has become the gold standard for evidence-based insights into what makes software teams successful.
DORA’s research points to two traits that matter more than anything else when it comes to building strong software teams:
- Speed: How quickly your team delivers working software, measured by Lead Time and Deployment Frequency.
- Reliability: How safe and stable those changes are, measured by Change Failure Rate and Mean Time To Restore.
Fast and reliable teams fix issues faster than their peers, adapt more quickly to changing demands, and consistently deliver updates that meet real customer needs. Engineering teams who possess these traits were also found to be highly correlated with better business outcomes.
Furthermore, the DORA research identifies specific capabilities that underly speed and reliability, grouped into three categories:
- Climate for Learning: Encouraging constant experimentation and improvement.
- Fast Flow: Enabling rapid, regular software releases.
- Fast Feedback: Quickly identifying issues and correcting course.
You can explore all the capabilities across those categories on DORA’s Website. Here are a few examples: Code Maintainability, Work in Process Limits, Deployment Automation, Job Satisfaction, and Test Data Management.
Putting This Into Practice
Merely setting goals like “improve code maintainability” is still too vague. Many of the DORA Capabilities cover a lot of ground and can have unclear paths forward. Teams need more direction than “improve your DORA capabilities” in order to make steady progress.
Identifying missing practices in a team’s toolkit is a key part of making progress. A practice is a specific, repeatable action or technique that software professionals use to improve how they build and deliver software. For example, “Perform Automated Linting on Commit” is a concrete practice that helps with both Code Maintainability and Streamlining Change Approval—two important DORA capabilities. This type of automation prevents inconsistent code from piling up, reduces the number of code review nitpicks, and helps keep technical debt from accumulating unnoticed.
Another example: “Create and maintain a shared test data generation script” is a practice that supports the Test Data Management capability. It ensures that developers can easily spin up consistent, realistic test environments without relying on stale or hand-crafted data. This reduces dev friction, boosts test reliability, and simplifies debugging.
Before going off and experimenting with new practices, it’s important to first get the team aligned on what needs to be improved. That’s why we created an open-source DORA Capabilities Maturity Assessment. Now teams can pinpoint the capabilities that are acting as a performance bottleneck. We’ve also distilled our improvement process into a repeatable strategy teams can actually use. We call it S.T.E.P.:
- Survey: Assess current capabilities objectively.
- Target: Identify the most impactful improvement areas.
- Experiment: Play around with new practices to enhance targeted capabilities.
- Polish: Continuously refine practices and adapt based on real-world feedback.
The S.T.E.P. process is cyclical: once practices prove effective and become team norms, teams return to the start to reassess their progress. This strategy gives structure to what otherwise feels like chaos. Instead of everyone picking their own improvement projects based on personal opinions, S.T.E.P. helps the team agree on where to focus and what type of experiments to try next.
After several iterations, teams gain confidence in the process, turning improvement from a political nightmare into an achievable goal. Leaders are freed from micromanaging every change and can focus on enabling progress rather than coordinating each detail.
It’s Not All Rainbows And Sunshine
No strategy guarantees a smooth path. Teams still face real challenges—interpersonal friction, legacy tech, cognitive biases, deadlines, and budget limits can all get in the way. A strategy like S.T.E.P. cuts through the noise of endless options and helps teams focus on the few improvements that matter most in an incremental fashion.
By giving teams a simple, repeatable way to own how they work, leaders no longer have to direct every improvement effort themselves. Instead of managing the details, they can spend time on the deeper issues that no strategy can fix on its own.
Failure As A Guide
High-performing teams aren’t extremely effective because they never fail. They succeed because they reduce the cost of failure to the point where they can take risks, learn fast, and adjust without throwing the team off course. Low-performing teams typically prioritize avoiding failure at all costs, sacrificing speed in the process.
To foster the “failure as a guide” mindset:
- Start by prioritizing experiments in areas that reduce the impact of introducing bugs or outages.
- Define clear criteria for an experiment’s success and failure before you experiment.
- Timebox every experiment to create urgency, encourage focus, and make stopping what isn’t working easier.
- Normalize open discussions of setbacks during retrospectives, emphasizing learning rather than blame.
Learn From The Community
Fortunately, there’s already a wealth of valuable engineering practices out there. We’ve gathered practical, proven techniques that have helped our clients improve and made them freely available in our open-practices repository. Each practice in the repo is tied to a specific DORA Capability, with helpful context and resources to make adoption easier. We include important gotchas, implementation tips, and a simple step-by-step guide to help teams apply each one with confidence. It’s free to use—and if it helps your team, we’d love for you to contribute back so others can benefit too.
Set The Strategy Before You Start The Work
Great software teams don’t happen by accident—they’re built through consistent focus, shared priorities, and a clear plan for improvement. Strategy is what keeps good intentions from unraveling when things get hard.
Whether you’re trying to reduce time-to-market, stabilize deployments, or boost morale, you need more than a vague goal—you need a path forward. The S.T.E.P. strategy offers just that: a simple, repeatable way to align your team, pick the right improvements, and move forward together.