If a framework claims to solve a human resources problem, than then turns to be ridiculously susceptible to human resources misusing it, then that framework is not of much use is it.
back
2 comments
Everything is susceptible to being co-opted when it becomes popular, and sometimes even when it doesn't. Any religion, any political platform, any protest movement, anything with any kind of a group identity can be misused by those who want to have that identity without having to actually meet the qualifications. Expecting a one-page statement of a development philosophy to not be susceptible to that is expecting the impossible.
Agile at least pointed out that the way development was being done was inhumane. That resonated with a large number of people. People wanted that more humane development style - that's why agile had so much appeal.
Calling agile a "framework" seems off, though. It was a philosophy, or perhaps a set of values. A framework is something more codified and rigid - which is exactly the problem, that people tried to make agile codified and rigid. "We're going to be agile according to a rigidly defined process" is an oxymoron.
But not being a framework, not being rigidly defined, there was nothing formal that stopped anyone from putting the "Agile" label on things that were antithetical to the Agile Manifesto. But they are in fact antithetical - it's like the practitioners never actually understood the manifesto, or else were never willing to actually change to correspond to what it said.
I think we agree. My point would be that any framework which calls for or normalizes imposter roles is going to stifle productive output.
The Agile manifesto clearly does that.
https://agilemanifesto.org/principles.html
> Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
This basically normalizes product managers being incompetent. Anyone can jerk the engineers around and be reactive. It takes expertise to not waste resources on the wrong thing.
> Business people and developers must work together daily throughout the project.
We know this is bad for engineering output empirically. You need to leave people alone to get work done. But giving the "business people" something to do legitimizes their imposter roles. Better check in on the engineers every day.
> The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Imposters are adept at feigning value creation in meetings. Ask for details in writing: no shot. In a meeting, where they can nod along with people who actually know what they are doing, is where imposters really shine. Also another work activity to legitimize the imposter role.
Well, you know, engineers are famous for "can't code their way out of a wet paper bag" even though they sounded great in an interview. That's what FizzBuzz is for - to find out quickly if candidates can code at all. So it's not like imposters are only in non-technical roles.
> > Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
> This basically normalizes product managers being incompetent.
No, it normalizes product managers doing their jobs. If external circumstances change, do you want to keep building the wrong thing, or do you want to respond? Agile is all about responding when things change. But you need a product manager who is competent to do the right changes, and only those, rather than changing with every morning headline.
But if you're not doing agile, you still have the same problem. If your product manager isn't competent to steer the delivery as circumstances change, how are they competent to get the requirements correct enough that they won't need to change for a year-long project? Answer: They aren't. (But agile may make their incompetence more frustrating day-to-day to the engineers, instead of letting them enjoy the sense of accomplishment of happily building something to completion, even though it's the wrong something.)