The Unwritten Playbook: Consulting Advice They Don’t Teach You in Training

Agile in the Real World: Beyond the Textbook

“We’re fully Agile,” the client’s delivery director assured me on my first day. By the end of the week, I’d discovered their version of “fully Agile” meant:

Two-month “sprints”
A 400-page requirements document that couldn’t be changed
Daily stand-ups that routinely lasted 45 minutes
A product owner who needed five layers of approval to make decisions

This wasn’t the exception—it was the norm. In over a decade of consulting, I’ve never encountered a client environment that perfectly matched the Agile methodologies described in training courses or certification programmes.

Welcome to the third instalment of “The Unwritten Playbook,” where I’m sharing the consulting truths they don’t teach you in formal training. Today, we’re tackling the gap between Agile theory and client reality, and how to deliver value when nothing matches the textbook.

Agile Theatre vs. Agile Value: Recognising the Difference

Many organisations have adopted the ceremonies of Agile without embracing its principles. They’re performing what I call “Agile Theatre”—going through the motions without reaping the benefits.

I once joined a project where the team proudly showed me their Kanban board with perfectly arranged columns and colour-coded cards. Yet when I asked how often cards moved across the board, the awkward silence told me everything. The board was updated only for sprint reviews—essentially a static presentation tool rather than a living workflow management system.

The difference between Agile Theatre and Agile Value lies in outcomes, not activities:

Signs of Agile Theatre:

Ceremonies held religiously but without purpose
Extensive documentation of “user stories” that function as traditional requirements
Sprint plans that never change during execution
Retrospectives where the same issues arise repeatedly without resolution
Product backlogs managed exclusively by project managers, not product owners

Signs of Agile Value:

Frequent delivery of working software
Genuine customer feedback influencing priorities
Team empowerment to make technical decisions
Visible improvement in processes over time
Focus on outcomes rather than output

As consultants, we’re often caught in a difficult position: clients hire us to implement Agile but aren’t prepared for the organisational changes required for success. I’ve found the most effective approach is to focus on incremental value delivery rather than methodological purity.

Unwritten Rule 1️⃣: Don’t fight for Agile purity; fight for the principles that deliver value in your client’s context. One real improvement is worth a hundred textbook implementations.

Translating Methodologies: Matching Agile Approaches to Client Cultures

Not every organisation is ready for the same flavour of Agile, and forcing a mismatch creates resistance rather than results.

I learned this lesson working with a government agency with strict governance requirements. Our initial attempt to implement Scrum failed spectacularly because the two-week sprint cycle conflicted with their monthly steering committee structure. When we adapted to a more Kanban-style approach with monthly demonstration points aligned to their governance, we suddenly made progress.

Assess your client’s Agile readiness across these dimensions:

Organisational Structure:

Hierarchical → Self-managing
Siloed → Cross-functional
Centralised → Distributed decision-making

Planning Horizon:

Annual budgeting → Continuous funding
Fixed scope → Flexible priorities
Detailed upfront → Progressive elaboration

Risk Tolerance:

Risk-averse → Risk-balanced
Process-focused → Outcome-focused
Failure-punishing → Learning-oriented

Then select and adapt your approach accordingly:

For traditional organisations: Consider Scrumban with longer cycles aligned to governance
For regulatory environments: Emphasise documentation and traceability within iterative delivery
For hierarchical structures: Implement clear escalation paths and decision frameworks
For risk-averse cultures: Start with low-risk areas to demonstrate success

I’ve found that a “principles-first” approach works better than a “practices-first” approach. When clients understand and buy into the why of Agile (faster feedback, reduced risk, increased adaptability), they become more open to adapting their processes to achieve those benefits.

Unwritten Rule 2️⃣: Meet clients where they are, not where the Agile manifesto thinks they should be. The path to true agility is itself incremental.

The Fixed-Price Paradox: Agile in Non-Agile Commercial Models

Perhaps the greatest contradiction in consulting is being asked to implement Agile within the constraints of fixed-price, fixed-scope contracts. This fundamental tension creates challenges that no certification course prepares you for.

On a digital transformation project, my team was contracted to deliver a specific set of features for a fixed price. The client wanted “Agile delivery” but wasn’t willing to adjust scope as we learned more about user needs. We were caught between contractual commitments and Agile principles.

Here’s how to navigate this paradox:

