Dialogic Leadership Agile vs Waterfall Polarities: A Guide
Nour
Founder, Coachful
The dialogic leadership Agile vs Waterfall polarities question becomes useful when it names the actual decision. Which uncertainty needs feedback? Which commitments need dependable controls? Who may approve the next step? A disagreement about those needs deserves more attention than a contest between method labels.
This guide develops a complete fictional portal-design decision. The group proposes a bounded test, discovers that its prototype is not isolated, repairs the condition and completes two small observations. It then records what the evidence supports, what remains uncertain and why production release is still a separate decision.
Describe the approaches before diagnosing a polarity
The Manifesto for Agile Software Development values responsiveness, working software and collaboration while explicitly acknowledging value in the other items it compares. Its principles include technical excellence and a sustainable pace. They do not instruct teams to discard all plans, documentation or assurance.
Scrum is a specific framework, not a synonym for every Agile practice. The November 2020 Scrum Guide connects transparency, inspection and adaptation to defined accountabilities, events, artifacts and commitments. A team borrowing a short review meeting should not claim that this alone implements Scrum.
A sequential arrangement organizes work through stages and dependencies. Whether it is useful depends on the actual uncertainty, obligations, evidence and ability to revisit a decision. Ask what the organization means by Waterfall instead of assuming it means that no feedback ever occurs.
Keep three questions separate: which process will govern this project, what the team needs to learn now and what must be true before a particular release. They may interact, but choosing a process does not answer every technical or authorization question.
The UK Service Manual's agile-governance principles combine iterative improvement with decision boundaries, accountability and verification. That guidance describes government service delivery; it is a useful reference, not a claim that every private organization has identical rules.
Distinguish recurring needs from a finite choice
Barry Johnson's Polarity Management distinguishes ongoing, interdependent demands from problems with a discrete resolution. Here, learning from new information and making dependable commitments can both remain necessary. The labels Agile and Waterfall are not automatically the two poles.
A team may need feedback to avoid committing to a misunderstood design. It may also need stable responsibilities so people can support the service. Pursuing feedback without boundaries can create uncontrolled changes. Preserving a plan without examining assumptions can preserve an avoidable defect.
That does not mean every option deserves compromise. A missing mandatory approval is a condition to resolve. An inaccessible interface is not one side of a balanced discussion about preferences. A contractually fixed requirement needs its actual change process; a dialogue exercise cannot quietly vote it away.
Use four original working questions: what does useful learning provide, what happens when learning lacks dependable boundaries, what do dependable commitments protect, and what happens when commitments prevent necessary learning? These questions support inquiry. They are not a reproduction of Johnson's formal map or an assessment of method loyalty.
The separate polarity management guide develops the recurring-needs lens. Use it when both needs really persist. Use a decision process when an authorized owner must select a specific option.
Use dialogue to expose assumptions and still make a decision
William Isaacs' original Dialogic Leadership article describes listening, respecting, suspending certainty and voicing. Suspension concerns making an assumption available for examination, rather than suppressing a concern. Respect means investigating the sense in another account without being obliged to accept its conclusion.
Apply those practices to evidence. “You are blocking Agile” becomes “Which condition prevents this test?” “You are reckless” becomes “What can the prototype currently send, and where?” A specific answer may change the proposed action without resolving every philosophical disagreement.
The facilitator should apply the same discipline to their own theory. Perhaps the issue is interdependent needs. Perhaps it is a missing owner, a contradictory contract or an unsuitable test environment. Do not keep reframing after the group has identified a straightforward requirement.
Dialogue also needs an ending. State whether the output is a proposal, an authorized decision or a request for another owner's response. Dissent can be recorded accurately without manufacturing consensus. A warm conversation that leaves authority obscure has not completed the job.
Establish the fictional decision and the real boundaries
All people, dates, records, technical findings and results in this case are fictional. Nadia owns an internal support portal. Ben leads product work, Iris owns support operations, Theo is the authorized technical and security reviewer, and Rae leads the user-research exercise. Jo is an external leadership coach facilitating one 60-minute workshop on 9 November 2026 and a 20-minute review on 20 November.
The five internal owners agree that scope and the audience for the decision record. Jo facilitates the discussion and records agreed leadership actions. Jo does not approve technical isolation, research arrangements or production deployment. Private individual reflections are not part of the shared meeting record.
The proposed learning question is whether staff can distinguish “change an existing request” from “start a new request” on two form screens. Five internal support staff may volunteer for a small exercise using invented cases. They are not a representative sample of external customers.
Nadia can authorize this internal prototype exercise only after Theo confirms its technical boundary and Rae confirms the participant arrangements. Iris confirms that the existing support route remains authoritative. A live portal change requires the organization's separate release process and its own evidence.
Nadia allocates 15 internal staff hours to the workshop, preparation, technical checks, two small observations and the review. Jo's separately purchased 80 minutes of facilitation sit outside that staff allowance. The trial cannot acquire more work simply by being called iterative.
Complete the first brief rather than debate the labels
Ben initially proposes releasing the revised live form to a small audience. Iris wants the complete specification approved before anything changes. Theo asks whether the learning question requires an operational submission at all. Rae says label comprehension can first be explored through a non-operational prototype.
The group fills this brief during the workshop. Its status is a proposal with explicit conditions, not an immediate release authorization.
| Brief field | Completed proposal on 9 November |
|---|---|
| Question | Can five volunteer internal staff distinguish the two request categories using an isolated prototype? |
| Learning output | Two invented scenarios per participant, with unprompted category choice and the person's explanation recorded. |
| Scope | Two screens and invented cases. No operational submission, real customer records or live-service change. |
| Dependability | The existing portal remains authoritative; the test must not interrupt support or create a real request. |
| Required confirmation | Theo confirms the technical boundary; Rae checks the volunteer brief and record handling; Iris checks service continuity. |
| Decision owner | Nadia authorizes only after those confirmations are recorded. Jo's agreement with the idea is not approval. |
| Alternatives | Repair the prototype, use a static demonstration with a revised task, narrow the question or defer. |
| Reopen condition | A connection to operational systems, unexpected data or an interruption pauses the affected exercise for review. |
The brief separates a learning purpose from the means proposed to achieve it. “We need feedback” no longer automatically means “we must release live.” It also makes the staged controls specific instead of using “the gate” as an unexplained veto.
The four-perspective review produces actual trade-offs. Learning may reveal misleading labels before more work is committed. Unbounded testing could send information into real support. Dependability preserves the authoritative request route and responsible owners. An inflexible specification could prevent the team from noticing an important misunderstanding. These are reasons to design the next action, not four equally weighted votes.
Give the sixty-minute conversation a useful structure
- Minutes 0–10: Nadia states the question, current authority and limits. Jo checks that the group agrees which decision is being discussed.
- Minutes 10–20: Each owner explains the requirement or failure they are trying to address. Jo asks for examples instead of method stereotypes.
- Minutes 20–35: The group examines learning and dependability, including the consequences of overemphasizing either.
- Minutes 35–50: They complete the brief, compare feasible options and identify the missing confirmations.
- Minutes 50–60: Nadia records the conditional proposal, assigns the checks and confirms the communication route and review date.
The blocks total 60 minutes. The five internal attendees contribute 300 staff minutes; Jo contributes 60 separately contracted minutes. Research, technical work and later review still require their own time. A one-hour workshop is not a one-hour project.
Ben: If we wait for the whole specification, we will learn too late.
Iris: I need one reliable request route. Two partly working routes would create a support problem.
Jo: Ben, could you describe what Iris must protect before defending your option?
Ben: Staff must know where a real request goes, and support must not have to reconcile test submissions.
Theo: Then our question is whether this prototype can meet that boundary. We have not checked it yet.
Nadia: Agreed. The test is proposed. It is not authorized until the confirmations are recorded.
No one has to praise a method or withdraw a legitimate objection. The useful shift is a testable condition, an owner and an honest status.
Retain the failed check and complete the repair
On 10 November, Theo checks the prototype before participant sessions begin. Pressing its submit control still calls an operational request service. That contradicts the brief. No participant exercise occurs, and the group does not describe this version as isolated because it uses invented text.
Nadia keeps the test unauthorized. Ben and Theo remove the operational connection and replace the sample material with newly created fictional records. They check the revised version and its allowed interaction path. On 13 November, Theo records that the reviewed prototype no longer sends a request to the operational service. Iris confirms that the live route is unchanged. Rae completes the participant brief and record-handling arrangements.
Nadia then authorizes that reviewed prototype and the defined exercise. The permission names the version and scope. It is not transferable to a later live implementation with different behavior.
NIST's final SSDF Version 1.1 describes secure-development practices that can be integrated into different life cycles. Its current publications list distinguishes that final document from the Version 1.2 draft. The framework supports taking security work seriously across approaches; it does not certify this fictional prototype or make Jo a technical assessor.
The retained failure matters. The workshop did not establish isolation through consensus. It made the requirement visible, after which a responsible owner found and repaired a defect.
Complete the learning exercise with actual outputs
On 16 November, Rae runs two invented scenarios with each of the five volunteers. One scenario describes an update to a request already submitted; the other describes a separate new need. The participant chooses a category and explains the choice before Rae offers assistance. The existing portal is not changed.
| Participant | First exercise, unprompted correct choices out of two | Observed explanation or difficulty |
|---|---|---|
| 1 | 2 | Distinguishes an existing request from a new need. |
| 2 | 1 | Reads “change” as changing the kind of service requested. |
| 3 | 2 | Uses the existing request reference to explain the distinction. |
| 4 | 1 | Needs a prompt on one scenario; the prompted choice is not counted as unprompted correct. |
| 5 | 1 | Starts a new request for a follow-up to an existing one. |
The total is seven unprompted correct choices out of ten task attempts, not seven successful people. The record includes the three attempts that did not meet that definition. It does not become a general usability score for the portal.
Ben revises the first label to “Update a request you already sent” and adds an instruction to use the existing request reference. The second becomes “Start a separate new request.” On 19 November, the same five volunteers try fresh invented scenarios with the revised screens. They make nine unprompted correct choices out of ten; one attempt still needs assistance.
One remaining difficulty concerns a person who wants to add a separate issue while an older request is still open. Rae records the unresolved category rule instead of silently redefining that attempt as correct. Product and Operations need to clarify that rule before another test.
The observed difference is two choices out of ten, or 20 percentage points. The participants have already seen the exercise, the scenarios changed and the sample is small. This is evidence for another design inquiry, not proof that the revised words caused a 20-point improvement for customers. It also says nothing about production security, accessibility or support performance.
Reconcile time and finish the next decision
The completed internal time record contains 300 minutes for the five owners' workshop, 120 for the technical check and repair work, 45 for research preparation, 150 for the first observation including participants and Rae, 30 for label revision, 100 for the repeat observation including participants and Rae, and 100 for the five owners' 20-minute review.
That totals 845 staff minutes, or 14 hours five minutes, against 900 minutes allocated. Fifty-five minutes remain. Simultaneous work by a participant and researcher counts twice. Jo's 60-minute workshop and 20-minute review total the separate 80-minute facilitation service.
At the 20 November review, Nadia records the following decision. The reviewed prototype exercise is complete. The existing portal remains unchanged. Product and Operations own the unresolved category rule. A further exercise with new participants needs its own scope, technical boundary and time allocation; it is not silently funded from the remaining 55 minutes.
| Final decision record | Actual fictional output |
|---|---|
| Keep | Small learning exercises with explicit boundaries and recorded owners. |
| Change | Clarify how a separate issue relates to an open request before preparing another participant task. |
| Retain as evidence | Failed initial isolation check, repaired version, seven of ten first choices and nine of ten repeat choices, with limits. |
| Production status | Not authorized by this exercise. The organization's release process and remaining requirements apply. |
| Further test status | Proposed, not authorized or funded. Ben and Iris prepare the rule; Nadia decides on any new allocation later. |
| Facilitation close | Jo's agreed service ends after the 20 November review. Company owners continue their own work; no extra coaching round is implied. |
The group has not adopted a universal hybrid formula or reached agreement about the best method for every project. It has completed a specific inquiry and made a bounded next decision.
Use a different response for a fixed obligation
Consider a separate fictional migration where a contract requires an approved interface definition before another organization begins its work. The product lead wants to revise that definition during implementation. The delivery owner verifies the actual obligation with the contract owner rather than treating it as a cultural preference.
The buyer's contract owner confirms that a separate internal mockup is permitted without changing the supplier's approved interface. The supplier lead acknowledges the resulting record: “The current milestone uses interface 2.1. An internal mockup may explore 2.2, but it is not a supplier instruction or an authorized production-interface change. Any proposal to change 2.1 goes back through the contract change process.” The current milestone still uses the approved definition. The coach does not convert that finite contractual decision into a requirement to balance two philosophies equally.
Likewise, urgent defects, personal conduct and safety concerns may require their own established procedures. Dialogue can clarify evidence and responsibility while those procedures operate. It cannot replace them with a more agreeable conversation.
Keep leadership preparation separate from delivery authorization
Coachful is our #1 recommendation for organizing the leader's preparation, original reflection worksheet and agreed coaching follow-through. Its useful role here is a record of questions, assumptions and actions. It is not the technical release system or a certification of the team's delivery method.
Prepare an original worksheet with the decision, learning question, dependable boundary, required owner, actual evidence and next status. Deliberately grant the individual leader access and review the actual staff audience. Copying a private resource link alone does not grant access. The form-builder image illustrates structured preparation, not the portal prototype or an approved release.
In this fictional engagement, Nadia sends permitted preparation summaries through her one-to-one Coachful Messages conversation with Jo; Jo replies there about the two agreed facilitated meetings. The other internal owners receive the agreed decision brief through the company's normal project workspace. Technical reports, participant notes and actual approval records stay in that authorized delivery system.
Use a client task for an agreed leadership action such as asking the authorized owner to clarify a boundary. A completed task records the action, not readiness for release. Keep Jo's own preparation separate from Nadia's assignments. If a recap is used, inspect its audience and approval controls before sharing; a private coaching interpretation should not become a team report by default.
The goal image shows demo tasks and reflection tabs, not evidence of this project's results. Explore Coachful's preparation and follow-up features. For a wider change, the digital-transformation dialogue guide examines steering responsibilities beyond one bounded test.
Frequently asked questions
Are Agile and Waterfall automatically a polarity?
No. Look for the actual ongoing, interdependent needs and distinguish them from a process choice. Learning and dependable commitments may both persist while one specific option is selected now.
Does Agile remove documentation or assurance?
No. The Agile Manifesto acknowledges value in planning and documentation, and its principles include technical excellence. Determine the actual evidence and responsibilities needed for the proposed work.
Must a dialogic workshop reach consensus?
Use the organization's real decision rule. Participants can understand each other's reasoning while still disagreeing. Record the authorized decision, dissent and unresolved conditions accurately.
What should happen when a prototype check fails?
Keep the affected permission pending, record the actual defect and obtain the required repair or choose another permitted option. Invented data alone does not prove technical isolation.
Does a successful test authorize production release?
No. A prototype answers a bounded question under its own conditions. Production can have different data, technical behavior, users and responsibilities. Its actual release requirements still apply.
How can a coach tell whether the conversation helped?
Look for a clearer assumption, a completed inquiry, an explicit owner or a decision that changed because evidence changed. Broader delivery or financial effects require their own observations and consideration of other explanations.
Primary-source scope
The conceptual orientation draws on the original Agile Manifesto and principles, Schwaber and Sutherland's November 2020 Scrum Guide, Isaacs' Dialogic Leadership and the publicly visible summary of Johnson's Polarity Management. NIST and the UK Service Manual provide the cited technical and governance context. The workshop schedule, brief, cases and all numerical records here are original fictional illustrations.
