i

Description

Convoyeurs à rouleaux et à bande d'une usine, en courbes bleues enchaînées.

Source

falco (Pixabay) · original page

Licence

CC0 Public domain

Original photo, unretouched. The background is a version of it stylised by the site.

Agile and Lean Methods (Manifesto, Kanban, XP, Lean, Shape Up, DSDM, SAFe, DevOps…)

You will understand what the Agile Manifesto really says (and what people make it say) and place each family: flow (Kanban), engineering (XP), lean, product discovery (Lean startup), appetite-based cycles…

In brief

• You will understand what the Agile Manifesto really says (and what people make it say) and place each family: flow (Kanban), engineering (XP), lean, product discovery (Lean startup), appetite-based cycles (Shape Up), enterprise frameworks (SAFe, LeSS, Nexus, Scrum@Scale), delivery culture (DevOps).
• You will understand the mechanism of each one: why limiting work in progress speeds things up, why XP makes change inexpensive, why Shape Up removes the backlog.
• You will understand what carries over to data and what breaks (source quality, historization, acceptance testing on numbers).
• You will get an honest reference point on the Spotify model: a snapshot, not a model to copy.
• You can then make trade-offs with the comparison and Choosing Your Method and Hybridizing.

On this page

1. 1. The Agile Manifesto and its principles
2. 2. Kanban and flow management
3. 3. Extreme Programming (XP)
4. 4. Scrumban
5. 5. Lean, Toyota, and the hunt for waste
6. 6. Lean startup
7. 7. Shape Up
8. 8. DSDM
9. 9. Crystal
10. 10. FDD (Feature-Driven Development)
11. 11. SAFe
12. 12. LeSS
13. 13. Nexus
14. 14. Scrum@Scale
15. 15. The “Spotify model” and its limits
16. 16. DevOps as a Culture
17. 17. Summary Table
18. 18. AI Contribution
19. 19. See also

Level: 🟢→🔴

1. The Agile Manifesto and its principles#

🟢 Novice — In February 2001, seventeen practitioners gathered in Snowbird (Utah) signed the Manifesto for Agile Software Development. It fits into four values, framed as preferences (“while there is value in the items on the right, we value the items on the left more”):

It is accompanied by 12 principles. The ones with the biggest practical consequences:

• satisfy the customer through early and continuous delivery of valuable software;
• welcome change, even late;
• deliver frequently (from a couple of weeks to a couple of months, preferably the shorter timescale);
• daily collaboration between business and developers;
• build around motivated people, trust them;
• face-to-face conversation is the most effective form of communication;
• working software is the primary measure of progress;
• sustainable pace; technical excellence and good design enhance agility;
• simplicity: the art of maximizing the amount of work not done;
• self-organizing teams; regular retrospective to adjust.

🟡 In practice — What the Manifesto is not: a rejection of documentation, planning, or contracts (the text says “more,” not “exclusively”), nor a method. It is a set of values from which methods were built. The most common reading pitfall is reducing “agile” to a calendar of ceremonies: stand-ups without product improvement are agile theater.

🔴 Expert — The agile family can be read along three axes that explain disagreements between methods:

Agility failures almost always come from a neglected axis: Scrum without engineering (XP) accumulates debt; a team excellent in engineering without product focus quickly delivers the wrong thing; an organization that scales the framework without solving dependencies adds layers. This reading structures what follows.

🟡 Data section — The Manifesto talks about “software,” but the principle holds for data: an increment is a reliable, consumable dataset (a loaded fact table, a semantic model, a report validated against known numbers), not a script. See Scrum Applied to Data, BI, and the Datamart and the “data project management” matrix.

2. Kanban and flow management#

🟢 Novice — Kanban (“visual signal” in Japanese) comes from the Toyota Production System (1940s-50s). Applied to development by David J. Anderson (Kanban, 2010): you visualize work on a column-based board (To do → In progress → Verify → Done), you limit work in progress (WIP) per column, and you optimize flow. No sprints, no imposed roles: you start from the existing process and improve it through small evolutions.

🟡 In practice — The six practices of the Kanban method: visualize flow; limit WIP; manage flow; make policies explicit (definition of “done,” priority rules); implement feedback loops; improve collaboratively and evolve through experimentation.

The central mechanism is Little's Law (queueing theory theorem): in a stable system,