Separate the commercial model from the delivery model
→ The contract may be fixed, but the implementation approach can still be iterative
→ Create a “scope buffer” by identifying lower-priority items that could be traded
Define outcome-based acceptance criteria
→ Shift from “building features” to “solving problems”
→ Create space for discovery while maintaining commercial boundaries
Use tiered scope classifications
→ Must-have requirements (contractually binding)
→ Should-have capabilities (implementation flexibility)
→ Could-have enhancements (if time/budget permits)
Implement rolling wave planning
→ Detail near-term work while keeping future work flexible
→ Regular re-prioritisation within the overall scope boundary
Establish change threshold agreements
→ Define what constitutes material change requiring commercial adjustment
→ Create lightweight change processes for smaller adjustments

The most successful approach I’ve used is to frame Agile as a risk-reduction strategy for fixed-price work. By delivering incrementally and gathering feedback early, we reduce the risk of building the wrong thing—a benefit to both client and consultant.

Unwritten Rule 3️⃣: Fixed-price contracts and Agile delivery can coexist if you separate what must be fixed (commercial terms) from what should be flexible (implementation approach).

Ceremonies That Actually Work: Cutting Through Ritual to Create Value

Agile ceremonies often degrade into meaningless rituals that teams endure rather than benefit from. As consultants, we need to revitalise these practices to deliver their intended value.

I joined a project where the daily stand-up had devolved into a 40-minute status report to the project manager. Team members were disengaged, checking emails or multitasking during the call. By restructuring the stand-up around impediments rather than status updates, we cut it to 12 minutes and dramatically improved collaboration.

Here’s how to transform the core ceremonies from rituals to value-creators:

Daily Stand-ups:

Focus on blocking issues, not status reports
Use a physical or virtual board as the central point, not people
Implement the “walk the board” approach rather than the three questions
Schedule technical discussions immediately after, but separate from the stand-up

Sprint Planning:

Do preparation work before the session (refinement)
Focus on outcomes, not just task breakdown
Include explicit discussion of risks and dependencies
End with a team commitment, not just assignment

Reviews/Demos:

Make them interactive, not presentational
Focus on business value, not technical completion
Include affected stakeholders, not just the product owner
Capture feedback systematically for action

Retrospectives:

Vary the format to maintain engagement
Focus on actionable improvements, not just discussion
Track implementation of previous retro actions
Create safety for honest conversation

The most effective Agile teams I’ve worked with treat the ceremonies as tools, not obligations. They constantly adjust the format, duration, and frequency based on team needs and project context.

Unwritten Rule 4️⃣: The purpose of Agile ceremonies is to solve problems and improve delivery, not to follow a script. If a ceremony isn’t adding value, change it or drop it.

The Consultant’s Secret Weapon: Incremental Value in Traditional Environments

Even in the most traditional, waterfall-oriented client environments, we can introduce Agile principles that deliver immediate benefits without requiring wholesale methodology changes.

While working with a financial services client committed to their stage-gate process, I still managed to transform their approach by introducing three Agile principles that didn’t threaten their governance:

Demonstrable increments
→ Breaking large deliverables into smaller, demonstrable pieces
→ Creating review points within phases, not just between them
Feedback loops
→ Involving end users earlier in the process
→ Creating mockups and prototypes for validation before full development
Visible workflow management
→ Making work and blockers visible
→ Tracking actual vs. planned progress visibly

The client maintained their familiar process while gaining many Agile benefits. Later, as they saw the value, they became more open to broader methodology changes.

Some of my most successful “Agile transformations” never used the word Agile. Instead, I focused on specific pain points:

“Let’s reduce the risk of misunderstanding by showing working software earlier”
“We can identify integration issues sooner by testing components incrementally”
“A visual workflow board will help us spot bottlenecks before they delay the project”

Unwritten Rule 5️⃣: Don’t fight the client’s methodology head-on; instead, introduce Agile principles as solutions to specific problems they recognise.

The Definition of Done Dilemma: Quality vs. Speed

In textbook Agile, the Definition of Done ensures quality is built into every increment. In reality, clients often pressure teams to prioritise speed over completeness, creating technical debt and future problems.

On a retail client project, pressure to meet a market deadline led to a “we’ll fix it later” mentality. Six months later, “later” never came, and the accumulated technical debt had reduced development velocity by 60%.

Here’s how to manage this tension:

Create a graduated Definition of Done
→ Minimum DoD for all work (never compromised)
→ Standard DoD for most work (occasionally flexed)
→ Ideal DoD for critical components (when time allows)
Make technical debt visible
→ Track shortcuts explicitly as “debt stories”
→ Estimate the interest rate (future cost) of each debt item
→ Include debt metrics in reporting
Establish a debt repayment plan
→ Allocate a percentage of each sprint to debt reduction
→ Prioritise debt that impedes current development
→ Connect debt repayment to future capability delivery
Educate on the economics of technical debt
→ Show how initial speed creates later slowdowns
→ Quantify the cost of delayed debt repayment
→ Demonstrate velocity impacts with data

