Assess nine team, culture, and project factors before choosing a method.
Locate / Start / Navigate
Public betaEducational decision support using transparent prototype weights. Validate consequential decisions with your team and subject-matter experts.How to use this beta
Methodology Compass by Methodology Guru
Find your real starting point.
Build your way forward.
Most teams begin with a methodology label. Compass begins with the team and context you actually have, identifies the strongest foundation for today, and maps the named practices that should shape your hybrid next.
See which methodology best fits the conditions you have today—and why.
Combine named practices into an explicit hybrid direction you can explain and test.
02
Find where to start
Strong signal
WHAT CHANGED?
Government program loaded. Hybrid balances adaptive delivery with high solution criticality.
04 / Navigate what comes next
Build your
hybrid direction.
Your starting point is not necessarily your destination. Compass keeps a named foundation and adds specific components for a reason, showing what to carry forward, what to borrow, and why the combination fits your context.
Core safeguardRecommendedOptional enhancement
Recommended next-state operating model
Predictivefoundation+Definition of Donefrom ScrumWork in Progress (WIP) Limitsfrom KanbanContinuous Integrationfrom Extreme Programming (XP)
Largely adaptive with a predictive component. Hybrid leads as a category; Predictive is the concrete delivery foundation.
STARTING FOUNDATIONPredictive
This is the primary operating pattern and the largest source of components in the recommendation.
Why it leads
Solution criticality88 +9.1
Higher consequences of failure increase the need for verification and traceability.
Team size24 +7.0
A multi-team delivery system increases dependency and coordination pressure.
Decision-making45 +0.7
Centralized decisions favor explicit escalation and approval paths.
Where it needs reinforcement
Definition of Donefrom Scrum
Solution criticality (88) and delivery cadence (55) require a shared, testable quality threshold for every completed increment.
Work in Progress (WIP) Limitsfrom Kanban
Limiting simultaneous work reduces context switching and makes blocked work visible.
What we take from Predictive
- Initiating
- Planning
- Executing
- Monitoring and Controlling
- Closing
- Scope Baseline
- Work Breakdown Structure
- Schedule Baseline
- Cost Baseline
- Risk Register
- Integrated Change Control
- Phase gates
- Acceptance and closeout
TAKE FROM ScrumCore
Definition of DoneSolution criticality 88Delivery cadence 55Delivery experience 75
- What it is
- A formal shared description of the quality state an Increment must meet before it is considered complete.
- How to use it here
- Make the criteria visible and apply them consistently to every completed Increment.
- Why this team
- Solution criticality (88) and delivery cadence (55) require a shared, testable quality threshold for every completed increment.
TAKE FROM KanbanRecommended
Work in Progress (WIP) LimitsDelivery cadence 55Requirements change 58Team size 24
- What it is
- An explicit policy that caps how many work items may be started but unfinished in each workflow state.
- How to use it here
- Define workflow states, set a visible limit for each active state, and pull new work only when capacity becomes available.
- Why this team
- Limiting simultaneous work reduces context switching and makes blocked work visible.
TAKE FROM Extreme Programming (XP)Recommended
Continuous IntegrationDelivery experience 75Requirements change 58Delivery cadence 55
- What it is
- Developers integrate changes frequently and verify the combined system with automated tests.
- How to use it here
- Integrate to the shared codebase at least daily, run the automated test suite on every integration, and repair a broken build immediately.
- Why this team
- Frequent change is safer when integration problems surface in minutes instead of near release.
TAKE FROM LeanRecommended
Value Stream MappingTeam size 24Delivery cadence 55
- What it is
- A current-state and future-state map of every step and information flow required to deliver customer value.
- How to use it here
- Map the path from request to release, classify delay and handoffs, then choose one systemic improvement instead of optimizing one team in isolation.
- Why this team
- Size and delivery friction suggest that the constraint may sit between teams rather than inside one team's process.
TAKE FROM SAFeRecommended
System DemoTeam size 24Delivery cadence 55
- What it is
- An integrated demonstration of new work from all participating teams, evaluated by stakeholders as one system.
- How to use it here
- Keep team-level delivery methods, but add a shared cadence where integrated work - not team slide decks - is demonstrated end to end.
- Why this team
- Large-team delivery needs an integration feedback loop across team boundaries.
TAKE FROM LeanRecommended
Standard WorkSolution criticality 88Requirements change 58Delivery experience 75
- What it is
- The current best-known documented way to perform repeatable work, used as a baseline for learning.
- How to use it here
- Document critical repeatable steps, follow them, and update the standard when a better method is proven.
- Why this team
- High criticality (88) and comparatively stable requirements (58) make a controlled, improvable standard valuable for repeatable work.
TAKE FROM Extreme Programming (XP)Optional
Test-First DevelopmentSolution criticality 88Delivery experience 75
- What it is
- Write an automated test for the desired behavior before writing the code that makes the test pass.
- How to use it here
- Use the red-green-refactor loop for business rules and critical code; keep the resulting tests in the continuous integration pipeline.
- Why this team
- Critical behavior benefits from executable specifications and rapid regression feedback.
TAKE FROM Extreme Programming (XP)Optional
Pair ProgrammingTeam trust 62Delivery experience 75Solution criticality 88Requirements change 58
- What it is
- Two developers work together at one workstation, continuously reviewing design and code as it is created.
- How to use it here
- Pair on complex, risky, or knowledge-spreading work and rotate partners deliberately.
- Why this team
- Team trust (62) and experience (75) can support pairing where criticality (88) or change (58) demands rapid technical feedback.
TAKE FROM LeanOptional
A3 Problem SolvingTeam size 24Solution criticality 88Team trust 62
- What it is
- A concise, evidence-based problem-solving process that captures context, cause, countermeasures, and follow-up.
- How to use it here
- Use one A3 to align people on a significant problem and test countermeasures against a target condition.
- Why this team
- Team size (24) and criticality (88) increase the value of a shared, evidence-based problem-solving record.
Component library
Explore named practices
The model-selected recommendation appears above. Use this read-only reference to see the full anatomy of every methodology in the race and understand the named components that make each one a coherent system.
Scrum
A complete Scrum system combines accountabilities, events, artifacts, and a commitment attached to each artifact.
- Product Owner
- Scrum Master
- Developers
- Sprint
- Sprint Planning
- Daily Scrum
- Sprint Review
- Sprint Retrospective
- Product Backlog
- Sprint Backlog
- Increment
- Product Goal
- Sprint Goal
- Definition of Done
Practice detailsWhat selected components mean and when they help
Sprint Goal
The single objective for a Sprint that gives the team flexibility in the exact work used to achieve it.
Useful when: an iteration is becoming a disconnected list of tasks.Sprint Review
A working session where the team and stakeholders inspect the Sprint outcome and adapt what to do next.
Useful when: stakeholder feedback needs a reliable, outcome-focused cadence.Sprint Retrospective
A recurring event to inspect how the team worked and plan improvements to quality and effectiveness.
Useful when: delivery repeats but the operating system is not deliberately improving.Definition of Done
A formal shared description of the quality state an Increment must meet before it is considered complete.
Useful when: 'done' means different things to different people or hidden work appears late.Sprint Planning
The event that establishes why the Sprint is valuable, what can be done, and how the work will get done.
Useful when: short-cycle work needs an explicit goal and shared commitment.Product Backlog
An emergent, ordered list of what is needed to improve the product and the single source of work for the Scrum Team.
Useful when: requests are fragmented across channels and competing queues.Responsible beta use
Use the signal. Keep the judgment.
An educational compass for diagnosing context, identifying a defensible starting methodology, and articulating a hybrid direction.
A probability of success, compliance determination, or replacement for experienced professional judgment.
Nine Agile Practice Guide factors with transparent prototype weights. Methodology Guru data is not connected yet.
Review assumptions with the delivery team, test the recommended components, and revise the blend as evidence changes.
Improve the public beta
Did this starting point and direction make sense?
Feedback is stored without an account or analytics identifier. Do not include confidential or personal information.