Limiting WIP shortens lead time without requiring people to work faster: stop starting and start finishing. Common measures: lead time (from request to delivery), cycle time (from actual start to finish), throughput, age of work in progress, cumulative flow diagram (CFD). Use percentiles (“85% of items are delivered in ≤ 9 days”) rather than averages for commitments.

Classes of service: urgent (expedite, limited to one at a time), fixed date, standard, intangible (debt, rework) — with explicit rules so urgent work does not consume everything.

Strengths: can start without disruption, very suitable for support work, operations, and unpredictable requests, visible lead-time gains, objective metrics. Weaknesses: no built-in decision cadence (risk of drift without planning), no iteration-based commitment (some leadership teams want a “sprint goal”), limited help for product discovery.

🟡 Data section — Kanban is the natural method for data operations: load anomalies, report enhancement requests, data corrections, access rights. Queues are random there, with highly variable sizes.

🧪 Example — A 4-person BI team receives 15 requests per week and handles 12: the queue grows. With total WIP capped at 8 and classes of service, 85th-percentile lead time drops from about 5 weeks to 2 weeks in two months, without hiring: most requests were sleeping “in progress” waiting for acceptance testing. (Illustrative order of magnitude, not a measurement.)

3. Extreme Programming (XP)#

🟢 Novice — XP (Kent Beck, late 1990s, the C3 project at Chrysler) is the agile method most focused on technique. Its idea: if practices that reduce risk are good, let’s push them to the extreme. Many modern technical “agile” practices (TDD, continuous integration, refactoring, small releases) come from it.

Values (2nd edition, 2004): communication, simplicity, feedback, courage, respect.

🟡 In Practice — The main practices:

The mechanism: TDD (red → green → refactor) produces a test suite that makes refactoring safe; refactoring keeps the design simple; simple design makes change inexpensive. The change cost curve flattens (see Predictive Methods (waterfall, V-model, spiral, RUP, PMBOK, PRINCE2, Merise, CMMI), §13).

Strengths: high technical quality, very short feedback loops, controlled debt. Weaknesses: requires discipline, cultural resistance to pairing, on-site customer rarely achieved, limited coverage of governance and contract issues.

🟡 Data perspective — XP practices exist, but the means differ:

• Test-first → data tests: constraint tests (key uniqueness, non-nullability), reconciliation tests (source/target totals), business rule tests on minimal, deterministic datasets; T-SQL testing frameworks (tSQLt); DAX measure tests on a reference model.
• Continuous integration → database project compilation, deployment to an ephemeral database, execution of data tests, semantic model validation (see CI/CD for data: foundations, datamarts, pipelines, and reports).
• Refactoring → controlled object renaming, view decomposition, logic extraction into a shared layer; this requires dependency mapping (who consumes this column?), otherwise a rename breaks downstream reports.
• Pairing → four-eyes review of critical SQL queries, analyst ↔ developer pairing on calculation rules.

-- Minimal data test (load idempotence): rerunning must not change the result.
EXEC dbo.p_Charger_Ventes @Jour = '2026-09-30';
SELECT SUM(Montant) AS M1, COUNT(*) AS N1 FROM dwh.FACT_Ventes WHERE DateVente = '2026-09-30';
EXEC dbo.p_Charger_Ventes @Jour = '2026-09-30';   -- rerun
SELECT SUM(Montant) AS M2, COUNT(*) AS N2 FROM dwh.FACT_Ventes WHERE DateVente = '2026-09-30';
-- Expected: M1 = M2 and N1 = N2 (otherwise: non-idempotent load, duplicates).

4. Scrumban#

🟡 In Practice — Scrumban (Corey Ladas, 2008) is a Scrum-Kanban hybrid: you keep Scrum’s cadence (review, retrospective, regular replanning, lighter roles) and import from Kanban the continuous flow, WIP limit, and pull replenishment (you replan when the ready-work stock falls below a threshold, rather than on a fixed date).

Typical uses:

• Transition: a waterfall or support team moves to iterative delivery without a major overhaul;
• Mixed project + run teams: sprinting handles emergencies poorly, continuous flow absorbs them;
• Heavily maintenance-oriented teams, where sprint commitment makes little sense.

Strengths: flexible, scalable, strong flow throughput. Weaknesses: ambiguity — everyone calls something different “Scrumban,” and the lack of clear rules can drift toward “Scrum without commitments.”

