PMI DAF cheat sheet

DA is a hybrid toolkit: it curates practices from Scrum, Kanban, XP, SAFe, LeSS, Agile Modeling, and traditional/waterfall sources, then guides teams to choose and tailor a fit-for-purpose way of working (WoW).

Four layers of scope: Disciplined Agile Delivery (DAD, team level), Disciplined DevOps (delivery plus operations/security/support), Disciplined Agile IT (DAIT, enterprise IT), and Disciplined Agile Enterprise (DAE, whole-organization business agility).

Three guiding principles: (1) Delight customers, (2) Be awesome, (3) Pragmatism beats purity. Pragmatism means choosing the practice that works in context rather than the ideologically 'pure' one.

DA mindset: principles over prescriptive process, choice over standardization, and a light touch over heavyweight governance; the toolkit supplies options, the team supplies the decision.

Seven phases of the DAD lifecycle: Inception, Construction, Transition, Production, Retirement (delivery), plus Ideation (pre-project) and ongoing Operations/Support.

DAD is risk-value driven and delivery-oriented: it explicitly includes Inception (vision, initial scope, initial architecture, funding) and Transition (deployment readiness, stakeholder acceptance) that Scrum leaves implicit.

DA roles are organized into four categories: primary (Team Lead, Product Owner, Team Member, Architecture Owner), supporting (Specialist, Domain Expert, Technical Expert, Independent Tester, Integrator), cross-team (Release Coordinator, Enterprise Architect, etc.), and governance (Portfolio Manager, IT Governance, Executive).

DA is not a method to be adopted wholesale; it is a knowledge base of strategies with explicit trade-offs, intended to be consumed via guided continuous improvement (GCI) and explicit choice.

Four DA life cycles: Agile (continuous delivery of consumable solutions), Lean (continuous flow with a kanban system), Continuous Delivery: Agile (agile plus automated deployment pipeline), and Exploratory (lean startup style, for high-uncertainty R&D).

Life cycle selection rule: choose Agile or Lean when the solution is well understood; choose Continuous Delivery variants when deployment automation is a priority; choose Exploratory when the problem/solution is genuinely novel and funding should be released in small increments.

Two levels of process tailoring: the delivery team tailors its WoW; the organization provides guardrails via Communities of Practice (CoPs), not mandates. CoPs are where practitioners share and evolve guidance.

Goal diagrams are the core DA tool: each of the ~20 goal diagrams states a goal (e.g., 'Produce a potentially consumable solution') and lists decision points with options and their trade-offs.

