On Agile coaching
When someone says "Agile," what's the first thing you picture? Probably Scrum—daily stand-ups, sprint retrospectives, or colourful Post-it notes covering office walls. But what if I told you that Agile originally had less to do with ceremonies and more with hardcore developer practices? Yes, Agile started deeply rooted in Extreme Programming (XP). Let's unpack this together, inspired by Uncle Bob’s influential piece, "The Land that Scrum Forgot."
The Roots of Agile: Beyond the Industry Complex
Before Agile became synonymous with Scrum, XP was the only game in town. XP wasn't about a few daily rituals; it was about coding excellence, frequent releases, and tight collaboration among developers. Uncle Bob, a founding voice in Agile, highlighted how the industry shifted from an XP mindset to that of management frameworks. They abandoned the technical discipline that makes agility what it once was.
On the 12 Agile Principles: And Why Agile Coaches Need Developer Experience
As a supplement to the original manifesto, agile principles one by one show why successful Agile coaches must have genuine development experience:
1. "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."
Releasing early means releasing software with the right amount of features, and the right amount of technological complexity. This means as much as releasing a proper Minimum Viable Product, or so-called MVP. It can also mean the release of canary versions. The incremental (and strategic) release of software at such stages is a skill of technological prowess. That skill cannot be gained without ever being knee-deep into the general engineering practice.
On the other hand, Continuous Delivery (CD) requires other specialised tech skills. It's not trivial to achieve full Continuous Delivery. The term does not mean simply using CI/CD tools, which is a common misconception. An Agile coach with thorough delivery experience understands the practice of Continuous Delivery.
Continuous Delivery means that we reduce the lead time of the product to the absolute minimum. (Lead time is the time between the initiation and completion of a production process) We aim to release software daily (eventually). Here, we must understand concepts such as Trunk-Based development, apply them successfully and know how to create quality gates (the QA part of the process) so that software is released frequently but doesn't ship bugs, or irrelevant acceptance criteria.
2. "Welcome changing requirements, even late in development."
Handling changes late in the project is both a stakeholder problem, as much as it's a developer's problem. The tools and techniques originating in Kent Beck's Extreme Programming literature are indispensable here. One such technique is incremental design, supported by merciless refactoring and automated tests, but there are many more. Those techniques enable the "agility" required to correct the course of the project in the face of changing requirements.
Again, it’s an engineering skill, it's a design skill. A coach experienced in XP-style practice knows how to guide teams safely through late-stage changes.
3. "Deliver working software frequently, from a couple of weeks to a couple of months, preferring shorter timescales."
The phrase "prefer shorter timescales" refers to the ongoing battle towards releasing multiple times daily, which is the gold standard.
To deliver working software frequently, the codebase must be in a deployable state at all times. That requires the discipline (and the culture) of feature toggles, small incremental commits, and sweeping automated tests. Coaches who’ve lived this understand the tooling, but more importantly, the mindset.
4. "Business people and developers must work together daily."
This one isn’t just about having a product owner in the room. It’s about creating shared understanding through concrete examples and language. It is about the collaborative story writing, discovery phases of the product and ongoing dialogue.
The common language between tech and business is often called Ubiquitous language, a practice originating from Domain-Driven Design. One way to get to such a common language is Event Storming.
The requirements discovery, on the other hand, is often the practice of Behaviour-Driven Development (BDD), a practice deeply rooted in Test-Driven development, another sibling engineering practice. BDD discovery sessions involve a few hours of business (or product) spending time with tech tech teams.
Coaches with a development background know the difference between cooperation and true collaboration. They know BDD, and they know a few more useful tricks.
5. "Build projects around motivated individuals."
Motivated developers are often those trusted to make decisions, write clean code, and explore solutions. Coaches who have written production code are better equipped to create cultures where developers own the work, not just execute tasks.
Motivated individuals are characterised by constant striving towards excellence and continuous improvement, which is a very important mindset to have. They are also constantly looking for growth opportunities.
6. "The most efficient and effective method of communication is face-to-face conversation."
For developers, this often means sitting at the same machine, pairing, whiteboarding design ideas, or doing real-time code walkthroughs. Coaches who have experienced the flow of shared problem-solving can foster these moments better than any scheduled sync.
Pair programming is no silver bullet, and it's only one side of the coin. Face-to-face conversation also means that we often have to pair up with the stakeholders and show them a working piece of software.
7. "Working software is the primary measure of progress."
Not velocity, not burndown charts. Coaches with a technical background understand that only running, tested features matter. And they know what it takes behind the scenes—test harnesses, build pipelines, small deployable units—to make that possible.
Who knows best what's the working software if not engineers writing it? Craftsmen at work. Those are the people who can truly tell you if we made any progress at all. It may be that because of a strong business push, we incurred more debt and that won't get us far in the long run. Again, engineers are the instruments of measurement in this situation.
8. "Agile processes promote sustainable development."
Burnout often stems from fragile codebases and the unsustainable pace. Technical debt accumulates when short-term speed trumps long-term thinking. Coaches familiar with TDD, clean architecture, and SOLID principles can teach teams to go fast and safely.
Sustainable development means that the cost of change of any software system does not increase over time. The only guardrail here is engineering craftsmanship.
9. "Continuous attention to technical excellence and good design enhances agility."
Technical excellence is not a bonus—it’s a must. Agile coaches with a dev background know how to push for better design decisions, cleaner abstractions, and tighter feedback loops. They've done the hard work of fixing and refactoring messy code and know how to avoid it.
10. "Simplicity—the art of maximizing the work not done—is essential."
Simplicity in software often means rejecting cleverness in favour of clarity. It means choosing boring, well-known tools when they get the job done. Coaches who’ve shipped real systems understand the long-term value of simple code over shiny abstractions.
Engineering seniority is perhaps the most key aspect in achieving simplicity. We should write code that is clearly understood, keeps proper self-descriptive conventions and refrains from premature optimisations.
11. "The best architectures, requirements, and designs emerge from self-organizing teams."
Self-organizing teams don’t just happen—they're cultivated. Developers need a shared understanding of the system, a sense of ownership, and safety to make decisions. Coaches who’ve worked in high-trust environments know how to set this up.
12. "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts accordingly."
Points of reflection aren’t just feel-good meetings. The best teams use them to question their process and their technical decisions. Coaches who’ve seen the impact of refactoring, testing strategies, or new build tools can bring practical improvement ideas to the team.
The Japanese term "Kaizen" means as much as "good change", and we should keep it in mind all the time. It should become second nature to take action and improve existing processes and our software.
How Agile Lost Its Technical Roots—And Why It Matters
Uncle Bob was right: When we look at some methodologies, such as Scrum of SaFe, we can see that what we commercially understand by Agile has drifted dangerously into management territory. It forgot the engineering core of XP. An effective Agile coach isn’t just a facilitator but a technical mentor (or a technical leader). Without this lens, teams risk practising Agile in name only—losing true agility altogether.
Bringing back developer discipline isn't nostalgic; it's what must be done to save the name of the Agile movement. Genuine Agile coaches know that Agile isn't about a few strange ceremonies, stand-ups or story points—it’s about sustainable, high-quality code and skilled, confident developers.
Conclusion
Does Agile coaching make sense, then? Does the role of an Agile coach have value? Absolutely. However, this is only if coaches deeply understand the technical heart of Agile.
In other words, yes to both questions. 100%.