I have observed that there are two kinds of Agile.
"Agile in doctrine" is the kind all of the anti-Agile crowd rail against because they've been burnt by working for some company or manager who drank the Koolaid without actually understanding what Agile is. Blindly following some consultant's Agile playbook is not Agile.
"Agile in spirit" is a bit like The Zen of Python: X is usually better than Y but there are times where it makes complete sense to do Y. In order for Agile to work, you need to have leaders and CIs who understand that. Agile emphasizes communication and flexibility. Agile is advisory, not prescriptive.
I largely agree with you, but when it comes to evaluating competing methodologies, what you refer to as “agile in spirit” turns quickly into No True Scotsman. “If you project failed you mustn’t have been doing agile correctly.”
There is some virtue to your criticism, but it is also not entirely true. There are things you can check to see if a team is doing Agile for real, like, what's the last process change you experimented with to see if it improved your outcomes? What experiment failed and was dispassionately removed from the process because it didn't work out? When your team's workload nature changed (e.g., from new development to maintenance), how did you adapt your processes to match? Do your processes come up from the team and their experience or do they source from above with effectively no feedback?
At that point, if you are doing those things, there is a certain amount of validity to the criticism that if it didn't work, you really weren't doing it right. Either something external jammed you up so you weren't able to adapt and truly follow agile, your team was personally unable to execute on the adaptation for some reason (structure, personality issues, experience levels, being simply too large to be able to be this flexible because large teams simply need more structure), or the task was simply too hard in the first place for some reason (such as "it doesn't matter how agile and smart the team is, you're not getting 4 people to produce a standards-compliant browser that is also an office suite in six months").
To me the single most common evidence of failure to perform "Agile in spirit" is management holding specific teams responsible for missing a deadline after a feature or due date was changed. It shows that the management doesn't understand software development. If you think you can add features or move delivery dates to the left without consequences, you've misjudged your entire industry.
Yeah, my former wannabe-boss was very surprised to realize that splitting the company in two and selling one part during my onboarding period might have a negative effect on my productivity.
We're not doing a very good job of picking the right people to manage things; quite the opposite, in many cases whatever success is despite the leadercrap we have to deal with.
As another commenter said, it’s difficult to compare “Agile in spirit”, but I’ve found that remarkably successful
Evolving the methodology to suit the team, product, and company in an additive way seems the best outcome I’ve seen.
Rarely will I have daily meetings, we can slack. Maybe twice a week hop on a call.
For story points I’ve seen models of using Fibonacci sequence, having 4 categories rated which then convert to points, or even (less desirable) 1:1 mapping to days of work. Personally I like the 4 categories approach, it feels less subjective as a whole despite each category being subjective to a degree
And in the end, if process gets in the way of productivity, I say go for it, we’ll either go back and document what happened or refine the process later (though rarely if ever have we skipped QA for good reason)
> Evolving the methodology to suit the team, product, and company in an additive way seems the best outcome I’ve seen.
This to me is the core of agile: the people doing the work have the flexibility to adjust to match their goals and needs. So much of the consultant-industrial complex comes down to finding ways to helping business people who aren’t willing to give flexibility or clear requirements ways to not do that which don’t sound like saying no.
The problem with "Agile in spirit" is that if adopt it and don't get the desired results, Agile aficionados will quickly remind you that you weren't actually doing Agile.
This is a common refrain, but I don’t think it’s true. “Agile in spirit” people will recognize the failure and look for ways to adapt so similar failures are less likely to occur. Rejecting that opportunity to reflect and adjust is where “not actually doing agile” comes into the discussion, and it doesn’t really have anything to do with “agile” at that point.
If you applied the same reasoning to any other iterative self-adjusting process, you’ll find they all tend to fail before the iterative aspect has been applied. Because that’s their nature, they’re iterative processes as a mechanism to respond to failure.
"Agile in doctrine" is the kind all of the anti-Agile crowd rail against because they've been burnt by working for some company or manager who drank the Koolaid without actually understanding what Agile is. Blindly following some consultant's Agile playbook is not Agile.
"Agile in spirit" is a bit like The Zen of Python: X is usually better than Y but there are times where it makes complete sense to do Y. In order for Agile to work, you need to have leaders and CIs who understand that. Agile emphasizes communication and flexibility. Agile is advisory, not prescriptive.