Goal categories in DA: team-level goals (e.g., Initiate a project, Form the team, Explore initial scope, Identify initial technical strategy, Plan the work, Coordinate activities, Develop the solution, Demonstrate value, Ensure quality, Deploy the solution, Leverage and evolve the infrastructure, Address risk, Govern the team) and enterprise-level goals (e.g., Coordinate teams, Evolve WoW, Align around the organization's business strategy, Provide enterprise guidance, Govern the portfolio).

Choice is explicit: each goal diagram option lists advantages, disadvantages, and 'when to use it' context, so decisions are made with eyes open rather than by default.

Guided continuous improvement (GCI) is the improvement loop: identify the problem, evaluate options on the relevant goal diagram, make an explicit choice, then measure and adjust. It is retrospective-driven and incremental, not a one-time transformation.

DA scaling factors (the 'context' in fit-for-purpose) include team size, geographic distribution, domain complexity, technical complexity, organizational distribution, compliance requirements, enterprise discipline, and solution type.

Hybrid: DAD combines Scrum's cadence and product ownership, XP's engineering practices (TDD, refactoring, pair programming, continuous integration), Kanban's flow and WIP limits, and Agile Modeling's lightweight modeling.

The DA 'pragmatic' test for a practice: does it improve outcomes for this team in this context? If a practice adds ceremony without value, DA explicitly permits dropping or replacing it.

Ceremony minimums: DA describes a 'sufficient' set of ceremonies rather than a fixed set; common ones are daily coordination, iteration/sprint planning, demonstration, retrospective, and inception/visioning.

Consumable solution over potentially shippable increment: DAD requires the team to produce something stakeholders can actually use (deployed or deployable) by the end of each iteration, not merely code that compiles.

Roles are not one-to-one with Scrum: DAD adds Team Lead (servant-leader/coach), Architecture Owner (architecture decisions and technical risk), and Independent Tester/Integrator for larger or regulated contexts.

Inception is time-boxed and risk-driven: its depth depends on project risk; a low-risk, well-understood effort may need only days of inception, while high-risk efforts need more.

DA distinguishes 'process' (the WoW the team follows) from 'process framework' (the toolkit of options); the framework is stable, the process is tailored per team.

DA's enterprise view: IT is a service provider to the organization; business agility requires aligning portfolio funding, governance, and operations with the delivery teams, not just fixing the teams.

Definition of 'disciplined': lean and agile values plus a conscious, explicit choice of practices, with a rationale, rather than either heavyweight bureaucracy or undisciplined improvisation.

DA's three 'pragmatic' guiding principles are sometimes stated as: delight customers, be awesome, pragmatism beats purity - and the DA mindset adds 'choice is good' and 'context counts'.

Architecture in DAD is emergent but not absent: enough initial architecture to reduce risk (Architecture Owner role), then evolve it through refactoring and spikes.

DA explicitly supports both cadence-based (iterations) and flow-based (kanban) planning, and permits hybrid WoWs such as iterations inside a kanban system.

Governance in DA is lightweight and evidence-based: decisions are made from demonstrated working solutions, metrics, and explicit risk assessment rather than document sign-off alone.

DA's 'process blade' concept (in DAIT/DAE) organizes guidance by functional area (e.g., continuous integration, release management, data management, security, portfolio management) so teams can pull relevant guidance.

The DA toolkit is organized to be navigated by goal, not by phase or role: a team facing a decision finds the goal diagram for that decision and evaluates options.

Metrics in DA favor outcome and flow measures (cycle time, lead time, escaped defects, value delivered) over output measures (velocity, lines of code) for governance decisions.

DA vs Scrum: DAD covers the full delivery life cycle (inception through production/retirement), includes explicit architecture and operations roles, and is explicitly a tailoring toolkit rather than a single prescribed framework.

DA vs SAFe: DA is a toolkit of options with goal diagrams for choosing among them; SAFe prescribes a specific scaled structure (ARTs, PI Planning, roles). DA scales via context-driven choice, not a fixed org chart.

DA vs traditional/waterfall: DA retains the useful disciplines of waterfall (inception planning, architecture, transition/deployment readiness, governance) but executes them iteratively and incrementally.

When to use the Exploratory life cycle: high uncertainty about market or technology, lean-startup style experiments, and funding released in small increments based on learning.

When to use Lean life cycle: work arrives continuously, a kanban/flow system with WIP limits suits the work, and the team wants to minimize batch size and optimize cycle time.

When to use Continuous Delivery: Agile/Lean: high priority on automated testing and deployment pipelines, frequent low-risk releases, and DevOps integration.

Common DA failure mode: treating DA as 'pick anything you like' without explicit choice, measurement, or GCI - the toolkit requires disciplined decision-making, not abandonment of discipline.

Common DA failure mode: adopting every option at once (over-engineering the WoW); DA favors the simplest WoW that addresses the team's actual context and risks.

Team Lead: servant-leader and coach; removes impediments, facilitates ceremonies, and shields the team; comparable to Scrum Master but with broader coaching/leadership scope in DAD.

Product Owner: owns the product vision, prioritizes the backlog, and represents stakeholder/customer value; in DAD the PO may be supported by a Product Manager in larger contexts.

Architecture Owner: accountable for architecture decisions and technical direction; ensures the team addresses technical risk and non-functional requirements; often a senior developer/architect role.

Team Member: cross-functional contributor who does the work; DAD assumes generalizing specialists (deep in one area, able to work across boundaries) rather than narrow specialists.

Supporting roles (Specialist, Domain Expert, Technical Expert, Independent Tester, Integrator) are brought in as needed and are not permanent core roles.

Cross-team roles (Release Coordinator, Enterprise Architect, Enterprise Business Architect, Portfolio Manager, Reuse Engineer) coordinate across delivery teams in scaled contexts.

Governance roles (IT Governance, Portfolio Manager, Executive/Sponsor) provide funding, oversight, and organizational alignment; DA expects them to use lightweight, evidence-based governance.

Roles in DA are a starting point to be tailored: small co-located teams may combine roles (e.g., Team Lead also Architecture Owner); large or regulated teams may split and add roles.

Inception goal: establish a shared vision, initial scope, initial architecture/technical strategy, initial plan, and funding - to the depth justified by risk, not to exhaustive detail.

Construction goal: produce a potentially consumable solution incrementally through iterations or flow, with continuous testing and integration.

Transition goal: deploy the solution into production/stakeholder hands, including deployment planning, stakeholder acceptance, and readiness activities.

Production goal: operate and support the solution in production, monitoring, fixing, and evolving it.

Retirement goal: decommission the solution in an orderly way, migrating data/users and removing infrastructure.

Ideation (pre-inception): identify and evaluate potential initiatives, estimate value and risk, and decide whether to fund an inception - the entry point for new work in the portfolio.

Operations/Support is ongoing and parallel to delivery: DA treats it as a first-class concern (DevOps) rather than an afterthought, and DA DevOps extends delivery into operations, security, and support.

Phase overlap is expected: inception activities may continue into early construction, and transition planning often starts during construction; the phases are a mental model, not a rigid gate sequence.

Goal diagram structure: goal statement at top, decision points as branches, and options under each decision point with trade-off notes (advantages, disadvantages, when to use).

Example goal 'Ensure quality': decision points include 'What quality strategy?', 'How do we test?', 'How do we address non-functional requirements?', 'How do we measure quality?', with options such as test-first, test-after, exploratory testing, and automated regression suites.

Example goal 'Form the team': decision points include team size, team structure, and how to staff roles; options range from a small co-located generalist team to larger distributed specialist teams.

Example goal 'Address risk': decision points include identifying risks, assessing risks, and mitigating risks; options include risk burndown, spikes, and explicit risk registers for regulated contexts.

Example goal 'Plan the work': decision points include how to plan (iteration vs flow), how much to plan up front, and how to schedule; options include release planning, iteration planning, and continuous planning.

Goal diagrams are decision aids, not checklists: a team selects the options that fit its context and records the rationale, then revisits via GCI.

Goal diagrams cover both team and enterprise concerns; enterprise goal diagrams (e.g., 'Govern the portfolio', 'Evolve WoW') are used by CoPs, PMOs, and leadership rather than delivery teams alone.

Because options carry explicit trade-offs, DA supports evidence-based tailoring: a team can justify a non-standard choice (e.g., test-after for a spike) with the documented trade-off.

Scaling factors to assess before choosing a WoW: team size, geographic distribution, domain complexity, technical complexity, organizational distribution (outsourcing/partners), regulatory/compliance requirements, enterprise discipline, and solution type (e.g., COTS vs custom).

As compliance/regulatory requirements rise, DA adds explicit evidence and documentation practices (e.g., traceability, formal reviews) rather than abandoning agility; the goal diagrams show options for regulated contexts.

As technical complexity rises, DA increases emphasis on initial architecture, spikes, and Architecture Owner involvement; as domain complexity rises, it increases emphasis on domain experts and modeling.

As team size and distribution rise, DA increases emphasis on cross-team coordination roles (Release Coordinator, Integrator), CoPs, and explicit coordination ceremonies.

Disciplined DevOps: integrates development with operations, security, and support; includes continuous integration, continuous deployment, and operational monitoring as first-class goals.

DAIT (Disciplined Agile IT): applies DA across the IT organization, covering process blades such as portfolio management, enterprise architecture, data management, and IT governance.

DAE (Disciplined Agile Enterprise): applies DA to the whole business, aiming at business agility - the ability of the organization to sense and respond to change - not just IT agility.

CoPs (Communities of Practice) are the mechanism for evolving WoW at scale: practitioners across teams share practices, and guidance flows back into the toolkit and guardrails.

DA is a 'process framework' or 'toolkit', not a methodology: it provides a curated set of strategies and the decision aids (goal diagrams) to choose among them; the team's resulting process is the WoW.

The DA mindset values: principles over prescriptive process, choice over standardization, and pragmatism over purity; the toolkit is meant to be tailored, not adopted verbatim.

DAD (team level) covers the full delivery life cycle from inception through retirement, unlike frameworks that begin at construction and end at a shippable increment.

DA explicitly adds Inception and Transition to the Scrum-style construction loop, and adds Ideation and Operations/Support as surrounding phases.

Guided continuous improvement (GCI) is the improvement engine: retrospectives plus goal diagrams plus explicit choice plus measurement; it is how a team evolves its WoW over time.

DA's stance on documentation: produce the documentation that adds value (e.g., regulatory evidence, architecture decisions), and avoid documentation for its own sake; Agile Modeling's 'document late, document lightly' applies.

DA's stance on metrics: prefer outcome, flow, and value metrics for governance; use output metrics cautiously and never as the sole basis for funding or performance decisions.

DA is context-driven: the same toolkit yields different WoWs for a 5-person co-located startup team and a 200-person regulated enterprise team, and both can be 'disciplined'.

Exam-style distinction: 'What is DA?' - a hybrid, context-driven toolkit of practices with goal diagrams for explicit choice, covering the full delivery life cycle and scaling to the enterprise.

Exam-style distinction: 'What is DAD?' - the team-level layer of DA covering inception, construction, transition, production, and retirement, with roles including Team Lead, Product Owner, Architecture Owner, and Team Member.

Exam-style distinction: 'What is a WoW?' - the tailored way of working a specific team follows, chosen from the toolkit's options based on its context and recorded rationale.

Exam-style distinction: 'What is GCI?' - guided continuous improvement, the retrospective-driven loop of identifying a problem, evaluating options, making an explicit choice, and measuring the result.

Exam-style distinction: 'What is a goal diagram?' - a decision aid listing a goal, its decision points, and the options with trade-offs, used to tailor the WoW.

Exam-style distinction: 'What is a CoP?' - a community of practice, a group of practitioners across teams who share and evolve guidance for a functional area, providing guardrails without mandates.

Exam-style distinction: 'What are scaling factors?' - the context variables (size, distribution, domain/technical complexity, compliance, enterprise discipline, solution type) that drive WoW choices.

Exam-style distinction: 'What are the four life cycles?' - Agile, Lean, Continuous Delivery: Agile, Continuous Delivery: Lean, and Exploratory; choice depends on uncertainty, flow needs, and deployment automation.

DA's position on 'best practices': there are no universal best practices, only practices that are fit for a given context; the toolkit documents trade-offs so teams can judge fit.

DA's position on 'ceremony': ceremonies exist to serve coordination, learning, and value delivery; if a ceremony does not serve those purposes in context, it is a candidate for change via GCI.

DA's position on 'roles': roles are defined by responsibilities, not job titles; one person may hold multiple roles, and roles may be split across people in larger contexts.

DA's position on 'architecture': architecture is a shared responsibility with an accountable Architecture Owner; it is evolved incrementally and validated with working code, not frozen up front.

DA's position on 'requirements': requirements are captured as lightweight models and backlog items, elaborated just in time, with stakeholders involved continuously rather than at sign-off gates.

DA's position on 'governance': governance should be lightweight, evidence-based, and aligned with delivery cadence; it should enable delivery rather than gate it.

DA's position on 'transformation': change is evolutionary and context-specific, driven by GCI and CoPs, not a big-bang rollout of a single prescribed model.

DA's position on 'hybrid': hybrid is the norm, not a compromise; DA deliberately combines practices from multiple sources and expects teams to blend cadence and flow as needed.

DA's origin: developed by Scott Ambler and Mark Lines, building on Agile Modeling, Agile Data, and Enterprise Unified Process experience; it is now stewarded by the Project Management Institute (PMI).

DA is published as an open, evolvable body of knowledge: the toolkit is updated as practitioners contribute practices and trade-off guidance, rather than being a fixed standard.

DA's relationship to PMI: PMI acquired the Disciplined Agile Consortium and offers DA certifications (e.g., Disciplined Agile Scrum Master, Disciplined Agile Senior Scrum Master, Disciplined Agile Coach, Disciplined Agile Value Stream Consultant); the DAF exam covers the foundations shared across these.

DA certification path: DASM covers foundational DA concepts and the Scrum Master role in a DA context; DASSM covers advanced team leadership and scaling; DAC and DAVSC cover coaching and value stream consulting.

DA's relationship to PMBOK: DA complements predictive project management by offering agile and hybrid options; PMI positions DA as a toolkit for choosing the right approach for the context.

DA's stance on predictive approaches: predictive/waterfall is a valid option in some contexts (e.g., stable requirements, regulatory gates); DA's goal diagrams include traditional options alongside agile ones.

DA's stance on 'agile at scale': scaling is about addressing coordination, architecture, governance, and funding across teams, not about replicating team ceremonies at a larger size.

DA's stance on 'business agility': true agility requires the business (funding, strategy, operations) to change along with IT; DAE addresses this beyond DAIT.

Inception decision points (goal 'Initiate a project'): how to initiate (lightweight vs formal), how much to invest in inception, how to fund, and how to staff; options include a vision statement, a business case, and a lightweight charter.

Construction decision points (goal 'Produce a potentially consumable solution'): how to build (iterations vs flow), how to organize the work (backlog, WIP limits), and how to integrate continuously.

Transition decision points (goal 'Deploy the solution'): how to deploy (manual vs automated), how to gain stakeholder acceptance, and how to handle release timing; options include continuous deployment and staged releases.

Production decision points (goal 'Operate the solution'): how to monitor, how to handle incidents, and how to feed operational learning back into delivery.

Retirement decision points (goal 'Retire the solution'): how to decommission, how to migrate data and users, and how to archive evidence for compliance.

Ideation decision points (goal 'Identify and fund an initiative'): how to identify opportunities, how to estimate value and risk, and how to decide funding; options include lean startup experiments and portfolio kanban.

Cross-cutting goal 'Address risk': decision points include how to identify risks (risk workshops, retrospectives), how to assess them (probability/impact, risk burndown), and how to mitigate them (spikes, prototypes, early delivery of risky items).

Cross-cutting goal 'Govern the team': decision points include how to measure progress, how to report, and how to align with enterprise governance; options include information radiators, metrics dashboards, and lightweight status reports.

DA's 'generalizing specialist' concept: team members have a deep specialty plus a working knowledge of adjacent areas, enabling swarming and reducing bottlenecks; this contrasts with narrow specialists who create handoffs.

DA's 'whole team' concept: the team includes all skills needed to deliver a consumable solution, including testing, architecture, and (via DevOps) operations; handoffs to external groups are minimized.

DA's 'swarming' practice: when a work item is at risk or a bottleneck forms, team members swarm on it rather than waiting; this is a flow-optimization option in goal diagrams.

DA's 'WIP limit' practice: limiting work in process improves flow and exposes bottlenecks; it is a core option in Lean and Continuous Delivery life cycles.

DA's 'continuous integration' practice: integrate frequently and run automated tests on every integration to keep the solution in a potentially consumable state.

DA's 'test-first' practice (TDD/ATDD): write tests before code to drive design and reduce defects; DA lists it as an option with trade-offs rather than a universal mandate.

DA's 'spike' practice: a time-boxed investigation to reduce technical or domain uncertainty before committing to a solution approach; commonly used in inception and construction.

DA's 'demonstration' practice: show working software to stakeholders at the end of each iteration to get feedback and validate value; DA treats demonstration as a goal, not just a ceremony.

DA's 'release plan' concept: a lightweight, rolling plan of what will be released and when, refined as work progresses; it is not a fixed commitment to scope and date.

DA's 'iteration plan' concept: a time-boxed plan of the work for the next iteration, derived from the prioritized backlog and refined just in time.

DA's 'backlog' concept: a prioritized list of work items (features, defects, technical debt, risks) that is continuously refined; DA supports both product backlogs and work-item lists in flow-based systems.

DA's 'minimum business increment' (MBI): the smallest increment that delivers value to the business and can be released; DA uses MBIs to plan releases that are valuable, not just shippable.

DA's 'potentially consumable solution' concept: the increment must be usable by stakeholders (deployed or deployable), which is stronger than 'potentially shippable' code.

DA's 'definition of done' concept: a shared, explicit checklist of what 'done' means for an increment; DA expects it to include quality, documentation, and deployment readiness criteria as appropriate.

DA's 'retrospective' concept: a recurring reflection on process and outcomes that feeds GCI; DA expects retrospectives to produce explicit choices, not just observations.

DA's 'information radiator' concept: a visible, low-cost display of key information (backlog, WIP, metrics, risks) that supports coordination and transparency without heavy reporting.

DA's 'lean' principles applied: eliminate waste, decide late, decide fast, deliver fast, optimize the whole, empower teams, build quality in, and amplify learning; these inform the goal-diagram options.

DA's 'decide late, decide fast' rule: defer irreversible decisions until you have enough information, but once decided, execute quickly; this supports emergent architecture and just-in-time requirements.

DA's 'optimize the whole' rule: improve the end-to-end value stream rather than a local team or step; local optimizations can harm overall flow.

DA's 'build quality in' rule: quality is designed and tested in continuously, not inspected in at the end; this drives test-first, continuous integration, and automated regression.

DA's 'amplify learning' rule: use retrospectives, demonstrations, and experiments to increase knowledge; learning is a deliverable, especially in exploratory contexts.

DA's 'deliver fast' rule: reduce batch size, limit WIP, and automate deployment to shorten lead time and increase feedback frequency.

DA's 'empower teams' rule: give teams the authority to choose their WoW and make technical decisions within guardrails; this is the basis for GCI and CoPs.

DA's 'eliminate waste' rule: remove activities that do not add value (unnecessary documentation, handoffs, waiting, rework); the goal diagrams help identify lower-waste options.

DA's 'enterprise awareness' concept: delivery teams operate within an enterprise context (funding, governance, architecture, operations) and must align with it; DA provides enterprise goal diagrams for this alignment.

DA's 'portfolio management' concept: fund and prioritize initiatives based on value and risk, using lightweight, evidence-based processes; DA supports both traditional and lean/agile portfolio approaches.

DA's 'enterprise architecture' concept: provide guardrails and reusable assets across teams without dictating team-level design; the Enterprise Architect role supports this.

DA's 'value stream' concept: the end-to-end sequence of activities that delivers value to the customer; DA encourages mapping and optimizing value streams rather than optimizing individual teams.

DA's 'process blade' concept: a cohesive area of guidance (e.g., continuous integration, release management, security, data management) that teams can pull from as needed; blades are a DAIT/DAE organizing device.

DA's 'guardrail' concept: enterprise-provided constraints or guidance (e.g., security standards, architecture principles) within which teams tailor their WoW; guardrails are not mandates.

DA's 'fitness for purpose' concept: the WoW should fit the team's context and risks; a WoW that is too heavy or too light for the context is a failure of tailoring.

DA's 'explicit choice' concept: record the rationale for WoW decisions so they can be reviewed and revised; implicit choices are harder to improve via GCI.

DA's 'servant leader' concept: leaders focus on removing impediments, coaching, and enabling the team rather than directing work; the Team Lead role embodies this.

DA's 'self-organizing team' concept: the team decides how to do the work and who does what, within guardrails; DA expects teams to also decide how to tailor their WoW.

DA's 'coaching' concept: coaching is a DA role responsibility (Team Lead) and a certification focus (DAC); coaching supports GCI and team maturity.

DA's 'facilitation' concept: ceremonies and workshops are facilitated to achieve their purpose (coordination, learning, decision-making) rather than performed ritually.

DA's 'stakeholder engagement' concept: stakeholders are engaged continuously through demonstrations, feedback loops, and collaboration, not just at sign-off.

DA's 'customer delight' principle: the ultimate measure is whether customers/stakeholders get value; process compliance is secondary to outcomes.

DA's 'be awesome' principle: teams should strive for high performance and continuous improvement, not just compliance with a process.

DA's 'pragmatism beats purity' principle: choose the practice that works in context, even if it is not 'pure' agile or 'pure' waterfall; the goal is outcomes, not ideology.

DA's 'risk-value life cycle' concept: work is sequenced to address high-risk, high-value items early, so that uncertainty and value are resolved as soon as possible.

DA's 'inception depth' rule: the depth of inception (vision, scope, architecture, plan, funding) should be proportional to the risk and uncertainty of the initiative; low-risk initiatives need less.

DA's 'transition readiness' concept: before deployment, the team verifies deployment readiness, stakeholder acceptance, and operational readiness; transition is a goal, not an afterthought.

DA's 'production support' concept: after deployment, the team (or DevOps function) monitors, fixes, and evolves the solution; operational feedback feeds back into the backlog.

DA's 'retirement' concept: solutions are decommissioned deliberately, with data migration, user communication, and compliance archiving; retirement is a planned phase, not neglect.

DA's 'ideation' concept: before inception, initiatives are identified, evaluated, and funded (or rejected) based on value and risk; ideation is the portfolio entry point.

DA's 'continuous delivery' concept: automate testing and deployment so that releases are low-risk and frequent; this is a life cycle choice and a set of practices.

DA's 'DevOps' concept: integrate development and operations (and security) to shorten lead time and improve reliability; DA DevOps is a layer above DAD.

DA's 'tailoring' process: (1) understand the context (scaling factors), (2) identify the relevant goal diagrams, (3) evaluate options and trade-offs, (4) make an explicit choice, (5) record the rationale, (6) measure outcomes, (7) revise via GCI.

DA's 'guardrail' vs 'mandate' distinction: guardrails define boundaries and principles; mandates prescribe specific practices. DA prefers guardrails plus team choice.

DA's 'CoP' vs 'PMO' distinction: CoPs share and evolve practice guidance; PMOs (in DA) provide governance and support services. DA expects them to collaborate, not compete.

DA's 'enterprise' vs 'team' goal distinction: team goals are about delivering a solution; enterprise goals are about coordinating teams, evolving WoW, aligning strategy, providing guidance, and governing the portfolio.

DA's 'life cycle' vs 'phase' distinction: a life cycle is the overall pattern of delivery (Agile, Lean, Continuous Delivery, Exploratory); phases (Inception, Construction, Transition, Production, Retirement) are stages within a life cycle.

DA's 'role' vs 'person' distinction: roles are sets of responsibilities; one person can hold multiple roles, and one role can be shared by multiple people.

DA's 'practice' vs 'process' distinction: a practice is a discrete technique (e.g., TDD, WIP limits); a process (WoW) is the tailored combination of practices a team follows.

DA's 'toolkit' vs 'methodology' distinction: a toolkit offers options with trade-offs; a methodology prescribes a specific set of practices. DA is a toolkit.

DA's 'value' focus: prioritize work by business value and risk; use MBIs to release value early and often; measure value delivered, not just work completed.

DA's 'quality' focus: build quality in with test-first, continuous integration, automated regression, and explicit non-functional requirements; quality is a goal, not a phase.

DA's 'architecture' focus: establish enough initial architecture to reduce risk, then evolve it; use spikes and refactoring; the Architecture Owner is accountable.

DA's 'requirements' focus: capture requirements as lightweight models and backlog items; elaborate just in time; involve stakeholders continuously; avoid big up-front specification.

DA's 'planning' focus: plan at multiple horizons (release, iteration, daily) with rolling refinement; use cadence or flow as appropriate; avoid fixed scope/date commitments where uncertainty is high.

DA's 'coordination' focus: coordinate within and across teams via daily coordination, demonstrations, CoPs, and cross-team roles; avoid heavy coordination bureaucracy.

DA's 'governance' focus: use lightweight, evidence-based governance aligned with delivery cadence; measure outcomes and flow; avoid document-heavy gates.

DA's 'improvement' focus: use GCI, retrospectives, and CoPs to evolve the WoW continuously; improvement is a habit, not a project.

DA's 'hybrid' examples: Scrum cadence with kanban WIP limits; XP engineering practices with DAD inception/transition; SAFe-style PI planning adapted to a DA team's context; waterfall gates for regulatory compliance within an agile delivery.

DA's 'choice' examples: a team may choose test-after for a spike and test-first for production code; it may choose manual deployment for a low-risk internal tool and automated deployment for a customer-facing service.

DA's 'context' examples: a co-located 5-person team may combine Team Lead and Architecture Owner roles; a distributed 50-person program may add Release Coordinator and Integrator roles and a CoP for architecture.

DA's 'scaling' examples: multiple teams coordinate via cross-team roles and CoPs; enterprise architecture provides guardrails; portfolio management funds initiatives by value and risk.

DA's 'compliance' examples: regulated contexts add traceability, formal reviews, and evidence archiving as explicit options in goal diagrams, without abandoning iterative delivery.

DA's 'exploratory' examples: lean startup experiments, MVP releases, and pivot/persevere decisions based on learning; funding is released in small increments.

DA's 'lean' examples: kanban with WIP limits, continuous flow, cycle-time measurement, and small batch sizes; suited to continuous arrival of work.

DA's 'continuous delivery' examples: automated build/test/deploy pipelines, feature flags, and frequent low-risk releases; suited to high deployment automation maturity.

DA's 'exam focus' areas: definitions (DA, DAD, WoW, GCI, goal diagram, CoP, scaling factors), life cycles (Agile, Lean, Continuous Delivery, Exploratory), phases (Ideation, Inception, Construction, Transition, Production, Retirement, Operations/Support), roles (Team Lead, Product Owner, Architecture Owner, Team Member, supporting, cross-team, governance), and principles (delight customers, be awesome, pragmatism beats purity).

DA's 'exam focus' on goal diagrams: know that they list goals, decision points, options, and trade-offs; know examples of team-level and enterprise-level goals; know they are used for explicit choice and GCI.

DA's 'exam focus' on tailoring: know the tailoring process (context → goal diagrams → options → explicit choice → measure → revise) and the role of guardrails and CoPs.

DA's 'exam focus' on scaling: know the scaling factors and how they drive WoW choices; know that scaling is about coordination, architecture, governance, and funding, not replicating ceremonies.

DA's 'exam focus' on DevOps: know that DA DevOps integrates development, operations, security, and support; know that DAIT and DAE extend DA beyond the team.

DA's 'exam focus' on principles: know the three guiding principles and the DA mindset (choice is good, context counts, pragmatism over purity).

DA's 'exam focus' on roles: know the four role categories and the primary roles' responsibilities; know that roles are tailorable and may be combined.

DA's 'exam focus' on life cycle selection: know which life cycle fits which context (uncertainty → Exploratory; continuous flow → Lean; deployment automation → Continuous Delivery; general delivery → Agile).