I generally agree, but with the caveat that you are more speaking to "Agile" and agile project management (eg: Scrum).
To that extent, I find it really useful to draw a distinction between agile development and agile project management. The former I think has some good ideas, namely :
- don't go off into a cave for days, weeks or even many months before merging or showing any work; show & release your work often.
- ask users frequently: "here this is, what do you think?"
- assume you are probably on the wrong track, a good way to get back on track is to talk to the users. The more often you talk to users, the less likely you are to spend time on the wrong track
- deliver in small increments. Gall's law - don't do big-bang deliver-the-world style projects, they often fail.
On the other hand, agile project management (IMO) is almost trivial when agile development is done well and should not be prescriptive. If someone is building a tool for someone sitting next to them, does it make sense to do a demo every two weeks? I find what's more that Scrum is not even coherent, it's not internally consistent with itself. It's ironic as Scrum says nothing about going "fast", yet it's all about "fast" development - and second a framework that says "we will be changing our mind every two weeks" is somehow supposed to be more predictable and a better fit for long-range project timelines??
ON THE OTHER HAND... in the defense of Scrum, having a framework to prioritize work and emphasize delivery can still be valuable. Dev's can have a tendency to only want to work on cleaning up code. It can be a bit like Starcraft, where a player spends too long building economy and workers and never actually builds the army that wins the game. Though, frameworks have a bit too often become shorthand for actual thought, too much cargo-culting.
Agile is fundamentally a "UI convergence" technique. It is perfect for interacting visually and conceptualizing requirements (and the realization of those requirements) with end users and other stakeholders.
I'm not saying waterfall is the only alternative. But one week sprints is a dumb idea for any serious software development.
The other thing Agile does is give too much priority to outside concerns. Like pulling people off to do some thing the support team should fundamentally own, or meetings, support tickets that get too high prioritization because agile gives them too much prioritization.
Sometimes you have to sit in an office undisturbed. To Agile people, that's the worst thing ever, but fundamentally everything truly significant in software stemmed from that.
Interesting: > I'm not saying waterfall is the only alternative. But one week sprints is a dumb idea for any serious software development.
I just proposed to our team we move from 3 week sprints to 1 week. It's working out far better already. In part it's already waterfall done as sprints, so the duration is not as bad, but it's helping my boss stay a lot more focused on delivering and keeping in mind WIP limits.
I do draw a distinction on "Agile" between 'agile development' and 'agile project management'. Unqualified, I would assume "Agile" to mean "agile project management", in which case IMHO it's mostly garbage. The interesting stuff is 'agile development' IMO, the project management is context dependent and would tend to flow readily from a development project where:
- developers focus on releasing early & often
- developers are speaking directly to customers frequently
- customers/users are interacting with the software as it is being built and are providing feedback along the way
> Sometimes you have to sit in an office undisturbed. To Agile people, that's the worst thing ever, but fundamentally everything truly significant in software stemmed from that.
I would tend to agree. My impression is generic IT management, or business & project management stems from just the 1920s & has evolved only so much. There's a lot of emphasis on predictability, removing variation, reducing risk and maximizing utilization. (eg: Gantt [1], and there is someone else whose name I can't think of around the same time that was also as foundational). For the context in which that management was created, in part it's fine (ableit de-humanizing) - but for an industry that is more akin to a story writer than a factory worker - it's not really fine.
To that extent, I find it really useful to draw a distinction between agile development and agile project management. The former I think has some good ideas, namely :
- don't go off into a cave for days, weeks or even many months before merging or showing any work; show & release your work often.
- ask users frequently: "here this is, what do you think?"
- assume you are probably on the wrong track, a good way to get back on track is to talk to the users. The more often you talk to users, the less likely you are to spend time on the wrong track
- deliver in small increments. Gall's law - don't do big-bang deliver-the-world style projects, they often fail.
On the other hand, agile project management (IMO) is almost trivial when agile development is done well and should not be prescriptive. If someone is building a tool for someone sitting next to them, does it make sense to do a demo every two weeks? I find what's more that Scrum is not even coherent, it's not internally consistent with itself. It's ironic as Scrum says nothing about going "fast", yet it's all about "fast" development - and second a framework that says "we will be changing our mind every two weeks" is somehow supposed to be more predictable and a better fit for long-range project timelines??
ON THE OTHER HAND... in the defense of Scrum, having a framework to prioritize work and emphasize delivery can still be valuable. Dev's can have a tendency to only want to work on cleaning up code. It can be a bit like Starcraft, where a player spends too long building economy and workers and never actually builds the army that wins the game. Though, frameworks have a bit too often become shorthand for actual thought, too much cargo-culting.
[edits: cut out some ranting]