The most effective approach I’ve found is to reframe the conversation from “quality vs. speed” to “short-term speed vs. sustainable speed.” This shifts the discussion from a technical concern to a business decision about long-term delivery capacity.

Unwritten Rule 6️⃣: Never fight for quality in engineering terms; fight for it in business terms of sustainable delivery and total cost of ownership.

Navigating Distributed Agile: When the Team Is Everywhere

The ideal of co-located, fully dedicated Agile teams rarely exists in consulting engagements. More often, we work with teams distributed across locations, time zones, organisations, and competing priorities.

On a global transformation programme, our team spanned four countries and seven time zones. The textbook approach of daily face-to-face communication was impossible. We had to reinvent our Agile practices for distributed reality.

Strategies that actually work for distributed Agile:

Overcommunicate visually
→ Use digital Kanban boards with rich information
→ Create information radiators accessible to all locations
→ Develop visual status reporting that doesn’t require real-time explanation
Establish core collaboration hours
→ Identify time windows when all team members can collaborate
→ Schedule key ceremonies within these windows
→ Rotate meeting times to share the time zone burden
Create location-based sub-teams
→ Form complete, cross-functional capabilities at each location
→ Minimise dependencies between locations
→ Create local team leads responsible for coordination
Implement asynchronous ceremonies
→ Record demos for asynchronous viewing
→ Use digital tools for ongoing retrospective input
→ Create standup slacks or channels for updates
Invest in relationship building
→ Start projects with virtual team building
→ Create non-work connection opportunities
→ When possible, bring teams together physically at critical junctures

The distributed teams that function best establish clear protocols for both synchronous and asynchronous communication, making explicit what requires real-time discussion versus what can be handled offline.

Unwritten Rule 7️⃣: In distributed Agile, communication must be deliberately designed, not left to chance. What happens naturally in co-located teams must be explicitly structured in distributed ones.

Case Study: Pragmatic Agile in a Resistant Environment

Let me share a real example of navigating these challenges in practice:

I led a digital transformation project for a traditional insurance company with a strong command-and-control culture. The executive sponsor wanted Agile delivery but the organisation had:

Quarterly funding reviews
A detailed business case with fixed scope
Separate development and testing teams
A heavyweight change control board
Limited user access for feedback

Rather than forcing textbook Scrum, we created a hybrid approach:

We established two-week development iterations within six-week “delivery increments” that aligned with their governance cycle
We maintained the fixed scope boundary but created flexibility in how features were implemented
We ran Agile ceremonies with the core team but translated outputs into the governance documentation the organisation expected
We created a “user proxy” group from internal stakeholders when actual users weren’t available
We demonstrated working software at the end of each two-week iteration but only formally delivered at six-week boundaries

The result? We delivered the project successfully, and more importantly, the client gradually adopted more Agile practices as they saw the benefits. Two years later, they had transformed their entire delivery approach—not because we insisted on methodological purity, but because we showed pragmatic value.

Conclusion: Principles Over Practices

After years of implementing “Agile” in environments ranging from startups to government agencies, I’ve come to a simple conclusion: the principles matter more than the practices.

The Agile Manifesto values “individuals and interactions over processes and tools,” yet ironically, many Agile implementations become obsessed with specific processes and tools. The most successful Agile consultants I know focus relentlessly on the outcomes Agile was designed to achieve:

Delivering value early and often
Reducing the cost of change
Improving quality through feedback
Enhancing team collaboration
Creating sustainable delivery pace

When you focus on these outcomes rather than methodological purity, you can find ways to bring Agile benefits to even the most traditional environments.

In consulting, our job isn’t to implement Agile—it’s to help clients deliver better software more effectively. Sometimes that means textbook Scrum, sometimes it means pragmatic hybridisation, and sometimes it means subtle introduction of Agile principles within existing frameworks.

The measure of success isn’t how purely you implemented the methodology; it’s whether you left the client better able to deliver value than when you arrived.

In the next post in this series, I’ll explore “Team Whispering: Navigating the Human Dynamics No One Prepared You For”—the unwritten rules of working with the complex team dynamics that can make or break your consulting success.

Until then, remember that Agile is a means to an end, not an end in itself. Be principled in your goals but pragmatic in your approach.

What’s the biggest gap you’ve encountered between Agile theory and practice? Share your experiences in the comments below!

Photo by Medienstürmer on Unsplash

The Unwritten Playbook: Agile in the Real World