Agile fails every time? Let's retrospect!

Let's start with something a bit off-topic. There is a very interesting definition for money - Money is what money does. Duh? We can barely argue with the logic there, but not exactly useful. If you must go on to explain the definition, would it not then beat the sole purpose? (Side-note: I believe recursive acronyms to be just as confusing! GNU? GNU's Not Unix!)

I found this bit from Young Sheldon very amusing. Sheldon explains it to be a tautology - something that is always true, but uninformative. Coming to think of it, Agile, by definition, could never fail. It is a tautology of its own - if you fail, you learn; review; retrospect; improve. Agile, done right, can never fail. But the definition is, ahem, not very definitive.

Now before I rant further, let me paste the manifesto, ??? ???? ???? ???? Individuals and Interactions over processes and tools??? ???? ???? Working Software over comprehensive documentation??? ???? ???? Customer Collaboration over contract negotiation??? ???? ???? Responding to Change over following a plan

The predicate for every Agile project is a cross-functional, self organizing team that leads from within and is responsible for the project as a whole. The Manager (Scrum Master , Kanban Practitioner, or any other imposing title) should be more or less, just an assistant (a servant leader) to the team - helping and guiding them; clearing the impediments; fostering growth and communication; keeping an open mind to suggestions and using best judgement to smooth out conflicts. Just to refine the statement, his job is not 'the delivery' of the project; the team should be capable of doing that, it is not assigning tasks to individual members; the team should be self organizing to decide on how to best proceed, it is not estimating the tasks in terms of man hours or person days; estimation, if done, should only be used to help the team track progress and must use "relative" units (name them story points, apples or oranges). Comparing two agile projects based on efforts would then literally be comparing apples to oranges.

"Agile" cannot help you if managers continue to run the project and use teams as tools to build it up nor if the team is not mature enough to take responsibility and march together towards a shared and defined goal that quantifies success. Without trust and mutual respect, a team cannot achieve an Agile transformation; and yes, Agile would fail you every time.

Working software sounds a bit misleading for me. "Maintainable, self documented and quality code, over written pamphlets" makes better sense. That being said, it wouldn't necessarily hurt to keep notes (as JSDocs or inline-comments that can be collected with a parser) that can give insights on how to navigate and use the code (for retrospection and for people who don't necessarily code the same programming vernacular!) If you use it as an excuse to develop rapid iterations without proper documentation - yes, Agile would fail you every time.

Customer collaboration is something that should be embroidered in gold. You need customers who can share the same mindset. When you develop in a time-boxed environment, there will always be room for improvement. Changing requirements and evolving designs would enforce code refactors and architectural modifications. On a long run, technology debts should also be factored in. When a team pitches efforts for refactoring code, it is not necessarily because of bad programming. Something which looked optimal at the time, may not be the best way to go about, several iterations later. Modifying code like so, may also not reflect with "business outputs", but is a necessary evil nevertheless and can save efforts on the long run. If you use Agile as an excuse to change requirements and expect to reap only the benefits, Agile would fail you every time.

Responding to Change over following a plan. This is the part of Agile definition that makes it future-proof! Agile is all about being amphibious and adaptive. You must be always on the lookout for opportunities, review and evaluate progress, find ways to minimize wastage and constantly evolve to outpace failures. Unlike the waterfall where everything is glued together at the very end, Agile implementations typically focus on providing multiple pit-stops to regroup and re-evaluate. But if you are resistant to change and not pick up actionable improvements along the way, then yes, Agile would fail you every time.

Then again, being Agile is not about never having failures. It is about doing things better leveraging the new learning. The article may be filled with anecdotes and is highly opinionated, but the next time you believe Agile has failed you, there may be something more to think about. Feel free to agree/disagree, like or share.