Should We Sing the Praises of Agile, or Bury It? (acm.org) 235
"Stakeholders must be included" throughout an agile project "to ensure the evolving deliverables meet their expectations," according to an article this week in Communications of the ACM.
But long-time Slashdot reader theodp complains it's a "gushing how-to-make-Agile-even-better opinion piece." Like other pieces by Agile advocates, it's long on accolades for Agile, but short on hard evidence justifying why exactly Agile project management "has emerged as a critical component for firms looking to improve project delivery speed and flexibility" and the use of Agile approaches is being expanded across other departments beyond software development. Indeed, among the three examples of success offered in the piece to "highlight the effectiveness of agile methods in navigating complex stakeholder dynamics and achieving project success" is Atlassian's use of agile practices to market and develop its products, many of which are coincidentally designed to support Agile practices and teams (including Jira). How meta.
Citing "recent studies," the piece concludes its call for stakeholder engagement by noting that "59% of organizations measure Agile success by customer or user satisfaction." But that is one of those metrics that can create perverse incentives. Empirical studies of user satisfaction and engagement have been published since the 1970's, and sadly one of the cruel lessons learned from them is that the easiest path to having satisfied users is to avoid working on difficult problems. Keep that in mind when you ponder why difficult user stories seem to languish forever in the Kanban and Scrum Board "Ice Box" column, while the "Complete" column is filled with low-hanging fruit. Sometimes success does come easy!
So, are you in the Agile-is-Heaven or Agile-is-Hell camp?
But long-time Slashdot reader theodp complains it's a "gushing how-to-make-Agile-even-better opinion piece." Like other pieces by Agile advocates, it's long on accolades for Agile, but short on hard evidence justifying why exactly Agile project management "has emerged as a critical component for firms looking to improve project delivery speed and flexibility" and the use of Agile approaches is being expanded across other departments beyond software development. Indeed, among the three examples of success offered in the piece to "highlight the effectiveness of agile methods in navigating complex stakeholder dynamics and achieving project success" is Atlassian's use of agile practices to market and develop its products, many of which are coincidentally designed to support Agile practices and teams (including Jira). How meta.
Citing "recent studies," the piece concludes its call for stakeholder engagement by noting that "59% of organizations measure Agile success by customer or user satisfaction." But that is one of those metrics that can create perverse incentives. Empirical studies of user satisfaction and engagement have been published since the 1970's, and sadly one of the cruel lessons learned from them is that the easiest path to having satisfied users is to avoid working on difficult problems. Keep that in mind when you ponder why difficult user stories seem to languish forever in the Kanban and Scrum Board "Ice Box" column, while the "Complete" column is filled with low-hanging fruit. Sometimes success does come easy!
So, are you in the Agile-is-Heaven or Agile-is-Hell camp?
Scrum. (Score:5, Interesting)
Ever played rugby?
A scrum is a bunch of sweaty men (well boys when I played) pushing in opposite directions, which often then collapses into utter chaos.
So really, the development methodology couldn't be more aptly named.
There's nothing wrong with agile per-se, it's an attempt to get small team dynamics working in a bigger environment. The problem is 99.999% of the time it's used by a management team that don't actually want to make any changes at all that in any way impact how they work.
The hope is that you can sprinkle the trappings of agile/scrum/kanban/whatever over a broken system and have it magically fixed without doing the hard work of saying to maybe even the boss's boss, "no we can't do that right now".
So it devolves into a bunch of daily standups where people panic and justify their jobs at increasing lengths, so called "sprints" with ever-tickets of the "do stuff" sort, or maybe none at all, except for all the "chase this squirrel" ones dropped in in the middle, obsession with MVP because the incantations say you need a working product, but that turns into grinding really hard to get something working then abandoning it because it's done.
And so on.
Share your horror stories below.
Re:Scrum. (Score:5, Funny)
Share your horror stories below.
One time a manager goes, "what's this waterfall thing? we should use that."
Re:Scrum. (Score:5, Insightful)
"There's nothing wrong with agile per-se..."
Oh yes there is. You are being far too kind.
"...it's an attempt to get small team dynamics working in a bigger environment."
No, it's not. That's perhaps a coincidental side effect. It would be more accurate to say that Agile rejects the values inherent in a bigger environment by rejecting any methodology that could benefit from them. Agile places no value on specialization, experience or infrastructure.
"So it devolves into..."
Yes it does, because while Agile claims it's about responsiveness to the client, which is rarely valued outside specific projects, in reality Agile is about making measurement of "performance" as easy as possible for managers, thus the inevitable "devolving" part.
Re:Scrum. (Score:5, Interesting)
I hate to go the "well you're not doing agile right, then", because I don't particularly want to defend it. I don't want to defend it at all!
But, there is actually the agile manifesto which isn't very long and has a number of nicely bulleted points. If you went down them one by one at my previous "agile" organization, it's like they'd almost used it as a checklist of what not to do. I've yet to work at a large organization claiming agility which has a reasonable approximation of even half of the things in there.
What remains to be seen is if it's actually possible to implement at a large organization.
I suspect that the main thing that's wrong with agile is that the structures of large organizations make it more or less impossible to implement.
Re: (Score:3)
99.999% of the time it's used by a management team that don't actually want to make any changes at all that in any way impact how they work.
Bad management can ruin any methodology or process.
Good management can successfully leverage most currently used methodologies.
To me, the biggest difference between waterfall and agile, is that waterfall is adversarial, agile is collaborative. There is a place for both types of project management.
If you're doing contract work for customers, you probably should go with the waterfall / adversarial approach, otherwise, the customer will keep dragging out the process to get more work for the same money.
If you'r
Re:Scrum. (Score:4, Insightful)
Agile is incredibly adversarial in the wrong management environment. Can very quickly devolve into the Spanish Inquisition the second a team starts missing "targets" or "commitments" for work that didn't get finished out in a given sprint / tranche / etc.
Re: (Score:2)
Of course. As I said, bad management can mess up any system. That same management would run a hostile workplace with waterfall too.
But one difference is, that agile, at its core, places people above process https://agilemanifesto.org/ [agilemanifesto.org]. So your scenario is arguably not...agile.
Re: (Score:2)
Don't women (girls) also play rugby these days?
Re:Scrum. (Score:5, Funny)
Re: (Score:3)
My experience over the last couple decades was Agile slammed onto an existing waterfall ecosystem netted only what I call
The Drunken Sailor scramble from one emergency to another
Re:Scrum. (Score:5, Interesting)
I can't improve on any of that. Of all the companies where I used Agile, not a single one did enough of it to give it a chance of working and were surprised when it didn't. The closest was a team at Microsoft where the Lead didn't know we were trying it informally.
When a process almost always fails and is always blamed by "experts" on not being executed perfectly, people should start to suspect something. Could it be that the easy way is actually too hard?
Agile, code patterns, "modern" C++, etc, all feel like they were invented to get tenure or kick start careers threatened by age or outsourcing, not actually improve anything. Dogbert would be proud.
Re: (Score:2)
"A scrummage, commonly known simply as a scrum, is a method of restarting play"
Actually well named. I've encountered sweating teammates during scrums occasionally, but that was their problem. And they started sweating after the stand-up, usually.
But Agile is a lot like systemd. Wrong solution to a contrived problem. Then again, waterfall was only used because it was all so much more difficult back then, to hear the elders talk about it.
Re: Scrum. (Score:2)
I've worked on a couple different teams using agile. Not one of them used scrum. You're conflating things.
Re: (Score:3)
There is something wrong with Agile per se... it's an additional layer of fluff and nonsense that provides no quantifiable benefit to engineering process while consuming significant time and energy. Anybody who has had the bad luck to experience agile in practice knows that engineers just do the bare minimum to satisfy management's delusions, and carry on doing their work just as they always have. Just slower and with greater stress.
Re:Scrum. (Score:5, Insightful)
Actually, there's one huge problem with agile, and it's not the developers or the project managers (bad ones can break any development methodology, good ones can make pretty much anything work - bending the rules if necessary).
It's the sales people. Agile is all too often sold as a way to avoid the requirements gathering and design stage. Customers (marks) love this idea because they don't really know what they want, haven't thought what they want, and once they actually have to face it, are exposed to the inherent contradictions of many of their requirements.
For small projects, agile is good, it doesn't actually save any time or any money but developers get something in front of the mark cheaply, the mark begins to understand what it is that they really want, and accepts that they've got to pay more to change it, and the solution can converge on something that is both possible and acceptable to all parties. (For smaller projects in particular, requirements gathering is hard to get right, take too much time and you've eaten into all of the profit that could have been made, but miss a key requirement and you're going to product something that isn't acceptable to the client)
But for big projects it's a disaster. On the biggest projects you can have a couple of years of development (especially when it's replacing an existing system) before any of the agile deliverables start getting tied into a deliverable that the client can properly assess and then the rest of the project becomes a desperate attempt not to have to throw away all of that work.
(I've never been closely enough involved with a SAP or Oracle ERP project to see how it's been sold or developed but the failing instances, of which I've seen many, have all the hallmarks of this - when it's announced it's going to replace existing processes with new, streamlined ones, when it finally goes live, years late, existing streamlined processes have to be changed to clunky awkward things so the data can be entered into the system in a way that the system will accept)
A perfect example of this is HMRCs MTD for IT project to replace the Self-Assessment tax return. It's long enough ago now that without going to look it up, I can't recall when it kicked off, but I think it was 2017. The latest "it will definitely go live" date is April 2026 (which is the start of the UK tax year) but there's just 30 people in the current pilot (and because of the way the UK tax system works, absolutely nobody who joins pilot for the 2025-26 tax year will be finalizing their tax affairs before it "goes live" so, except for those 30 - who by definition have the simplest affairs otherwise they weren't allowed to join - there will be nobody who has done an real-life end to end test)
Various figures have been bandied around about how much this project has cost so far, but 1-2 billion pounds sounds most likely.
It is how it is implemented... (Score:3)
It isn't really the methodology, as how it is implemented. For example, when your standup meetings devolve into finger pointing and people yelling at each other, "stop blocking me", and then demanding IT/Ops honor their pull request for code that was never tested, you get why people think that methodology doesn't work.
On the other hand, I've seen waterfall methodology work perfectly because a company wanted to do something right, not hire someone to act as a boatswain to yell at people and have tons of mee
Bury it on the pile of other failures. (Score:4, Funny)
Preferably at a location where the sun never shines.
https://www.agitma.nl/wp/wp-co... [agitma.nl]
Re: (Score:2)
Agile has some good aspects and some bad aspects. It works better in some environments than it does in other environments. And it can suffer from low competence or low buy-in from those attempting it.
People who have had a bad experience with it are going to hate it, and people who have had a good experience with it are going to like it.
So, there's my opinion of it. I won't distill it down to a single "good" or "bad" because that would be a silly oversimplification.
Re: (Score:2)
Agile has some good aspects and some bad aspects.
i agree. agile is a rich toolset with very good ideas. what definitely should be buried is the conception of it as a silver bullet, or more precisely its blind adoption by industry as a religious ritual with the sole purpose of providing plausible deniability and exemption of responsibility to management (all levels). that's just cancer. then again, industry will always be industry: they couldn't properly handle waterfall nor agile nor anything that comes after. they just have the wrong priorities.
Re:Bury it on the pile of other failures. (Score:5, Insightful)
Agile has the most impoverished toolset possible. It is precisely the opposite of a "rich toolset". I noticed you didn't give a single example, wonder why?
Re: (Score:3)
wonder why?
because they should come as obvious for anyone who has ever had a look at agile. here are a few, for ... you:
test driven development / / /
pair programming
early automation
functional breakdown
small iterations
viable product at all times
w. early/continued customer (product owner) involvement
-> transparency
for team growth:
retros / post mortem
these are quite potent tools (if used sensibly) for a "poor toolset methodology". it's no surprise if those are new to you because most implementations of agile just revo
Re: (Score:3, Insightful)
Everything on your list either existed prior to Agile and has nothing to do with it, is generally not possible (viable product at all times only works if you're doing something truly trivial), or is actually a negative most of the time (pair programming as a general usecase). Because I can promise you early automation, functional breakdown, transparency, and post mortems existed for decades before the idea even existed.
Re: (Score:2)
sorry but that's just a load of incorrect nonsense not worth discussing, maybe go read up a bit on the subject. your personal opinion on pair programming is nearly as uninteresting.
Re: (Score:3, Insightful)
It's a shitty "opinion" that says utterly nothing. It's maybe good or bad, maybe liked or disliked. Great insight.
Re: (Score:2)
In the real world, some things are multi-dimensional. They aren't simply "all good" or "all bad." They are a mix of both, with high sensitivity to context, application, and other details.
That really shouldn't be hard to understand. Agile is exactly in this boat. I have personally seen it work well in some environments, and also I believe the stories I have read about cases where it didn't work well. So the simple recognition that it is "a mix," without over-committing to an oversimplified judgment, is
I am in neither camp. (Score:3)
And when it comes to customer satisfaction: I am one of those guys who always marks 5 on a scale between 0 and 10.
Re: (Score:2)
I was gonna say that I'm in the "Agile is irrelevant to me" camp.
Re: I am in neither camp. (Score:2)
Agile drinking game (Score:2)
Finish your glass when a manager says:
"We need to be more Agile!"
Re: (Score:2)
prost!!! .... rlpssss! hic!
Bury it. Twice (Score:3)
Re: Bury it. Twice (Score:5, Insightful)
As a guy who spent 15+ years in Information Architecture, Experience Design and Interaction Design, I can confidently say: Agile is total crap for UI work. It hurries the parts that should be slowed way down, and fosters a "Ready, Fire, Aim" mentality.
'constantly be shipping' is at odds with study and analysis of the _actual_ problem to be solved, which is very often not the problem management wants solved.
Re: Bury it. Twice (Score:5, Insightful)
Half a person used to be able to design the GUI before web, why the fuck has it turned into rocket surgery under HTML/DOM/CSS?
One excuse is that it needs to work on a wide variety of screens and mobile, but most internal biz/admin apps in our shop are almost NEVER used on phones or tablets. Catering to blue moons is a bigass YAGNI Tax. Catering to mobile wastes screen real-estate anyhow for finger-spacing, requiring desktop user to scroll more. Nobody did a cost-benefit analysis, only a resume buzzword analysis, selfish bastards!
And it's a lie that WYSIWYG can't stretch to fit wider screens. "Stretch zones" are an invention that allows WYSIWYG GUI's to fit larger screens. The industry threw the WYSIWYG baby out with the bathwater, leaving us with whack-a-mole DOM/CSS shit. You whippersnappers fucked it all up; gittoff my lawn, you dirty fad-apes! We need a real GUI-over-https standard...
Re: Bury it. Twice (Score:5, Interesting)
Hmmm. Interesting take.
I spent most of my time without my head down in the pixels (where I have to say that separation of presentation from content, semantic structure of the page are positive salvations for findability, SEO, content reuse, ECM...not problems).
What was a much more effective use of my time was solving problems the company couldn't identify, by listening to the people that actually have to _use_ the site the developers create.
By interviewing, surveying, shoulder-surfing, various exercises, I could determine problems that a company's site was not instrumented to detect (for example the woman that started every support ticket by opening MS Word and typing it there, because our ticketing system would invariably crash before the ticket was submitted. With no ticket submitted, there was no record of the lady's support request NOR of the site crash). The company hadn't uh...instrumented MS Word...
Another example:
Manager wants to fix something he's convinced is dropping people out of his conversion funnel. He's got his mind set. But doesn't realize that people are dropping out possibly because:
or any of a thousand more things.
The work I excelled in was as much anthropology and psychology (these are for-instances; I'm not degreed in either field, and don't hold myself out a specialist in either of those) as it was technical. Given my bridge skillset, I was able to translate user findings into actionable things that could be fixed - but typically given little to no time to do so in agile teams, who were focused on delivery at the expense of doing things that made sense.
Good idea, bad execution (Score:3)
To me, the main problem with Agile was the meetings. Management hear 'communication' and think "constant meetings".
Communication can be a text message, not an hour long meeting for 10 people about a mistake that two interns made.
Great point (Score:3, Interesting)
Communication can be a text message, not an hour long meeting for 10 people about a mistake that two interns made.
When we have a production issue where I work that requires a hot patch, we have to have a meeting with about 12-15 people listing every single aspect of what went wrong in all departments across the company and then changes made to systems and processes to try and prevent it from happening again. Like you said, about an hour long.
But all of this could be done by one person writing up that detai
Re: Great point (Score:2)
"Agile" is a philosophy, and excessive meetings and too much process overhead is not consistent with it. The most popular agile framework, scrum, defines certain specific meetings (somewhat pompously called "ceremonies") and the one you described isn't one of them. So the problems you're having are not caused by anything to do with agile.
Re: Great point (Score:2)
That last word is important though. That meeting is supposed to be so short people don't mind standing up for the whole thing. If a team is having daily hour long status meetings (been there), that's a problem. There's nothing wrong with daily meetings if they're short (IMO).
Re: (Score:3)
Management hear 'communication' and think "constant meetings".
This is unfortunately true of many managers of all sorts. It might be one of the reasons so many people hate agile development*, but it's actually independent of agile.
* I can't say first-hand because I've never had to work in an agile shop.
It doesn't matter... (Score:3)
I understand why Agile/Scrum/et al is maligned, but the reality is the negative associatons will be had with any "methodology" for project management that acheives the "gold standard" status that Agile has.
The reason is simple, most folks will deal with a horribly mismanaged project and that project will pretty much certainly be managed in accordance with the set of "correct" buzzwords of the day, and that set of buzzwords is Agile.
Agile is a bit extra frustrating, as it presents folks reponsible for mismanagement an authority they can point to and say "oh, things are managed great, because we are aligned with Agile buzzwords and that alignment is agreed by everyone to be 'the' way to manage things, and if you doubt our superficial alignment to buzzwords, we paid a company to tell us we are good at agile and pay another company to use tools that are known to be Agile". So they can pat themselves on the back for being such good management even as things fall apart around them, and are even less ready to receive criticism than when they have no authority to latch onto.
The origins of Agile are reasonable enough, a relatively terse set of observations for things that frustrated a group of people. That sometimes project management loses sight of some factors while chasing other somewhat significant, but also distracting factors. The thing is those observations are extremely subjective, and the guidance to find the middle ground between opposing concerns is vague. So a whole mess of BS came out to try to be more specifically prescriptive. Unfortunately despite being more words and more headaches for folks, it can't get to be an objective set of guidance for generic work, because that is just fundamentally not a reasonable goal. So lots of effort is wasted chasing some formulaic magic to wave a wand to get good results with random quality of leadership and technical workforce.
The reality is that it's nuanced and affinity to authoritative buzzwords are anathema to fostering a functional organization. There's some vague things to keep in mind, but ultimately you can't determine some absolute measure of thosse things and people won't agree on their subjective assessment of those things. So keep them in mind, but getting in the weeds over them is pretty much exactly obsessing too much over "processes and tools" as warned about in the whole thing that started this all.
Re: It doesn't matter... (Score:2)
I think most people who hate agile development probably work in a dysfunctional organization where any process would be some combination of hellish and chaotic.
Ben Franklin (Score:2)
As Ben Franklin said about government, so goes most every group project:
anything is fine if well administered
That said, good administration / management is hard to come bye.
If everything you have is a hammer (Score:2)
Everything looks like a nail. Dogmas are never a good thing. If it says "one size fits all" it fits no one well. You can use a flat head screwdriver as a flathead screwdriver, but in a pinch as a torx, as a philips, as a chisel, and even aas a hammer, but that does not mean is the right tool for those uses...
Agile is not the only development metodology, and if you use it "for everything", well, you will have failures galore.
Waterfall, Agile, whatever - it doesn't matter (Score:5, Insightful)
And all of the methodologies I've ever seen are attempts to dodge a brutal reality: developing quality software is a hard, long, tedious, expensive process that requires smart, diligent, meticulous people.
And management doesn't want to hear that, so from time to time someone comes along with a new! better! faster! method that they promise will provide a way to duck that brutal reality. And there are books and papers and conferences and tutorials and certifications for it, and some people make a lot of money off it...and then...nothing changes. Not really. It turns out that this promised shortcut isn't actually a shortcut at all, and software continues to (mostly) suck, with occasional happy exceptions provided by the kind of people and the kind of process I described above.
This isn't going to change, because management will always look for a way around the problem, and thus they're susceptible to whatever trendy crap is peddled with sufficient sincerity and persistence. So if you think I'm wrong: wait 10 or 20 years. There will be another one, and there will be endless arguments over whether it's better than its predecessors will be all over the Internet.
It won't be. It'll just be another dodge, another trick, and another waste of time.
Re: (Score:2)
Mod parent up.
Re: (Score:2)
Stakeholder engagement is king.
If you have it, any methodology will succeed. If you don't, no methodology will save you.
Re: (Score:3)
This is all true, but Agile is suitable for managing web page development which, while some might argue differently, isn't really "software" in the sense you describe. Agile is optimized for ever-changing customer requirements where development is interchangeable and does not benefit from expertise. In other words, web sites.
Software development is entirely different and, like all engineering, is hard to do well. Agile not only doesn't help, it disrespects engineers..
Re: (Score:2)
So if you think I'm wrong: wait 10 or 20 years. There will be another one, and there will be endless arguments over whether it's better than its predecessors will be all over the Internet.
It won't be. It'll just be another dodge, another trick, and another waste of time.
It will come along in about 2 years, and it will be a melding of Agile (because there has to be some franwork, and that's still the silver bullet of the day) with a game-changing core component called "AI".
I can't wait to see what they call it.
Re: (Score:2)
So if you think I'm wrong: wait 10 or 20 years. There will be another one, and there will be endless arguments over whether it's better than its predecessors will be all over the Internet.
It won't be. It'll just be another dodge, another trick, and another waste of time.
It will come along in about 2 years, and it will be a melding of Agile (because there has to be some franwork, and that's still the silver bullet of the day) with a game-changing core component called "AI".
I can't wait to see what they call it.
AI-gile.
Hallucinate early and often.
Re: Waterfall, Agile, whatever - it doesn't matter (Score:2)
I don't think agile ever promised that getting to the finish line would be any faster, though some managers probably heard that anyway. What it's supposed to do is 1) make changing direction faster and 2) delivering something of value (but not the whole project) sooner. In some situations that could be valuable and in others not.
Re: (Score:2)
I'm pretty sure that over the decades I've sat in the exact same meetings with you in completely different companies. What you wrote is so true that it hurts, and the cycle just repeats endlessly.
Re:Waterfall, Agile, whatever - it doesn't matter (Score:5, Insightful)
Regardless of methodology, in most markets there is a direct economic incentive to release low-quality software: it has the highest profit margin!
Put simply: if I spend a whole lot of time developing software to be very high in quality, very polished, nearly bug-free, then I will find very few buyers. Why? For starters, all that upfront effort takes time. While I am busy perfecting everything, my competitors are out there selling barely-works crap to whoever will buy. In many markets they rope their clients into long-term contracts. So they simply aren't shopping for replacements any more, by the time mine is ready.
Furthermore, the ongoing maintenance of high-quality software also costs money. A premium, if the quality is to remain high. Most clients are content with buggy software so long as it mostly works most of the time, and saves them a bundle. So, very few clients want to buy my software because it is so expensive.
It's true, there is a good reason why mine is expensive. But they don't care. The uglier, slower, buggier option saves them a fortune and gets them rolling on their business venture to make their money.
So, my business flops due to overspending on quality. The successful business is the one who does not aim for excellent quality, but aims for just slightly above the bare minimum, and then puts a shiny coat of paint on it. Their software will be the cause of endless headaches for years to come, but it will also make a whole lot of money.
The worst part is that all that front-loading of costs make investors real twitchy. It is risky to invest a whole lot into something, especially if the market is in any way new. Getting something cheap out there fast is the quickest way to learn what the market actually wants, so you can adapt your design right away. The risk of having a very elaborate design that turns out to be just a bit off-target, and therefor is bought by no one, makes investors turn tail and run.
For example: the Apple Vision Pro. Its the most advanced AR/VR headset on the market, it does things the others don't do, and nobody wants it. The much cheaper much less functional Meta Quest is selling like hotcakes by comparison.
With this truth in play, the methodology chosen is secondary. Agile, kanban, waterfall, USDP, lean, extreme, it doesn't matter which one is chosen, because leadership has already chosen to use it to produce something barely functional, but sellable.
Re: (Score:2)
Exactly.
Software is hard. The only real benefit of agile is that it does seek to regularly engage the end user community and greatly benefits in the play space by keeping developers from spending ooodles of time on something that nobody wants. Both because I want to build something but nobody else wants me to build that thing, but also because half the time the user doesn't actually really understand what it is they want.
When requirements are poor, product is poor.
Sure, you COULD have perfect requirements
Fragile (Score:2)
It's a way for managers to justify their existence. If they don't communicate progress/results daily, their bosses may realise that they don't need that many managers.
Cherry pick agile (Score:3)
Re: (Score:3)
Absolutely. Religious adherents of any methodology, are hell to work with. Take the pieces of agile or waterfall that work with *your* team and go with it. But of course, that approach requires people to think, and that's often a skill in short supply.
Re: (Score:2)
Your first problem is 'agile' often means different things to different people. I think it is best when you cherry pick ideas from agile that actually work for your team and ignore the rest.
Bingo, I've used test driven development and incremental development ever since I was taught agile methods. Some other elements of agile work, while other pieces don't, but these in particular have really helped my software development.
Re: (Score:3)
Mod parent up. The only official certificate I ever had to acquire (over a 50-year software developer career) was that of an Agile Practitioner. "Agile" is a collection of about 8 different methodologies for getting work done. There is no such thing as "agile", singular.
So, you absolutely need to pick out the things that work for your team and your business, and leave the rest on the floor. Here are the elements nearly all the dev teams I worked on used:
- Deliver working code incrementally
- Do daily stand-u
Management Philosophies (Score:4, Insightful)
If it has a name, it is almost guaranteed to be awful at large scale.
Show me the definition! (Score:5, Interesting)
For years I've asked for a definition of "agile" sufficient that an objective evaluator (manager, QA, contracts official, etc) could use to determine "Are we doing 'agile' or something else?" The most common response was "If it's not working, it's not agile." (Which, of course begs the interpretation "If it's not agile, it can't work.") When Agile started showing up in formal ISO standards without a single normative and rigorous definition, I came to the conclusion "It's just marketing." No one could explain to me how you'd do something that is infrastructure-intensive, rather than user-function intensive (and the example I used was "Can you use agile to build a DBMS? How would 'agile' address things like performance and concurrency, critical under-the-covers characteristics that don't lend themselves to "a couple weeks build cycle?") But of course no one, particularly no manager, wants to say "We're NOT agile."
So it's long past time to bury this in the dungheap of hype, and hope that toxic waste doesn't leach out from that landfill.
Re: (Score:2)
Its been decades and I still have not seen a definition for "Agile"
Its power always lay in a distinct -LACK- of definition, so that consultants could always tout is as the all-purpose magic solution for whatever problem was at hand.
Also see: Blockchain, Cloud, Microservices, etc
Re: (Score:2)
Blockchain: a long string of numbers that supposedly no one can secretly alter
(Yeah, I don't believe it either)
Re: Show me the definition! (Score:3)
Agile is a philosophy, not a procedure. I have to wonder how hard you actually looked if you didn't find the manifesto.
https://agilemanifesto.org/ [agilemanifesto.org]
Re: (Score:2)
l've read the "manifesto". It doesn't help me resolve the question "Are they doing Agile, or something else?"
Re: Show me the definition! (Score:3)
It sounds like you're still thinking of agile as a process. It isn't. So nobody is "doing" agile, but what they are doing might or might be consistent with the agile approach. If you want to know whether it is, look through the 12 principles and evaluate whether that organization's practices are consistent with them.
Re: (Score:3, Informative)
"Agile" is merely a collection of methodologies for getting work done. There is no, one methodology that is "agile". You need to find the particular set of methodologies that work for your team and business, and use only those. None of the rest of the ideas are suitable.
Just as a small example, under the "agile" umbrella there are methods for speeding up a known process and reducing errors. None of those methods are going to help you if you don't know what you're building in advance, obviously.
An afternoon
Quote... (Score:2)
Adapting a famous quote, "Agile is the worst form of project management, except for everything else that has ever been tried."
Use it if and when it works well (Score:3)
Too many are either dogmatically religiously in favour of Agile, praising its strengths, and insisting it is always used; or else dogmatically religiously against Agile, berating its flaws, and insisting that it never be used.
I'm of the view that sometimes it works well, and sometimes it doesn't, and what we want to know is how to decide which is which, and why, and to decide in an efficient and reliable way.
You need to fend off the customers some times (Score:2)
Shoot it (Score:2)
Take it out back and put a bullet in it's head. Agile has created half of the problems we have today with games and other software. Developers are told to get a minimally viable product out the door and bugs can be fixed afterwards. I believe the term associated to this is move fast, fail fast. A previous co-worker used to joke by putting a [fr] in front of agile, because it's really fragile.
Recently certified (Score:2)
Our corporate IT division pushes these new "systems" every 7-10 years, always start out strong and fade within a few years.
I can see Agile having its place but it's not some savior. We're wasting resources trying to get shove a square peg in a round hole.
Or? (Score:2)
What's your alternative? Waterfall?
I mean - I guess there are some things taht waterfall is appropriate for. I'm not sure what those are - but I suppose there is something.
I guess I think most software management issues are exactly that: management issues.
Re: (Score:2)
What's your alternative? Waterfall?
I mean - I guess there are some things taht waterfall is appropriate for. I'm not sure what those are - but I suppose there is something.
anything where requirements are precisely knowable in advance. that's quite a lot, actually, a huge majority of generalist business software. but it does take effort and compromise to nail those down, and discipline and commitment to work them out. applying agile to that is just escapism, and i you have a collective who indulges in escapsim agile won't do it either.
agile (*some* agile techniques applied judiciously) would excel where goals are vage or unknown or complexity is just too big to address. that's
Re: (Score:2)
I guess it's been my experience that software requirements are virtually never well known. Most people that want software written don't know what they want, why they want it, or what software can actually do (or not do) [easily]. Most "well specified" software I've been asked to write ends up with software that nobody actually wants, needs, or is willing to use. But if you work with folks to discover what problems they need to solve you can get to writing software that will make their jobs easier or way
Re: (Score:3)
Like many formalized dogmas, agile starts with some good ideas and then turns them into an inflexible religion. Continuous refactoring? Great idea. Automated testing? Definitely. Being flexible in the face of changing requirements? Of course.
But then it builds a rigid, inflexible "methodology" around them. Everything must be done through exactly this set of meetings with this set of documents that are created in this way, whether it's appropriate or not. Plus some crazy ideas mixed in, like that you
Re: (Score:2)
Software Engineers know that design starts far before coding, including not just choosing the right tools from a wide array of available ones, but
Buzzword Bingo (Score:5, Insightful)
I was immediately put off by one of my least-favourite PR-speak words, namely "stakeholders". Nonetheless, I screwed up my courage to the sticking point and waded into TFA. It's been a while since I last encountered this much amorphous buzzword bullshit in one place:
"critical component" (doesn't refer to hardware or software)
"complicates stakeholder participation"
"necessitates continuous cooperation"
"stakeholders must be included"
"evolving deliverables"
"broader corporate goals"
The gobbledegook listed above is all in the first paragraph! The second paragraph contains such gems as:
"novel strategies"
"stakeholder mapping"
"actionable ideas"
"reinforce the value"
I simply couldn't read any more. Trying to parse this dreck was like wading through an ever-thickening sea of non-specificity toward an ever-receding illusion of relevance and meaning. Do the people who write shit like this honestly believe that they're saying something?
Subject-Object agreement on grammatical person (Score:2)
I use terms of art.
You use jargon.
They use buzzwords.
Re: (Score:2)
Crowdstrike. (Score:2)
Do proper testing or GTFO.
Agile is 'fine', its not whats broken in SW DEV (Score:2)
I've seen "good agile" and I've seen agile twisted into a hellscape of management torture. As an organization tool, agile is 'fine' - but it doesn't solve for a broken organization. If you can't or won't manage expectations, if you can't or won't prioritize, and especially if you can't or won't do real product design, then nothing is going to solve for that. When you have management evaluations being done on checkin count or LOC metrics, then there's nothing really agile will do to save you. When your p
Re: (Score:2)
"If you can't or won't manage expectations, if you can't or won't prioritize, and especially if you can't or won't do real product design, then nothing is going to solve for that."
Amen.
I never used it, but... (Score:2)
...the original Agile manifesto seemed to make great sense and described a process very much like the one I came up with on my own.
From what I've read, the idea was mutated by consultants and managers into a horrible form that is hated by those who are forced to use it
Re: (Score:2)
This is the entire problem.
The manifesto remains correct. The theatrics which have been built around the *name* "Agile" are largely insanity.
I once saw it said that the only reliable way to know how long it will take to build a piece of software is to build it and then report how long it takes. This is a hard pill for people who are paying for software to be written to swallow, because they very reasonably want to know that the results will arrive on time and that they're getting something for their money d
It worked once (Score:3)
The smartest guy at the agile conference (Score:3)
Re: (Score:2)
That's a much better name.
Mad Men Explained Why Agile is Terrible Years Ago (Score:2)
Agile's core problem is that because it attempts to include everyone and all scenarios, it inevitably becomes this mess of buzzwords and frustration. You hear "well that's just because you're doing it wrong" not because it's so hard, but because it's designed that way at its core.
There's this line really early in Mad Men, I forget how it goes exactly. But Peggy has both had a big win with her client that she's thrilled about, but finds she feels really unhappy about it too. Don says something to her like "y
It's just good project management (Score:2)
It's like any other tool (Score:2)
Mediocrity (Score:2)
Agile seems like an OK way to keep a mediocre project on track with a mediocre team.
Perhaps the best.
The trouble comes when you are trying to make an insanely great product with an insanely great team and try to force Agile on them.
And I don't mean a great team - special people need to be managed differently and they often don't fit the mold of 'normal people'.
I happen to be friends with a guy who managed the Unix team at Bell Labs. He saw his job as running interference with management and getting the gen
Simplify it (Score:2)
I've only seen one methodology work in any line of work, and that's setting and sticking to priorities.
Sure, sometimes something unexpected can shift a priority but it's not the norm.
Toyota is an excellent case study (Score:2)
They invented Kanban, and they are known for building high quality vehicles and for being a well-run company. So whatever you might think of agile methodologies, they certainly can work, and may even contribute to a company's success.
What's the alternative? (Score:2)
I suppose "waterfall" is the obvious answer. Really? This is what we will hold up as being "better"?
Some of us are old enough to remember when waterfall didn't have a name, but it was considered the only way to develop software. At the time, I observed that teams that were successful, were doing incremental development below the surface. So when Scrum went viral, I was ready to jump on the bandwagon. I've never looked back.
The human side of process (Score:2)
The biggest thing that hurt waterfall, is that adherents to the methodology forgot that people are human. They tried to build a perfect framework for success, dotting all the i's and crossing all the t's, doing everything in the correct order. But no waterfall project ever achieved this ideal. Expensive change requests after completion, are the norm.
Agile puts people first. It assumes that people are unable to think of everything up front, and reduces the friction of making adjustments mid-stream.
Sure, in a
Whose stand-up is it anyway? (Score:2)
Welcome to Whose Stand-up Is It Anyway - a show where everything's made up and points don't matter.
The myth of self-organising teams (Score:3)
Reportedly, Agile is all about self-organising teams who are given the autonomy to decide how they work and how they deliver objectives. Now, you tell me - have you ever been in an Agile team that has that quality? In my experience, the more Agile the team is, the more restrictions and dictatorship is imposed on the team by product managers and scrum masters (who often are also product managers). It's all an illusion for yet another apparatus of control in the name of dreamt-up productivity.
Agile for all (Score:4, Funny)
I enthusiastically support agile and encourage our competitors to adopt it fully.
It gives managers numbers (Score:3)
Re: (Score:2)
Yes, this.