16
votes
The sins committed in the name of Agile development
Link information
This data is scraped automatically and may be incorrect.
- Title
- Agile software promises efficiency. It requires a cultural shift to get right
- Published
- Feb 29 2024
- Word count
- 2037 words
I'm really getting tired of the recent trend of crapping on Agile. If you don't like it fine, don't use it. At my last company, the teething pains of agile implementation weren't fun, but after roughly 6 months we got in a really great groove and I learned to love Agile. If it fits your organization and team, use it. If it doesn't, then use Kanban or something else and shutup.
Kanban is a form of agile I do believe. An alternative agile sub-methodology to scrum. My personal favorite flavour of agile.
I think part of it is the proselytizing of Agile has caused organizations to force adoption of it where it doesn't fit...and that results in all sorts of bad rebranding and implementations.
My personal opinion is that Agile works best when the objectives are a continual moving target. If the overall goal of a thing is well-defined, it is not.
The project I'm working on now is spending very much time in the early architecture phases, in part because it's replacing multiple decade's worth of piecemeal development.
The end product will be deployed piecemeal, as its done, rather than "build then ship" ala waterfall development. But there is a lot of architectural planning done in the early phases to address the primary shortcomings of the existing system. Namely, hammering down the exact nature of how data flows, the data model it will follow, and where the massaging of the data takes place. Over the course of several months (side project right now), we've basically thrown away and redesigned it 4+ times in ways that would have just resulted in throwing away a lot of code if we hit the ground running.
In the original system, those grew organically as the requirements came up....and it's an unmaintainable mess as it gets passed from generation to generation and the institutional knowledge that made it workable slowly erodes away.
Agreed! The worst part about “modern agile” methods is its top-down implementation by management on orgs or in projects where it doesn’t fit at all, and arguably where engineers don’t have much of a say in quite a few things as a whole. So there’s (perhaps good?) reason for them to bash it like this.
That’s not to say there aren’t valid criticisms, just a recurring thing I’ve noticed (from an outsider perspective, hearing from friends and colleagues where it was forced upon development).
Yeah this is the real issue. Not just using it where it doesn't make sense, but also ignoring the parts that someone doesn't like, even when they're important. Like many business trends, it works well for a few, but then everyone tries to shoehorn it in while still keeping to management or whoevers whims and you get these franken systems.
I think the reason you see so much of this is that for a huge majority of people, Agile (and usually specifically a bastardized version of Scrum) are declared from on-high and individual teams don't have any say in the matter. Process fit be damned.
Add to that that management often doesn't actually respect the parts of Scrum they don't like, so it often ends up a complete mess, and there's a lot of resentment and frustration. That's the root cause of the complaints from my experience.
The complaints stem from companies forcing developers to "use Agile" top down, but they implement a completely broken facade that has nothing to do with the actual Agile principles and end up creating a disastrous process that doesn't help anybody except for giving middle management the appearance of hard data to present to their managers, meanwhile the feedback coming from experienced developers is generally ignored.
It’s a confusing article. It starts out with what seems like a laundry list of complaints about the incorrect implementation of agile but then pivots to essentially saying that agile isn’t suited for large customer facing projects in the first place.
Sounds like a pretty agile article.
I don't see that pivot at all. The message is, "Make sure that people understand what they're doing and focus on communication."