Overview
Exploring More Scenarios extends the two worked scenarios to harder and less familiar contexts. Complex delivery covers situations where scaling factors pile up: large or geographically distributed teams, several teams building one solution, high domain or technical complexity, or regulatory compliance. DA addresses these with options such as the Program lifecycle, a team of teams coordinated through shared cadences, product owner and architecture owner coordination, and early integration.
Non-IT teams, such as marketing, finance or HR, show that the DA mindset is not limited to software. Their work is often continuous and request-driven, so flow-based practices from the Lean lifecycle frequently fit, with vocabulary adapted to the domain. The module closes by consolidating the course: the mindset from module 1, the knowledge base from module 2, diagnosis from module 3 and value acceleration from module 4, applied as an ongoing habit of guided continuous improvement rather than a one-time project.
How it's tested
Questions here combine context factors or move outside software. Expect scenarios such as five teams building one product across two countries, or a marketing team overwhelmed by requests, followed by 'what is the MOST appropriate approach' or 'what should the team do FIRST'. The right answer applies the same DA principles: understand context, choose fit-for-purpose options, coordinate only as much as needed, and improve through experiments.
-
Coordinate a team of teams
Several teams must deliver one solution, and you choose coordination that aligns them without centralizing every decision.
-
Translate to non-IT
A non-software team has a flow or overload problem, and you pick the DA practice that fits, often visualizing work and limiting WIP.
-
Stack the scaling factors
Distribution, compliance and complexity are all present, and you choose the option that addresses the most consequential factor.
Four teams build one product, and integration problems surface only at the end of each quarter. Ask what complex delivery needs: shared cadence and early, frequent integration across teams. The DA-consistent answer is a team-of-teams structure with regular cross-team coordination and continuous integration of all teams' work. Assigning a central manager to plan every team's tasks adds hand-offs and delay and does not fix the late integration.
Module topics 3
Official module topics from the PMI outline, in outline order.
7.1 Complex delivery teamsScaling factors, team of teams and cross-team coordination.
- What it means
- Complex delivery covers contexts where scaling factors combine: team size, geographic distribution, organizational distribution, domain and technical (solution) complexity, skill availability and compliance. DA offers the Program lifecycle for a team of teams and options for coordinating them.
- What to understand
- Scale coordination to the need: shared cadence, cross-team product owner and architecture owner coordination, visible dependencies and frequent integration. Each scaling factor adds specific risks, such as communication delays from distribution or documentation needs from compliance, that change which options fit.
- How it shows up
- Several teams must deliver one solution and you choose the coordination approach that surfaces integration problems early.
- Common confusion
- Equating scaling with adding a central planning layer; DA prefers coordination among semi-autonomous teams.
7.2 Non-IT teamsApplying DA to marketing, finance, HR and other business teams.
- What it means
- Non-IT teams use the same DA mindset and many of the same practices, adapted to their work, which is often continuous, request-driven and subject to its own constraints such as campaign dates or regulatory deadlines.
- What to understand
- Visualizing work, limiting WIP, classes of service for fixed-date items and regular replenishment translate well. Use the team's own vocabulary; 'deploy' becomes 'publish' or 'launch'. The principles transfer even when software-specific options, such as continuous integration, do not.
- How it shows up
- A business team is overloaded or misses deadlines, and you choose the DA practice that fits its work pattern.
- Common confusion
- Assuming DA applies only to software, or forcing software practices and terms onto a business team.
7.3 Consolidating learning and applying DA principlesTurning the course into an ongoing habit at work.
- What it means
- Consolidation means applying the course as a repeatable approach: understand the context, diagnose the constraint, find options in the knowledge base, order improvements and run experiments, then repeat.
- What to understand
- Start where the team is, change one thing at a time, measure results, and keep evolving the WoW through the Evolve WoW goal. DA's value is in this ongoing cycle, not in a single redesign.
- How it shows up
- After a course or workshop, a team asks how to begin, and you choose a small first experiment on its biggest problem over a full process redesign.
- Common confusion
- Treating DA adoption as a one-time transformation project with a fixed end state.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Scaling factors
DA's scaling factors are team size, geographic distribution, organizational distribution, skill availability, domain complexity, technical (solution) complexity and compliance.
- Remember
- Each factor adds specific risks, and the options a team needs depend on which factors are present and how strongly.
- Tested as
- Complex delivery scenarios name several factors and ask which option fits.
- Trap
- Treating scale as only team size and ignoring distribution or compliance.
-
Program lifecycle
DA's lifecycle for a team of teams building one solution, adding coordination of planning, architecture, product direction and integration across the sub-teams.
- Remember
- Sub-teams may each use different lifecycles while sharing coordination points.
- Tested as
- The fitting lifecycle when several teams deliver one product.
- Trap
- Assuming every sub-team must use the same lifecycle.
-
Team of teams coordination
Coordination in a large program through shared cadences, cross-team meetings of product owners, architecture owners and team leads, and visible dependencies.
- Remember
- Coordinate the minimum needed and keep decisions close to the teams doing the work.
- Tested as
- Most complex delivery questions are about how teams align.
- Trap
- Adding a central manager who plans every team's tasks.
-
Early and frequent integration
Integrating all teams' work continuously or at least every iteration so cross-team defects surface while they are cheap to fix.
- Remember
- Late integration is a primary risk in multi-team delivery.
- Tested as
- The fix when problems appear only at the end of a release.
- Trap
- Adding an integration phase at the end instead of integrating continuously.
-
Compliance as a context factor
Regulatory compliance adds requirements for evidence, traceability and review that the team's WoW must satisfy.
- Remember
- Build compliance evidence into the work, for example automated audit trails, rather than adding a separate phase.
- Tested as
- Appears in complex delivery and in non-IT teams such as finance.
- Trap
- Treating compliance as a reason agile cannot be used.
-
Geographic distribution
Team members spread across locations and time zones, which slows communication and feedback.
- Remember
- Compensate with overlapping working hours, shared digital boards, written agreements and occasional in-person time.
- Tested as
- Common in scenarios combining several scaling factors.
- Trap
- Assuming tools alone remove the cost of distance.
-
DA for non-IT teams
Business teams such as marketing, HR or finance apply the DA mindset and suitable practices, often flow-based, to their own work.
- Remember
- Principles transfer; specific options and vocabulary are adapted.
- Tested as
- Questions ask how a business team should start applying DA.
- Trap
- Introducing software-only practices such as code reviews to a marketing team.
-
Exploratory lifecycle
DA's Lean Startup style lifecycle for high uncertainty: form hypotheses, build minimal experiments, observe results, then pivot or proceed.
- Remember
- It fits new ideas whose value is unproven, in IT and non-IT contexts.
- Tested as
- Appears when a team must test whether an idea is worth building at all.
- Trap
- Running full delivery on an untested idea.
-
Evolve WoW
Evolve WoW is the ongoing process goal covering how a team keeps improving its way of working, through retrospectives, experiments and the knowledge base.
- Remember
- Improvement never finishes; it is part of normal work.
- Tested as
- Underpins consolidation questions about what a team does after the course.
- Trap
- Treating process improvement as a separate, time-limited project.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Central planning vs. team-of-teams coordination
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Central planning | One manager or group plans tasks for every team | Decisions flow down; adds hand-offs and delay | Chosen because it looks controlled |
| Team-of-teams coordination | Semi-autonomous teams align through shared cadence, cross-team roles and visible dependencies | Decisions stay close to the work; coordination is just enough | Mistaken for no coordination at all |
Software team vs. non-IT team application
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Software team | Uses DA options including technical practices such as continuous integration and automated testing | Technical practices are central | Assuming non-IT teams need the same technical options |
| Non-IT team | Uses the DA mindset with flow, visualization, WIP limits and classes of service adapted to business work | Principles transfer; vocabulary and options adapt | Concluding DA does not apply because there is no software |
Exploratory vs. Agile lifecycle
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Exploratory lifecycle | Hypothesis-driven experiments to test whether an idea has value | Fits when value is unknown | Skipping it and building a full solution for an unproven idea |
| Agile lifecycle | Iteration-based delivery of a solution whose value is reasonably understood | Fits when the team knows what to build and needs to deliver it | Using iterations to discover whether anyone wants the product at all |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Central control for scale
- What candidates pick
- Appointing one manager to plan all teams' work.
- Why it looks right
- Central control looks like the cure for coordination problems.
- Why it's wrong
- It adds hand-offs and delays; DA coordinates semi-autonomous teams through shared cadence and cross-team roles.
Clue to watch for Teams already have product owners and architecture owners who could coordinate.
-
End-of-release integration
- What candidates pick
- Adding a dedicated integration phase before release.
- Why it looks right
- It concentrates integration effort.
- Why it's wrong
- It postpones discovery of cross-team defects; frequent integration finds them early and cheaply.
Clue to watch for Integration problems are discovered late.
-
Uniform lifecycle across sub-teams
- What candidates pick
- Requiring every team in a program to run identical iterations.
- Why it looks right
- Alignment seems to need uniformity.
- Why it's wrong
- Sub-teams can use different lifecycles if they share coordination points; context counts at team level too.
Clue to watch for One sub-team handles unpredictable work while others build planned features.
-
Software practices for business teams
- What candidates pick
- Introducing technical practices such as continuous integration to a marketing team.
- Why it looks right
- They are well-known agile practices.
- Why it's wrong
- Practices must fit the work; flow, visualization and WIP limits translate, software-specific practices often do not.
Clue to watch for The team produces campaigns, policies or reports, not software.
-
Agile is not for regulated work
- What candidates pick
- Keeping a regulated finance team on a heavy serial process.
- Why it looks right
- Compliance seems to require it.
- Why it's wrong
- DA treats compliance as context to design for, building evidence into the work rather than ruling out agility.
Clue to watch for The scenario names a regulation but no rule that forbids iterative work.
-
Big-bang adoption
- What candidates pick
- Redesigning the whole department's process after the course.
- Why it looks right
- It shows commitment to the new approach.
- Why it's wrong
- DA favors starting where you are and improving through small experiments on the biggest problem.
Clue to watch for The question asks what to do first after training.
Answer framework
Use this sequence when a scenario combines scaling factors or moves outside software delivery.
- Name the context factors present, such as size, distribution, compliance, complexity or a non-IT domain, and decide which one matters most.
- Decide whether one team or a team of teams is needed, and whether the work is planned, flow-based or exploratory.
- Choose coordination that keeps decisions close to the teams: shared cadence, cross-team roles and visible dependencies.
- Adapt options and vocabulary to the domain, keeping principles such as visible work, limited WIP and classes of service for fixed dates.
- Start with one experiment on the biggest problem, measure it, and keep evolving the WoW rather than redesigning everything at once.
Practice question
Want more like this? The DASM practice test has questions for every domain.
Checklist
0 of 11
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Treat this module as a test of transfer rather than new content. Start with the scaling factors: for each one, write the specific risk it adds and one DA option that addresses it. Then study the Program lifecycle and team-of-teams coordination, focusing on how teams align on cadence, product direction, architecture and integration without a central planner.
Next, pick two non-IT teams you know, such as marketing and HR, and sketch how each would apply DA: what their work items are, which classes of service they need and what WIP limits might look like. Notice which software practices drop out and which principles stay.
Commonly underestimated areas are mixed lifecycles within a program and the Exploratory lifecycle for unproven ideas. Finally, consolidate the course: write the sequence you have used throughout, from context to diagnosis, options, improvement backlog and experiments, and apply it once to a team you work with. Then use the practice test to check every module together.
FAQ
Does DA require a scaling framework for large programs?
No. DA offers the Program lifecycle and coordination options and treats other frameworks as possible sources of practices. The choice depends on the scaling factors present.
Can sub-teams in a program use different lifecycles?
Yes. A program can mix lifecycles as long as teams share the coordination points needed to integrate and align on direction.
Does Disciplined Agile work outside IT?
Yes. The mindset and many practices, especially visualizing work, limiting WIP and classes of service, apply to marketing, HR, finance and other business teams.
What is the best first step after the course?
Pick one team's biggest problem, choose an option from the knowledge base, run it as a measured experiment and review the result. DA favors starting where you are.
How does compliance affect a DA team?
It adds evidence and review requirements the WoW must meet. DA builds those into the work rather than treating them as a reason to avoid agility.
Is this module covered on a DASM exam?
PMI's DASM page now describes the DA Foundations course and lists no exam, so there is no published weighting. This module still brings together everything the course teaches.
How long should I spend on this module?
Plan for about two to three hours, including a sketch of DA for one complex delivery and one non-IT team.
Other Project Management certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
- PRINCE2 7 Practitioner Study guide
- PMI Risk Management Professional Study guide
- PMI Scheduling Professional Study guide
- Project Management Professional Study guide
- CompTIA Project+ Study guide
- PRINCE2 7 Foundation Study guide
- Portfolio Management Professional Study guide
- Program Management Professional Study guide
- Certified Associate in Project Management Study guide
- Agile Project Management Study guide
- PMI Agile Certified Practitioner Study guide
- Project Management Professional (PMBOK 7) Study guide
Test your Domain 7 knowledge
You have just applied DA to complex delivery and non-IT teams and pulled the course into one repeatable approach. Test it across all seven modules with mixed scenarios.