0 / 24

Model 32 of 74 · Technology & Data

Software Development Maturity Assessment

Assess software development practices across planning, coding, testing, and release.

Pillars & areas

Plan

Plan the work

  1. 01Development Process & Planning
  2. 06Documentation & Knowledge Sharing

Build

Write quality code

  1. 02Code Quality & Standards
  2. 03Testing & Quality Assurance

Deliver

Ship with confidence

  1. 04Build, Release & Deployment
  2. 05Security in Development

Levels

  1. 1FirefightingReactive & inconsistent
  2. 2DisciplinedRepeatable & standards-driven
  3. 3Engineering-LedMeasured & optimised

01 Development Process & Planning

How does the team plan, prioritise, and track software delivery work?

0/4 answered

DP-1How does your team decide what to build next?

Think about whether work is prioritised based on business value and effort, or whether the loudest voice wins.

DP-2How does your team break down work before starting development?

Consider whether developers start coding from a vague description, or whether work is decomposed into well-understood pieces.

DP-3How does your team track progress during a development cycle?

Think about whether the team has real-time visibility into what is done, what is blocked, and what is at risk.

DP-4How does your team handle unplanned work and production incidents during a development cycle?

Consider whether urgent requests derail planned work, or whether the team has a deliberate way to absorb interruptions.

02 Code Quality & Standards

Does the team write consistent, maintainable code with shared standards?

0/4 answered

CQ-1How does your team maintain consistent coding standards?

Think about whether a new team member would write code that looks and feels like the rest of the codebase, or whether every file has a different style.

CQ-2How does your team conduct code reviews?

Consider whether code reviews happen consistently, whether reviewers provide meaningful feedback, and whether reviews block or enable flow.

CQ-3How does your team manage technical debt?

Think about whether the team deliberately tracks and pays down technical debt, or whether it silently accumulates until something breaks.

CQ-4How does your team handle dependencies between components or services?

Consider whether changes in one part of the system routinely break other parts, or whether boundaries are well-defined.

03 Testing & Quality Assurance

How thoroughly and efficiently does the team verify that software works correctly?

0/4 answered

TQ-1What is your team's approach to automated testing?

Think about what types of automated tests exist and how much of the codebase they cover.

TQ-2How does your team handle test failures?

Consider whether a failing test stops the line, gets ignored, or gets deleted.

TQ-3How does your team test for edge cases and failure scenarios?

Think about whether testing only covers the happy path, or whether the team deliberately tests what happens when things go wrong.

TQ-4How does your team manage test environments?

Consider whether developers can get a working test environment quickly, or whether environment issues are a constant source of delays.

04 Build, Release & Deployment

How reliably and frequently can the team get code from commit to production?

0/4 answered

BR-1How does your team build and package software for release?

Think about whether builds are manual and error-prone, or automated and reproducible.

BR-2How frequently does your team deploy to production?

Consider the time between a developer finishing a feature and that feature being available to users.

BR-3How does your team handle failed deployments?

Think about what happens when a release causes problems — how quickly can you recover, and what does the process look like?

BR-4How does your team manage configuration across environments?

Consider whether configuration differences between environments cause surprises, or whether configuration is managed as carefully as code.

05 Security in Development

Is security treated as an integral part of the development process, not an afterthought?

0/4 answered

SD-1When does your team first consider security for a new feature?

Think about whether security is discussed during design, or only discovered as an issue during a penetration test or after a breach.

SD-2How does your team detect vulnerabilities in code and dependencies?

Consider whether the team relies on periodic manual audits, or whether vulnerabilities are caught continuously and automatically.

SD-3How does your team manage secrets and credentials?

Think about how API keys, database passwords, and tokens are stored, rotated, and accessed by applications.

SD-4How does your team respond when a security vulnerability is disclosed in a dependency?

Consider how quickly the team can identify whether they are affected and ship a fix.

06 Documentation & Knowledge Sharing

Can the team's knowledge survive the departure of any single person?

0/4 answered

DK-1How does your team document architectural decisions?

Think about whether a new team member could understand why the system is built the way it is, or whether that knowledge lives only in people's heads.

DK-2How does your team document how to set up, run, and debug the application?

Consider whether a new developer could go from zero to a running local environment in under an hour by following documentation alone.

DK-3How does your team share knowledge about the codebase and domain?

Think about whether knowledge is concentrated in one or two people, or whether the whole team can work across the system.

DK-4How does your team document and communicate API contracts or integration interfaces?

Consider whether consumers of your APIs can understand and integrate with them without asking a developer on your team.

Self-assessment report

Software Development

Answer the questions above and your report builds here: an overall score, a score and target for each area, and the three changes that matter most.

About this model

About the Software Development maturity model

Great software is not the product of brilliant individuals — it is the product of disciplined teams with strong engineering habits. This model assesses whether your team's development practices are resilient, repeatable, and continuously improving, or whether delivery depends on heroics, tribal knowledge, and luck.

The model deliberately avoids measuring tool adoption or methodology labels. A team using Scrum poorly will score lower than a team using Kanban well. What matters is observable behaviour: Can you ship with confidence? Can you onboard someone new without losing a week? Can you deploy on a Friday without fear?