🟡 Data perspective — This is the most common hybrid for BI teams that handle both project work and support: reserved capacity (for example 30%) for incident flow, the rest in iterations. See Choosing Your Method and Hybridizing.

5. Lean, Toyota, and the hunt for waste#

🟢 Novice — Lean is a management philosophy from the Toyota Production System (Taiichi Ohno, Eiji Toyoda, postwar). Principle: create customer value by eliminating waste (muda). The seven classic production wastes:

An eighth waste is often added: unused talent.

🟡 In Practice — Mary and Tom Poppendieck (Lean Software Development, 2003) adapted Lean to software with seven principles: eliminate waste; amplify learning; decide as late as possible (at the last responsible moment); deliver as fast as possible; empower the team; build quality in; optimize the whole (systems view).

Useful tools:

• Value Stream Mapping: map the flow from request to delivery, distinguishing work time and waiting time. Typical result: flow efficiency (value-added time / total lead time) is low — on the order of a few tens of percent in a queued process, often much less; most lead time is waiting.
• Pull rather than push: pull work when capacity is available (Kanban).
• Just-in-time: decide/specify as close as possible to implementation.
• Jidoka (“autonomation”: stop the line at the first defect) → in data, a load that fails rather than loading non-compliant data.
• Kaizen: continuous improvement in small steps (Scrum in Practice).

Strengths: a simple thinking framework to diagnose; compatible with any other framework. Weaknesses: it is not an operational method; the factory metaphor applies poorly to design work (intrinsic variability: software is not a repeated product). There is a risk of local optimization (maximizing each person’s utilization increases queues) — hence the rule: target flow, not utilization.

6. Lean startup#

🟢 Novice — Lean startup (Eric Ries, The Lean Startup, 2011, inherited from Steve Blank and customer development) is about discovery: when you don't even know whether the product will find a use. The Build → Measure → Learn loop aims to validate hypotheses at the lowest cost.

🟡 In practice — Concepts:

• MVP (minimum viable product): the smallest experiment that allows you to learn — not a cheap product, a test;
• value and growth hypotheses to validate; pivot (a strategy change based on learning) or perseverance;
• innovation accounting: actionable metrics (usage rate, retention) rather than vanity metrics (number of downloads);
• small batches, product development through experimentation.

Strengths: avoids building what no one uses, legitimizes stopping quickly. Weaknesses: does not provide a way to build; experimentation assumes you can measure (enough volume) and adjust; the MVP can be distorted into a “sloppy version.”

🟡 Data component — Very useful for uncertain analytical use cases (“will this score really help the sales team?”). The MVP is not a warehouse or a complete model but rather:

• a report prototype based on a real extract, put in the hands of 3 users;
• a one-off analysis on an extract, before any industrial loading;
• a value test: does the indicator change a decision? measure usage (Power BI service view logs) rather than declared satisfaction.

7. Shape Up#

🟡 In practice — Shape Up (Ryan Singer, Basecamp, 2019) is a method of long cycles with fixed appetite, designed to avoid Scrum pitfalls at product scale. Principles:

• 6-week cycles followed by a 2-week cooldown period (cooldown) (fixes, exploration, debt);
• appetite (appetite) comes before estimation: “this is worth 6 weeks (or 2) of our time”; scope adapts to appetite, not the other way around (fixed timeline, variable scope);
• shaping (shaping): seniors define the problem, the broad outlines of the solution, boundaries (no-gos) and risks, without getting into execution detail; the result is a few-page pitch;
• betting (betting table): a small committee chooses which pitches to launch for the cycle; no persistent backlog (what is not selected disappears, and will come back if it is important);
• autonomous teams (one designer + one to two developers) that own the project end to end;
• tracking with hill charts (uphill = “unknowns to solve,” downhill = “execution”) rather than percentages;
• a circuit breaker (circuit breaker): if the project is not finished at the end of the cycle, it is not automatically extended.

Strengths: end of the catch-all backlog, reduced drift risk, accountability, calm. Weaknesses: requires seniors able to shape; requires a product context (one product, one sponsor); poorly suited to contract obligations, mass maintenance, external dependencies.

🟡 Data component — Suited to data product teams (internal platform, data product) that have room to maneuver. A data “pitch” includes: the decision to support, the grain, the sources and their quality risks, the desired history tracking, and the no-gos (“no real-time,” “no redesign of the reference model”). The hill chart works well for the task of connecting a source: uphill is source exploration (never fully known), downhill is industrial loading.

