Over the years, I’ve been fortunate to work with teams across different industries, countries, and organisational functions, applying agile principles using both Scrum and Kanban. Below are a few of the key lessons from that original training, and how I’ve seen them play out in the wild.
Why agile, not waterfall?
Before diving in, it’s worth naming the elephant in the project room. Traditional waterfall approaches lean heavily on extensive up-front planning, captured in detailed requirements documents and rigid project plans. They assume the team can predict, in advance, exactly what should be built and how long it will take.
Agile takes a different bet: that requirements will change, that customers learn what they want by seeing working software, and that small, frequent course-corrections beat one big plan that goes stale on contact with reality.
The advantages of agile over waterfall, in short:
- Faster, more frequent value delivery rather than a single big-bang release at the end.
- Built-in feedback loops, so wasted effort is caught early.
- Adaptability to change, instead of fighting it through change-request bureaucracy.
- Higher team engagement through self-organisation and ownership.
- Stronger stakeholder relationships thanks to visibility, predictability, and transparency.
With that framing, here are the lessons that have stuck with me.
1. Self-organisation and servant leadership
This was a big shift for me on the original course, especially compared with traditional project management. Role-play exercises drove the difference home: instead of a project manager maintaining a master task list and assigning work, team members pulled tasks from a shared board against an agreed goal.
As an independent software developer at the time, this resonated immediately. Since then, I’ve worked in plenty of organisations still transitioning from traditional project management to more agile ways of working. Where managers have genuinely embraced servant leadership, I’ve consistently seen the same pattern: happier individuals, more effective collaboration, and stronger stakeholder relationships through timely delivery, improved quality, and an ability to absorb changing requirements gracefully.
2. Frequent delivery of working software
This is surely one of agile’s most important principles — and one of the easiest to underestimate.
Adopting Scrum is a good start, but it’s no silver bullet. Far from instantly resolving a team’s process issues, it tends to amplify visibility of the problems already lurking. In my experience these fall into two camps:
- People and collaboration: can the team communicate and collaborate quickly enough to iterate in step with business feedback?
- Technical readiness: is the architecture flexible enough to accommodate change? Is there a release and deployment process capable of shipping frequently — or continuously?*
Performance is also shaped by wider organisational dynamics: prioritisation conflicts, cross-team dependencies, financial approvals, and the like. The Product Owner and Scrum Master (or Project Manager, depending on the setup) need to clear those hurdles so the team can focus on its sprint commitments. The Product Owner, in particular, must understand the business well enough to help the team navigate trade-offs — between new features, technical debt, and production support — and to give meaningful input on technology and infrastructure decisions.
Not every backlog item lends itself to iterative customer feedback. Infrastructure projects, or data work without a customer-facing front-end, often don’t. These can still be broken into smaller, estimable tasks and reviewed iteratively to ensure they stay on track.
3. Iteration
Iteration is the very thing that distinguishes agile from waterfall, which leans on extensive up-front planning built on a tower of assumptions.
Instead of an exhaustive requirements document, requirements are broken into small user stories that can be delivered within a single sprint. A user story is deliberately concise — its purpose is to prompt a conversation between developer and Product Owner, not to specify every detail in advance. Feedback gathered during or at the end of an iteration is then folded back into existing or new stories for the next round.
Sprints can run up to four weeks, but in practice I’ve found two weeks tends to work best. On one team we shortened from four weeks to two and saw immediate benefits: tighter focus and far more frequent feedback from stakeholders.
4. Customer feedback
End-of-sprint demos are a brilliant way to get feedback from users and customers. Of course, not everything in a sprint is necessarily demo-able, so it pays to agree in advance which items will be shown, prepare an agenda, and run through it as a team beforehand. A quick tech check ahead of time avoids a lot of avoidable awkwardness on the day.
Some sprints we’ve had stakeholders attend demos directly — ideal for fast feedback. Other times, demos have been deferred until items are ready. The principle that matters: stay in frequent contact with the people who can give meaningful feedback. If a demo isn’t viable in a particular sprint, replace it with a mid-sprint meeting to review designs or clarify uncertain requirements.
5. Responding to change over following a plan
One exercise from the original course has stayed with me. We were given rules for how instructions could be passed between team members to move from one point in the room to another. One team had a short discussion and started moving. The other tried to plan every step in advance.
The team that moved first won easily. The lesson: it’s often better to take an early step, learn, and let the next move become clearer — rather than attempting to plan every move up front.
Scrum mirrors this. The next sprint should be planned in detail because clarity is at its highest there; planning fades as you look further out. Within a sprint, you want a clearly prioritised set of stories — but resist the urge to over-specify each one before development starts. Keep stories simple, concise, and open to conversation. Once work begins, get business feedback as often as possible to make sure effort is going where it actually creates value.
6. Delivery of value through a potentially shippable product
Agile emphasises delivering value frequently, with a potentially shippable product at the end of each sprint. For features to be genuinely shippable, they need to have passed QA and user testing — and that’s rarely as easy as it sounds within a sprint timebox.
It takes time to verify that requirements meet their acceptance criteria after development. In some organisations I’ve worked in, a dedicated QA function didn’t exist, and testing fell to project managers or business analyst teams. That’s a stop-gap, not a substitute: a dedicated QA professional who understands the system deeply and works directly with developers consistently delivers better outcomes.
Test-driven development (TDD) has helped enormously here, prompting test scenarios to be written before development begins. Pair that with well-structured user stories — clear acceptance criteria, explicit user benefit statements — and a behaviour-driven development (BDD) approach to writing scenarios, and you have a much firmer foundation for shipping with confidence.
Key takeaways
- Self-organisation beats command-and-control. Trust teams to pull work, and you’ll get happier people and better outcomes.
- Scrum reveals problems; it doesn’t solve them. Treat the visibility as a gift, not an indictment.
- Two-week sprints are the sweet spot for most teams — long enough to deliver, short enough to learn.
- User stories are conversation starters, not specification documents.
- Move first, plan less. Early action surfaces clarity that no amount of up-front planning can.
- Feedback is the engine. Demos, mid-sprint check-ins — whatever it takes to stay close to the user.
- Shippable means tested. Without proper QA discipline, “potentially shippable” quickly becomes “potentially embarrassing.”
* Continuous delivery, as referenced in the principles behind the Agile Manifesto.
Chandran Honour's Blog 
Leave a comment