Should We Sing the Praises of Agile, or Bury It? (acm.org) 81
"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: (Score:3)
Share your horror stories below.
One time a manager goes, "what's this waterfall thing? we should use that."
Re:Scrum. (Score:4, 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: (Score:2)
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: (Score:2)
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)
Don't women (girls) also play rugby these days?
Bury it on the pile of other failures. (Score:3)
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:4, 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:2)
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)
It's a shitty "opinion" that says utterly nothing. It's maybe good or bad, maybe liked or disliked. Great insight.
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:2)
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.
Good idea, bad execution (Score:2)
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:1)
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: (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:2)
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: (Score:2)
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 cli
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:2)
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.
Management Philosophies (Score:3)
If it has a name, it is almost guaranteed to be awful at large scale.
Show me the definition! (Score:4, 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:2)
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]
Shakespeare (Score:1)
If the headline is trying to evoke Mark Antony's speech in Julius Caesar Act III Scene II, the TFS missed the obvious: "For the stakeholder is an honourable person. So are they all, all honourable people"...
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:2)
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.
Meh (Score:1)
Anything good about isn't unique to "agile".
And anything bad about it is just magical proof that you are doing it wrong (according to Agile advocates).
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:2)
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?
Re: Buzzword Bingo (Score:2)
Speaking of misusing terms, both of those uses of "effect" should be "affect".
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
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:2)
Agile is the worst software methodology ... (Score:1)
... except for all of the others.
(Apologies to Churchill)
Re: (Score:2)
Yes, this.
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.