On agile purists

Waterfall ensures productive use of people's time through detailed scheduling and resource management; Agile replaces schedules with self-direction, a culture of collaboration, and a pull system of work.

Somewhere between waterfall and agile is a canyon of chaos where there are neither the detailed personnel schedules of waterfall or a a high-quality backlog of business value-prioritised work that teams can pull from. In this canyon, there's a lot of downtime, wheel-spinning, and lack of direction.

This is why agile coaches can sometimes be perceived as impractical "purists". It's not because they are ideologues; they only want teams to cross the river quickly and not getting bogged in the mud.

So-called "pragmatic" or "real world" agile is not a safe middle ground. It's no man's land. It's quicksand. You have neither the benefits or tools of either waterfall or agile. It's both ineffective and inefficient.

You lose your detailed functional requirements but fail to replace it with a high-quality product backlog that is frequently reviewed and checked for alignment against business objectives and user needs.

You lose the hierarchy of top-down management but fail to empower teams to rise to the challenge of figuring out the most efficient path to meet stories.

You lose months of up-front planning but fail to regularly inspect and adapt, following a plan that hasn't been validated, not open to new information and feedback.

It tempting to think you can have the best of both worlds - waterfall and agile - but if you can't commit to adopting and embracing the practices, values, and most importantly the mindset and culture of agile then you might be better off sticking to waterfall.

Think about it: Why might agile coaches insist on doing agile properly, even arguing with the clients who pay their invoices? What's in it for them when they risk being terminated?

Nothing. They're only looking out for you, because they've seen teams attempt "wagile" or "waterscrum" before and it's horrific.

They're not agile fanatics; they only want you to succeed.

That said, agile is a very loose philosophy and Scrum only slightly more defined as a methodology. There is a wide band of tolerances, plenty of room to figure out how to make it work for you and your team.

You can have backlog refinement meetings, or not. Product owners can attend daily stand-ups, or not. You can have a physical product backlog, or stick it all in TFS. You can write "As a __ I want to __ so that __" formatted user stories, or not. You can be co-located, or distributed and do everything via JIRA, Slack, and phone.

As long as you understand the consequences of such configuration decisions and focus on what's in the best interests of the team, business, and users of the product or services you're implementing, not what is easiest or comfortable.

What isn't optional is building projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done, where working software is the primary measure of progress and maximising the amount of work not done.

Read the rest of the principles behind the agile manifesto.