Now we have much of the industry equating Agile with the Scrum methodology. The software industry is aligning itself around this specific methodology and selling a wide variety of training, coaching, and tools – for good money – to set up a pre-defined set of procedures and methodologies for us to be Agile. That in itself seems anti-Agile.

One of the most cringe worthy things I heard once was that Agile would enable us “to do twice as much work in half the time”. I’m an engineer and I understand that statement means I get to work 4 times as hard in a given time frame to deliver the needed result. That is another of the fallacies of the Agile/Scrum framework. Besides asking for 100% resource commitment, it asks that teams deliver at 2 week increments again and again and again. Regardless of how committed you may be, it is difficult to maintain a work quality of life at that pace.

What we haven’t figured out – and certainly not at scale – is how to “deliver twice as much VALUE to the customer while doing half as much work.”

Agile is one of those concepts that – much like the “pyramid scheme”, or even “communism” to give very extreme examples – looks convincing on paper, but fails if/when you try to execute it without properly considering the ultimate success factors.

For any project, there are at least 3 general “pillars” of project success; 100% resource commitment, 100% developer expertise, and 100% stakeholder feedback.

There are many times these 3 can never be 100% achieved in the qualitative world we live in, and unless you have really great project management and room to fail, even the lack of or weakness in one of those “pillars” will cause the entire project to come crashing down to a halt; this failure is further amplified with the sprint-like nature and hapless misunderstanding of Agile project management.

While it might not help to be critical of Agile projects underway, it may be useful to those managing, to constantly reevaluate and remind themselves of the pitfalls of the four concepts of Agile project methodology, while mapping them to the 3  general project success pillars for more emphasis:

1.) Individuals and Interactions over processes and tools – requires 100% resource commitment; eliminating a few “unnecessary processes” here and there isn’t gonna do squat unless the resources you choose have absolutely nothing else they are working on or bound to other than your project, and that usually isn’t the reality; this cannot be stressed more, and it’s cringeworthy when you see Agile projects set up to fail because the sprint timeframes (e.g. 1-2 weeks at a stretch) didnt consider the reality of the resources; if nothing else, just remember, not all people work well under pressure.

2.) Working Software over comprehensive documentation – requires 100% developer expertise; even if let your resources code/develop all week with no regard to comprehensive knowledge transfer or documentation, they can only deliver within the limits of their knowledge, and if they’re not documenting the design, then you’re asking for a lot of rework/risk when it fails due to a poor design/concept. Be prepared in that case to spend more money/time to bring in another “expert” later to comprehensively pick your product apart and try to figure out what went wrong; or have the previous resource comprehensively learn from their incomprehensive planning/designing in order to fix.

3.) Customer Collaboration over contract negotiation – requires 100% stakeholder feedback; even if you had the perfect committed team of experts, you have to also manage the business and user resources to ensure your team has a continuous stream of feedback necessary to strive for perfection. This isn’t exclusive to Agile though, it applies to any project methodology. If you’re not constantly managing expectations/feedback throughout the project from your stakeholders then brace yourself for a lot of changes as you near implementation at each sprint, which leads us into….

4.) Responding to Change more than following a plan; I’ll admit when I first read this I was literally ROFL, but perhaps because I misinterpreted the meaning; contrary to popular belief it doesn’t mean forgo planning, throw all your resources into a room, just wing it, and go wild with every single change that comes your way. It means understand that change happens in a project, and what’s important is how your team responds by prioritizing the change with your stakeholders and resources, and being able to accept it into your project without further reprimand or risk; both of which you are prone to without a proper plan for budget, time, and resources.

Then again, talk is cheap, so perhaps I could have saved myself (and everyone else’s) time by simply going with the engineer’s or consultant’s answer “it depends” on the project…it’s just that I’ve also generally found it helpful for people t remember to distinguish between reality and concept; a clarification that should be universally accepted by all.