This assessment covers six areas that together represent the full lifecycle of software delivery — from deciding what to build, through writing and verifying code, to releasing it safely and ensuring the knowledge survives beyond any individual. It is designed for teams building and operating software products or services, regardless of technology stack, team size, or delivery methodology.

The model uses three maturity levels that reflect how engineering teams actually evolve: from reactive firefighting, through disciplined process, to engineering-led optimisation. Each level builds on the previous one — you cannot meaningfully operate at Level 3 if Level 2 behaviours are not yet consistent.

Who this assessment is for

  • Software engineering teams assessing their own practices
  • Engineering managers and tech leads benchmarking team capabilities
  • CTOs and VPs of Engineering evaluating organisational development maturity
  • Teams preparing for growth who need to identify which practices will break at scale
  • Organisations transitioning from project-based to product-based delivery

The three maturity levels

  • Level 1 — Firefighting: Development is reactive and inconsistent. Work arrives through ad-hoc channels, quality depends on who happens to be working on it, and releases are high-stress events. Knowledge lives in people's heads, technical debt accumulates silently, and the team spends significant time on rework and incident response. The team can deliver, but success is not repeatable.
  • Level 2 — Disciplined: Development follows repeatable, agreed-upon processes. The team plans work deliberately, enforces coding standards automatically, writes tests, and deploys through a defined pipeline. Knowledge is documented, security is considered during design, and technical debt is tracked. Delivery is predictable and the team can absorb new members without significant disruption.
  • Level 3 — Engineering-Led: Development is driven by measurable engineering principles and continuous improvement. The team treats its delivery pipeline, test infrastructure, and developer experience as products worth investing in. Decisions are informed by data (cycle time, defect rates, deployment frequency), practices are regularly reviewed and evolved, and the team can deploy any change to production independently, safely, and at any time.

The 6 areas assessed

1. Development Process & Planning

How the team plans, prioritises, and tracks software delivery work. This area examines whether work flows through a deliberate, transparent process or arrives chaotically with no shared visibility. It covers backlog management, work decomposition, progress tracking, and the team's ability to absorb unplanned work without derailing commitments.

2. Code Quality & Standards

Whether the team writes consistent, maintainable code with shared standards that are enforced automatically rather than relying on individual discipline. This area covers coding conventions, code review practices, technical debt management, and how well the team manages dependencies between components and services.

3. Testing & Quality Assurance

How thoroughly and efficiently the team verifies that software works correctly before it reaches users. This area assesses the team's automated test strategy, how test failures are handled, whether edge cases and failure scenarios are deliberately tested, and whether test environments are reliable and available on-demand.

4. Build, Release & Deployment

How reliably and frequently the team can get code from a developer's commit to running in production. This area covers build automation, deployment frequency, rollback capability, and configuration management — the mechanics that determine whether releasing software is a non-event or an all-hands emergency.

5. Security in Development

Whether security is treated as an integral part of the development process rather than a gate at the end or an afterthought. This area examines when threat modelling occurs, how vulnerabilities are detected and remediated, how secrets are managed, and how quickly the team can respond to disclosed dependency vulnerabilities.

6. Documentation & Knowledge Sharing

Whether the team's collective knowledge can survive the departure of any single person. This area covers architectural decision records, developer setup documentation, knowledge distribution across the team, and API/integration documentation — the practices that determine whether onboarding takes hours or weeks, and whether critical context is preserved or lost.

How this model relates to other frameworks

  • DORA (DevOps Research and Assessment) metrics and annual State of DevOps reports — deployment frequency, lead time, change failure rate, failed deployment recovery time
  • Spotify engineering culture (squads, tribes and guilds), widely discussed though not intended as a model to copy
  • Accelerate (Forsgren, Humble, Kim) — research-backed software delivery performance metrics
  • The Joel Test — a practical checklist for software team quality
  • Team Topologies (Skelton, Pais) — team design patterns for fast flow
  • ISO/IEC 25010 — software product quality model

Frequently asked questions

What is the Software Development maturity model?

Assess software development practices across planning, coding, testing, and release. It is an original, simplified model with three maturity levels (Firefighting, Disciplined and Engineering-Led), assessed through 24 questions across 6 areas: Development Process & Planning, Code Quality & Standards, Testing & Quality Assurance, Build, Release & Deployment, Security in Development and Documentation & Knowledge Sharing.

How long does the Software Development assessment take?

Most people finish in 10–14 minutes. Each of the 24 questions has three concrete answer options. Your progress is saved in the page URL, so you can bookmark it and come back later.

How is the score calculated?

Each answer scores 1 (Firefighting), 2 (Disciplined) or 3 (Engineering-Led). An area's score is the average of its answered questions, and the overall score is the average of the area scores, so every area counts equally. Scores run from 1.0 to 3.0.

Is my data stored or shared?

No. Your answers are never sent to a server. They are stored only in the page URL, which you control. Copy the link to share results with colleagues, or export a PDF or CSV report.

How should I use the results?

Start with "Where to focus" in your report. It lists the questions with the biggest gap to the target you set for each area, and shows what the next level looks like in practice. For a fuller picture, ask several people from different teams to complete the assessment and compare their links. Differences in perception are often as revealing as the scores themselves.