8. DSDM#

🟡 In practice — DSDM (Dynamic Systems Development Method) was created in 1994 in the UK by a consortium of companies to bring discipline to rapid application development (RAD). Today maintained by the Agile Business Consortium under the name Agile Project Framework (AgilePF). Distinctive features:

• Fixed time and cost, variable features: scope is negotiated through MoSCoW prioritization (Must, Should, Could, Won't have) — at most 60% of effort in Must to keep a safety margin;
• timeboxing; user involvement; frequent delivery; continuous testing;
• a more formal governance framework than Scrum: phases (pre-project, feasibility, foundations, solution evolution, deployment), defined roles (sponsor, visionary, user ambassador…);
• principles including “focus on business need,” “deliver on time,” “build incrementally from firm foundations.”

DSDM is agile for organizations that want structure: it works well with PRINCE2 (the “manage by stages” mindset) and with “fixed time and cost” contracts.

Strengths: explicit governance, MoSCoW reusable everywhere, bridges agile/classic project management. Weaknesses: its own vocabulary, modest adoption in France/in small teams, somewhat heavy documentation.

🟡 Data component — MoSCoW works well for prioritizing a batch of reports/measures; the “fixed time and cost” rule is reassuring for a sponsor paying fixed price: you guarantee the date and the essential baseline (Must), and sacrifice Could.

9. Crystal#

🟡 In practice — Crystal is a family of methods by Alistair Cockburn (1990s). Core idea: there is no single method; the method depends on team size and project criticality. The “colors” (Clear, Yellow, Orange, Red…) scale up with number of people; the best-known variant is Crystal Clear (~2 to 8 co-located teams). Properties: frequent delivery, osmotic communication (hearing without interrupting), improvement through reflection, personal safety, focus, easy access to expert users, technical environment with automated tests, continuous integration, and frequent delivery.

Strengths: emphasizes the human factor and adapting the method to context. Weaknesses: few tools, little adoption as a named framework; its contribution is mostly conceptual.

🟡 Data component — The key lesson is “the method follows criticality”: an exploratory dashboard does not require the same rigor as a regulatory statement. See the selection grid.

10. FDD (Feature-Driven Development)#

🟡 In practice — FDD (Jeff De Luca and Peter Coad, 1997, banking project in Singapore) is a feature-driven and modeling-oriented method. Five activities:

1. develop an overall model (collaborative modeling);
2. build the feature list (features), phrased as “action + result + object” (e.g., calculate the total of a planogram statement);
3. plan by feature;
4. design by feature;
5. build by feature (short cycles, 1 to 2 weeks max per feature).

Distinctive features: class ownership (a developer responsible for classes), “chief programmers” (chief programmers), progress reports by feature tree (percentage complete by weighted milestone), code inspections. Suited to large teams and systems with strong business logic, with an explicit initial modeling phase.

Strengths: clear progress visibility, clear modeling, scales well to medium size. Weaknesses: more directive and more “designer-led” than other agile methods; little community momentum today.

🟡 Data component — Surprisingly close to data needs: the feature list maps to a list of measures and views (“calculate a chain’s net revenue over a period”) and the initial overall model is the equivalent of the logical dimensional model (grain, conformed dimensions). Progress by completed feature is more honest than a percentage of loaded tables.

11. SAFe#

🟢 Novice — SAFe (Scaled Agile Framework, Dean Leffingwell, 2011; 6.0 edition published in March 2023; check the current edition on the Scaled Agile website) is the most widely deployed agile scaling framework in large organizations. It coordinates dozens of teams around Agile Release Trains (Agile Release Train, ART: 50–125 people who plan and deliver together).

🟡 Practical — Structuring elements:

• PI Planning: a 2-day event every 8 to 12 weeks (Program Increment) where all train teams plan together, identify dependencies and risks, and make commitments;
• layers: team → program (ART) → large portfolio (Large Solution) → portfolio (value stream management, lean budgets);
• roles: Release Train Engineer, Product Management, System Architect, etc.; operational and development value streams;
• core competencies (Core Competencies): team and technical agility, DevOps, organizational agility, etc.;
• Inspect & Adapt at the end of the PI.

Strengths: a structured response to the dependency coordination problem, shared vocabulary, abundant training and certification, alignment with corporate financial governance. Weaknesses: heaviness, risk of waterfall by ceremony (PI Planning as a disguised annual plan), recurring criticism of “reintroducing traditional management”; the method requires major organizational changes that are often overlooked by keeping only the events.

🟡 Data perspective — Relevant for large organizations with a shared data platform and several product teams dependent on the platform (ingestion, reference models, security). Out of proportion for a 4–10 person datamart. Typical dependencies to synchronize: data contracts between sources and consumers, reference model, load windows.

12. LeSS#

🟡 Practical — LeSS (Large-Scale Scrum, Craig Larman and Bas Vodde, 2000s) takes the opposite path from SAFe: instead of adding layers, remove structure. Principle: “LeSS is Scrum at scale — one product, one Product Backlog, one Product Owner, several teams running the same sprint, one definition of done, one potentially shippable delivery.” Two versions: LeSS (2 to 8 teams) and LeSS Huge (beyond that, with requirement areas and Area Product Owners). It emphasizes organizational simplification (fewer roles, fewer middle managers, feature teams rather than component teams) and systems thinking (descaling).

Strengths: consistent with agile principles, few added roles. Weaknesses: requires a deep organizational transformation (structure, management), with few tool-supported “deliverables”; lower adoption than SAFe among leaders who want an off-the-shelf framework.

🟡 Data perspective — The discipline of “one feature team, full end-to-end flow” fits data product teams (source → model → report) better than siloed “ETL / modeling / BI” teams. It's a strong argument for vertical teams.

13. Nexus#

🟡 Practical — Nexus (Ken Schwaber and Scrum.org, 2015) is a lightweight framework for having 3 to 9 Scrum teams work together on a single product. It adds to Scrum:

• a Nexus Integration Team (NIT) — Product Owner, Nexus Scrum Master, integration members — that handles dependencies and ensures the integrated increment;
• a single Nexus Backlog; Nexus Sprint Planning, Nexus Sprint Review, Nexus Retrospective;
• a Nexus Sprint Goal and a shared definition of done;
• an integrated increment every sprint.

Strengths: minimal, faithful to Scrum, well suited to teams already mature in Scrum. Weaknesses: few answers on organization and governance, depends on the Product Owner and NIT to resolve dependencies.

🟡 Data perspective — Useful when multiple Scrum teams contribute to the same data warehouse and risk stepping on each other (same schema, same dimension tables). The integration team plays the role of guardian of the reference model and single deployment.

14. Scrum@Scale#

🟡 Practical — Scrum@Scale (Jeff Sutherland, Scrum Inc., 2014-2018) extends Scrum through a fractal model: a “Scrum of Scrums” coordinates multiple teams; a “Scrum of Scrums of Scrums” coordinates multiple such groups, etc. Two independent axes:

• the Scrum Master axis (“doing things right” — impediments, organizational performance): Scrum of Scrums coordinated by a Scrum of Scrums Master;
• the Product Owner axis (“doing the right things” — strategic alignment): a MetaScrum of Product Owners who align on priorities, chaired by a Chief Product Owner.

Strengths: modular (you adopt useful components), conceptual simplicity. Weaknesses: less prescriptive, therefore more dependent on judgment; little public feedback compared with SAFe.

🟡 Data perspective — A Scrum of Scrums of team leads (ingestion, model, reporting, security) is the lightest and most realistic form of coordination for a data production pipeline of 15–30 people.

15. The “Spotify model” and its limits#

🟢 Novice — In 2012, Henrik Kniberg and Anders Ivarsson published Scaling Agile @ Spotify, describing the organization at the time: squads (small autonomous teams, comparable to a Scrum team), grouped into tribes, connected across functions by chapters (professional communities within a tribe) and guilds (communities of interest at company scale).

🟡 Practical — What you need to know to avoid getting it wrong:

• Kniberg himself presented it as a snapshot of the organization at a given moment (not a “model” or a framework), and reminded readers that the company kept changing;
• testimonies from former employees indicate that the real organization did not match the document's ideal (dependencies, coordination pain) — confirmed by Spotify's constant organizational revision;
• the enduring value of the text is to illustrate alignment with autonomy: “aligned, then autonomous” (aligned autonomy), end-to-end teams responsible for a mission, and communities for sharing practices.

Limits when copying it:

🟡 Data perspective — The transferable part is the end-to-end product team (source through report) and the community of practice (guild of modelers, DAX developers) that spreads standards — exactly what self-service governance is trying to achieve.

16. DevOps as a Culture#

🟢 Novice — DevOps (a term popularized around 2009 by Patrick Debois and the DevOpsDays conferences) aims to tear down the wall between those who develop and those who operate. It is neither a project management method nor a job role: it is a culture and a set of practices that enable teams to deliver fast AND reliably.

🟡 In practice — The CALMS summary: Culture (collaboration, shared responsibility), Automation (build, test, deployment), Lean (flow, small batches), Measurement (metrics, observability), Sharing (knowledge sharing).

The DORA team’s research (DevOps Research and Assessment, the book Accelerate by Forsgren, Humble, and Kim, 2018, then the annual State of DevOps reports) identified delivery performance measures that correlate with organizational outcomes. The four key metrics:

The standout result from DORA research is that speed and stability are not opposites for high-performing teams; more recent DORA work refined how some metrics are phrased: lead time for changes became change lead time, time to restore became time to restore after a failed deployment (failed deployment recovery time), and a fifth metric, the rate of unplanned deployment rework after incidents (deployment rework rate), complements change failure rate. DORA’s online guide now groups these metrics into two families: throughput (throughput) and instability (instability).

Foundational technical practices: continuous integration, continuous delivery, infrastructure as code, monitoring and alerting, progressive deployments (canary, blue/green), “you build it, you run it”. Details in CI/CD.

🟡 Data component — DataOps applies the same mindset to data: tested and versioned data pipelines, reproducible environments, data observability (freshness, volume, schema, distribution), replayability. Complicating specifics: state (a database is migrated; a deployment does not “replace” a table with its data), the size of test environments, production data (confidentiality), and historical replay. See CI/CD for data: foundations, datamarts, pipelines, and reports and the matrix domain Lead Time and Industrialization (DataOps).

🧪 Example (common thread) — Datamart delivered in versioned installation kits: moving from 1 kit every 3 months to 1 kit every 3 weeks requires (1) a test database rebuilt from the kit for every change, (2) an automatic regression test suite, (3) a generated delivery report. Every manual step removed improves both frequency AND reliability.

17. Summary Table#

Ratings /5 — context: team of 4 to 12 people, software or data project lasting 6 to 18 months, mid-sized organization; expert assessments (see Rating: Reading Ratings, Scores, and the Legend). The table with predictive methods and Scrum is in the Comparison of Project Management Methods.

Critical reading: Kanban’s ease of adoption (5/5) is why teams often start with it; the low 2/5 for XP and DevOps reflects the cultural and tooling cost, not a flaw in the method. No approach “wins” everywhere: these ratings only make sense with context.

18. AI Contribution#

🤖 AI — AI mainly impacts engineering (XP/DevOps) and flow (lead time analysis).

Example prompt: “Here is the exported flow table (ID, creation date, start, end, type). Calculate lead time and cycle time at the 50th, 85th, and 95th percentiles by class of service, and flag items whose age exceeds the 85th percentile.”

AI does not replace team autonomy, trust, access to business stakeholders, or the decision to stop a project. A new risk: the flow of code produced without understanding increases hidden technical debt; XP discipline (tests, review, simplicity) becomes more necessary, not less. See AI for Project Management (General Then Data).

19. See also#

• Predictive Methods (waterfall, V-model, spiral, RUP, PMBOK, PRINCE2, Merise, CMMI) · Comparison of Project Management Methods · Choosing Your Method and Hybridizing · Methods Specific to Data Projects.
• Scrum, the framework (Scrum Guide 2020) · Scrum in Practice · Scrum Applied to Data, BI, and the Datamart · Project Management Fundamentals · Pitfalls and good practices in project management (cross-functional summary).
• CI/CD: Continuous Integration and Continuous Delivery · CI/CD for data: foundations, datamarts, pipelines, and reports.
• Tools: Azure DevOps Server (ex-TFS) in Depth · Jira In Depth and Alternatives · Project Metrics and Reporting.
• Maturity: Team and Collaboration (EQU) · Continuous Improvement and Learning (AMC) · Continuous Integration and Continuous Delivery · Developer Experience and Flow.
• Glossary.

✻ Written by Claude Sonnet 5.5