The End of Agile
August 23, 2019 7:12 PM Subscribe
I knew the end of Agile was coming when we started using hockey sticks. Every morning, at precisely eight o'clock, the team of developers and architects would stand around a room paneled in white boards and would begin passing around a toy hockey stick. When you received the hockey stick, you were supposed to launch into the litany: Forgive Father, for I have sinned. I only wrote two modules yesterday, for it was a day of meetings and fasting, and I had a dependency upon Joe, who's out sick this week with pneumonia.
Agile was only ever a zillion tiny waterfalls anyway.
posted by rhizome at 7:39 PM on August 23, 2019 [38 favorites]
posted by rhizome at 7:39 PM on August 23, 2019 [38 favorites]
This article is way more nuanced than the title would suggest.
(ctrl-f “Goodhart’s Law”)
posted by q*ben at 7:40 PM on August 23, 2019 [6 favorites]
(ctrl-f “Goodhart’s Law”)
posted by q*ben at 7:40 PM on August 23, 2019 [6 favorites]
I work quasi-agile for enterprise software projects. We have mixed projects, some with 2 week iterations and some with 3 weeks, I’ve really not noticed 3 is better than 2. We don’t have real customers so we don’t do true demos- clients don’t care about back end processing. He is totally correct about client disengagement.
I don’t get the point he made about short-timer code. It existed in the waterfall world too. Nor about scaling - I’ve not really noticed any better or worse scaling there either.
I say quasi-agile because I totally agree that the ceremonies can take over and that the time spent doing detailed estimating is also mostly wasted.
posted by The_Vegetables at 7:45 PM on August 23, 2019 [5 favorites]
I don’t get the point he made about short-timer code. It existed in the waterfall world too. Nor about scaling - I’ve not really noticed any better or worse scaling there either.
I say quasi-agile because I totally agree that the ceremonies can take over and that the time spent doing detailed estimating is also mostly wasted.
posted by The_Vegetables at 7:45 PM on August 23, 2019 [5 favorites]
Every morning, at precisely eight o'clock
Bold choice. Most of the technical teams I've been on would have just murdered the scrum master and made a grim scarecrow out of their flayed skin as a warning to others, who might think that a standing meeting at the unholy hour of 8AM was appropriate.
posted by Kadin2048 at 7:52 PM on August 23, 2019 [90 favorites]
Bold choice. Most of the technical teams I've been on would have just murdered the scrum master and made a grim scarecrow out of their flayed skin as a warning to others, who might think that a standing meeting at the unholy hour of 8AM was appropriate.
posted by Kadin2048 at 7:52 PM on August 23, 2019 [90 favorites]
There is a fallacy in computer programming circles that all applications are ultimately decomposable - that is to say, you can break down complex applications into many more simple ones.
QFT. There is no system too complex, too thick with years of subtle tweaks and undocumented business decisions that cannot be converted to microservices in three months by developers with The One True Way on their side.
posted by grumpybear69 at 7:53 PM on August 23, 2019 [31 favorites]
QFT. There is no system too complex, too thick with years of subtle tweaks and undocumented business decisions that cannot be converted to microservices in three months by developers with The One True Way on their side.
posted by grumpybear69 at 7:53 PM on August 23, 2019 [31 favorites]
If agile isn't working "then you're just doing it wrong" is my favourite.
posted by greenhornet at 7:56 PM on August 23, 2019 [14 favorites]
posted by greenhornet at 7:56 PM on August 23, 2019 [14 favorites]
If agile isn't working "then you're just doing it wrong" is my favourite.
Well, it's true, if unhelpful. The problem is that organizations think Agile is a software development methodology. It's not. It's an organizational methodology.
I'm working on a project with a team of three other developers, and this year, we've been reimplementing the functionality of a 30-year-old core system running on a mainframe. 95% of what that system does hasn't been touched, but we've been delivering great stuff every two weeks, and are on track to sell it to our first internal customer.
The main reason?
We're an outside group that has patiently but diligently worked to isolate ourselves from the overall organization and have worked in an agile fashion to always be focused on the most important undone capability.
It's not easy, but it's possible, and it works.
posted by Ickster at 8:01 PM on August 23, 2019 [23 favorites]
Well, it's true, if unhelpful. The problem is that organizations think Agile is a software development methodology. It's not. It's an organizational methodology.
I'm working on a project with a team of three other developers, and this year, we've been reimplementing the functionality of a 30-year-old core system running on a mainframe. 95% of what that system does hasn't been touched, but we've been delivering great stuff every two weeks, and are on track to sell it to our first internal customer.
The main reason?
We're an outside group that has patiently but diligently worked to isolate ourselves from the overall organization and have worked in an agile fashion to always be focused on the most important undone capability.
It's not easy, but it's possible, and it works.
posted by Ickster at 8:01 PM on August 23, 2019 [23 favorites]
Scrum is only one type of "agile" and even that is debatable if you want to get pedantic about "real agile" being the thing described in the Agile Manifesto. Which by the way is what people mean when they say "then you're doing it wrong", there are many different systems of management fighting over the "agile" brand.
I'm very happy to see a lot of press in the last week about the fact that the certified scrum master, professional agile coach, PM-and-not-dev-driven approach is being recognized as the disaster it is before more failed projects pile up.
I don't care what you call it, but it is perfectly possible to manage a project in a very self-organized way along the lines of the extreme programming stuff or the agile manifesto stuff (which are about communication and organization, not ticket ceremonies) and be in a much better place than the standard scrum approach. I've done both many times in the last 15 or so years, the differences are stark.
posted by Infracanophile at 8:04 PM on August 23, 2019 [7 favorites]
I'm very happy to see a lot of press in the last week about the fact that the certified scrum master, professional agile coach, PM-and-not-dev-driven approach is being recognized as the disaster it is before more failed projects pile up.
I don't care what you call it, but it is perfectly possible to manage a project in a very self-organized way along the lines of the extreme programming stuff or the agile manifesto stuff (which are about communication and organization, not ticket ceremonies) and be in a much better place than the standard scrum approach. I've done both many times in the last 15 or so years, the differences are stark.
posted by Infracanophile at 8:04 PM on August 23, 2019 [7 favorites]
As an aside, we've gently put our client-supplied scrum master on an island. He doesn't know it, and our stakeholders don't fully realize it, but we do our backlog grooming and sprint planning on a rolling basis throughout our sprint. When we get to his ceremonial meetings, we usually take about 5 minutes to review what we already have moved into our next sprint and let everyone else have 55 minutes back.
posted by Ickster at 8:04 PM on August 23, 2019 [23 favorites]
posted by Ickster at 8:04 PM on August 23, 2019 [23 favorites]
Surely you all could be making merge requests right now instead of hanging out on the blue. /productmanager
posted by turbowombat at 8:10 PM on August 23, 2019 [18 favorites]
posted by turbowombat at 8:10 PM on August 23, 2019 [18 favorites]
What if One Weird Trick can't substitute for the cultivation of Virtue, even if some of the different Weird Tricks could be fruitfully used by the Virtuous?
posted by save alive nothing that breatheth at 8:14 PM on August 23, 2019 [18 favorites]
posted by save alive nothing that breatheth at 8:14 PM on August 23, 2019 [18 favorites]
Surely you all could be making merge requests right now instead of hanging out on the blue.
Well, a few minutes ago, I was investigating whether a KieScanner would take a URL as the location of a Maven settings file for Drools reloading. I'm going to test that, and if it doesn't work, I'll have to look at other approaches.
Other than that, no blockers.
posted by Ickster at 8:16 PM on August 23, 2019 [15 favorites]
Well, a few minutes ago, I was investigating whether a KieScanner would take a URL as the location of a Maven settings file for Drools reloading. I'm going to test that, and if it doesn't work, I'll have to look at other approaches.
Other than that, no blockers.
posted by Ickster at 8:16 PM on August 23, 2019 [15 favorites]
There is a whole lot of hand-waving at the end of that article. "We have Unity, so we don't need Agile." HUH? "Mobile apps are just shells of HTML and CSS, unlike REAL apps." Anybody who says HTML and CSS are "just" anything is getting to classic 10x engineer "I don't do communication and front end is for children, no I don't know what semantic HTML means and CSS confuses and frightens me" territory and I am sick to death of it.
Building things with a lot of moving parts is incredibly difficult. I'm not saying Agile is the One True Way, but it's certainly easier to deal with than a lot of the other methodologies that have been inflicted on me. "Vague deadlines with no clear goals or acceptance criteria," for example. "We woefully underestimated how complicated this was because the person estimating it had zero expertise and now that we're trying to cobble this together for reals we are literally months behind." That was a good one. Buy a beverage for any tech worker and they will tell you a bunch of war stories.
posted by fifteen schnitzengruben is my limit at 8:24 PM on August 23, 2019 [23 favorites]
Building things with a lot of moving parts is incredibly difficult. I'm not saying Agile is the One True Way, but it's certainly easier to deal with than a lot of the other methodologies that have been inflicted on me. "Vague deadlines with no clear goals or acceptance criteria," for example. "We woefully underestimated how complicated this was because the person estimating it had zero expertise and now that we're trying to cobble this together for reals we are literally months behind." That was a good one. Buy a beverage for any tech worker and they will tell you a bunch of war stories.
posted by fifteen schnitzengruben is my limit at 8:24 PM on August 23, 2019 [23 favorites]
What if One Weird Trick can't substitute for the cultivation of Virtue, even if some of the different Weird Tricks could be fruitfully used by the Virtuous?
What if -- and hear me out here -- what if instead of One Weird Trick we broke it down into several Slightly Odd Shortcuts?
posted by rhizome at 8:32 PM on August 23, 2019 [21 favorites]
What if -- and hear me out here -- what if instead of One Weird Trick we broke it down into several Slightly Odd Shortcuts?
posted by rhizome at 8:32 PM on August 23, 2019 [21 favorites]
The problem isn't agile. The problem is management structures that want organizational and development processes to be a magic spell, whereby if they do a precise number of spins and say the right words, everything works out without ever actually bothering with the introspection required to build functioning organizations.
I'm not saying agile is perfect, but if it wasn't agile they were attempting to use in place of actually developing good teams, it'd just be something else.
posted by tocts at 8:36 PM on August 23, 2019 [58 favorites]
I'm not saying agile is perfect, but if it wasn't agile they were attempting to use in place of actually developing good teams, it'd just be something else.
posted by tocts at 8:36 PM on August 23, 2019 [58 favorites]
Whenever I hear about how development really works and how messed up things are i’m just really glad software doesn’t power anything important in the world. Same reason as a infosec guy I’m really glad security flaws don’t have real world impacts.
posted by inflatablekiwi at 8:45 PM on August 23, 2019 [22 favorites]
posted by inflatablekiwi at 8:45 PM on August 23, 2019 [22 favorites]
inflatablekiwi: Bad development processes and poor product security aren't unrelated problems.
posted by el io at 8:56 PM on August 23, 2019 [2 favorites]
posted by el io at 8:56 PM on August 23, 2019 [2 favorites]
No project ever works without scope clarity and discipline. Avoiding bikeshedding and yak shaving on the part of the devs, and avoiding wishy-washy Bring Me A Rock games with the executives or the clients will mean that whether you use agile and its variants, or waterfall-style you'll be OK.
I swear I have almost never in my life seen a group of "smart" people more susceptible to cargo-cult thinking than MBAs and software developers.
countdown to devs shrieking about being lumped in with MBAs in 3, 2, 1...
posted by tclark at 9:11 PM on August 23, 2019 [22 favorites]
I swear I have almost never in my life seen a group of "smart" people more susceptible to cargo-cult thinking than MBAs and software developers.
countdown to devs shrieking about being lumped in with MBAs in 3, 2, 1...
posted by tclark at 9:11 PM on August 23, 2019 [22 favorites]
This is why "but will it scale?" entered the lexicon of programmers everywhere."But will it scale?" is the software development version of but will it work in the streets?
posted by clawsoon at 9:13 PM on August 23, 2019 [2 favorites]
Bold choice. Most of the technical teams I've been on would have just murdered the scrum master and made a grim scarecrow out of their flayed skin as a warning to others, who might think that a standing meeting at the unholy hour of 8AM was appropriate
Big boy applications have engineers that live all over the world. 10:30am in Los Angeles is 6:30pm in London, but 8:00am in LA in only 4pm in the UK.
posted by sideshow at 9:14 PM on August 23, 2019 [10 favorites]
Big boy applications have engineers that live all over the world. 10:30am in Los Angeles is 6:30pm in London, but 8:00am in LA in only 4pm in the UK.
posted by sideshow at 9:14 PM on August 23, 2019 [10 favorites]
Thats why the Large Software Company I work for pretty much abolished distributed teams and thus we can have our status meetings at a reasonable 3pm, thankfully.
(Other teams might be in other areas, but those tend to be ad hoc meetings which are easier to schedule / wake up early and call in from home).
posted by thefoxgod at 9:36 PM on August 23, 2019 [3 favorites]
(Other teams might be in other areas, but those tend to be ad hoc meetings which are easier to schedule / wake up early and call in from home).
posted by thefoxgod at 9:36 PM on August 23, 2019 [3 favorites]
Giant Corporation split the difference and has a satellite team in Seattle that works on the app and other specific development products. There’s another one in San Diego due to a recent acquisition. The rest of us are in the Midwest.
Having individual team members spread across multiple time zones isn’t a very efficient way to work.
posted by Autumnheart at 10:05 PM on August 23, 2019 [3 favorites]
Having individual team members spread across multiple time zones isn’t a very efficient way to work.
posted by Autumnheart at 10:05 PM on August 23, 2019 [3 favorites]
Having worked ~ 20 years as a dba (and now hadoop admin) at the same company who has watched the move from waterfall development of desktop client/server applications to agile development of nodeJS webservices, i can confidently say three things:
Both ideologies work, both are vulnerable to bad product management, and “Agile” is apparently French for “no documentation “
posted by das_2099 at 10:10 PM on August 23, 2019 [37 favorites]
Both ideologies work, both are vulnerable to bad product management, and “Agile” is apparently French for “no documentation “
posted by das_2099 at 10:10 PM on August 23, 2019 [37 favorites]
Shhh no one talks about documentation
posted by zenon at 10:17 PM on August 23, 2019 [29 favorites]
posted by zenon at 10:17 PM on August 23, 2019 [29 favorites]
1. The entire history of IT is essentially that of competing religions.
2. Agile is not the same as agile
3. Cults are a choice.
I have successfully built and delivered numerous nation scale services using agile (deliberate small “a”). There is no workable alternative.
The Cargo Cult Agile that the author describes is an interesting area of anthropology, it’s not how any sane organisation would deliver a system. However it is exactly how large consultancies and dev shops can ensure a highly profitable future business model.
posted by fallingbadgers at 10:41 PM on August 23, 2019 [14 favorites]
2. Agile is not the same as agile
3. Cults are a choice.
I have successfully built and delivered numerous nation scale services using agile (deliberate small “a”). There is no workable alternative.
The Cargo Cult Agile that the author describes is an interesting area of anthropology, it’s not how any sane organisation would deliver a system. However it is exactly how large consultancies and dev shops can ensure a highly profitable future business model.
posted by fallingbadgers at 10:41 PM on August 23, 2019 [14 favorites]
Fifteen Minutes Hate.
posted by rhizome at 11:14 PM on August 23, 2019 [7 favorites]
posted by rhizome at 11:14 PM on August 23, 2019 [7 favorites]
Bad development processes and poor product security aren't unrelated problems.
Yeah I get that. Should have had a /s at the end of my comment. Made harder by the fact that even good development processes get undone by the layers of crap they are built on.....
posted by inflatablekiwi at 11:28 PM on August 23, 2019
Yeah I get that. Should have had a /s at the end of my comment. Made harder by the fact that even good development processes get undone by the layers of crap they are built on.....
posted by inflatablekiwi at 11:28 PM on August 23, 2019
Smart data systems are the future, says futurist with a smart data company seeking investors.
"No Silver Bullet" - Fred Brooks
This is such a profound insight, and it's taken me years to really appreciate it. Note how there are no asterisks there: not for Agile, or functional programming, or Typescript/Haskell/Julia/etc/etc, or any other innovation we've come up with.
The best we've ever been able to do is "Hey, could you look at this and see if it looks okay?" And that's a powerful thing, to look at the process and the product and execute judgement on it. And so, systems that promote this activity of examination produce better software: open source, iterative feedback, trusting relationships.
But this plays into the power dynamics of organizations in ways that are uncomfortable. Is the QA tester able to say that's really a bug? We need to ship this week! Can the UX person override the CEO's favorite color ("hideous chartreuse")? What if the decade-old specification is just wrong, I mean, it's signed off and everything, and, I mean, it would take months to do that again?!
It's an uncomfortable margin to live in, the land of no silver bullet. But there really isn't anywhere else to be, though we try hard to convince ourselves otherwise.
posted by cowcowgrasstree at 11:34 PM on August 23, 2019 [23 favorites]
"No Silver Bullet" - Fred Brooks
This is such a profound insight, and it's taken me years to really appreciate it. Note how there are no asterisks there: not for Agile, or functional programming, or Typescript/Haskell/Julia/etc/etc, or any other innovation we've come up with.
The best we've ever been able to do is "Hey, could you look at this and see if it looks okay?" And that's a powerful thing, to look at the process and the product and execute judgement on it. And so, systems that promote this activity of examination produce better software: open source, iterative feedback, trusting relationships.
But this plays into the power dynamics of organizations in ways that are uncomfortable. Is the QA tester able to say that's really a bug? We need to ship this week! Can the UX person override the CEO's favorite color ("hideous chartreuse")? What if the decade-old specification is just wrong, I mean, it's signed off and everything, and, I mean, it would take months to do that again?!
It's an uncomfortable margin to live in, the land of no silver bullet. But there really isn't anywhere else to be, though we try hard to convince ourselves otherwise.
posted by cowcowgrasstree at 11:34 PM on August 23, 2019 [23 favorites]
A post from couple of months ago: The point of black triangles
One problem is that software development isn't really a single discipline. There are many different types of software and many different specific applications. Each has their own sets of problems of different types (technical, organisational, etc). A methodology that works for one can and will be complete rubbish for at least some others.
Having worked within various agile methodologies (mostly scrum) it seems to me that the main selling point for agile is identifying and managing risk. Risk to features, time, budget (See also: "good, fast, cheap"). It generally does help with that, but I also think it is oversold to managers who expect it to eliminate risk, which is just not realistic. There is One True Way to eliminate risk and that is to cancel the project.
As to 8AM meetings: I've worked in multi time-zone projects, including sideshow's example: "10:30am in Los Angeles is 6:30pm in London, but 8:00am in LA in only 4pm in the UK." Don't get the LA team up earlier, shift the London team later instead (not eight hours, just enough for some overlap). I've been on the London side of that and can tell you, sleeping in and missing rush hour on the tube is a nice little bonus.
posted by swr at 12:18 AM on August 24, 2019 [7 favorites]
One problem is that software development isn't really a single discipline. There are many different types of software and many different specific applications. Each has their own sets of problems of different types (technical, organisational, etc). A methodology that works for one can and will be complete rubbish for at least some others.
Having worked within various agile methodologies (mostly scrum) it seems to me that the main selling point for agile is identifying and managing risk. Risk to features, time, budget (See also: "good, fast, cheap"). It generally does help with that, but I also think it is oversold to managers who expect it to eliminate risk, which is just not realistic. There is One True Way to eliminate risk and that is to cancel the project.
As to 8AM meetings: I've worked in multi time-zone projects, including sideshow's example: "10:30am in Los Angeles is 6:30pm in London, but 8:00am in LA in only 4pm in the UK." Don't get the LA team up earlier, shift the London team later instead (not eight hours, just enough for some overlap). I've been on the London side of that and can tell you, sleeping in and missing rush hour on the tube is a nice little bonus.
posted by swr at 12:18 AM on August 24, 2019 [7 favorites]
These people should be made to watch Monty Python's 'Biggles Takes Dictation' sketch.
IANACSM, but the idea of the standup is information exchange, not project management. Specifically, the scrum master is not the project manager, and vice versa. This is the whole point of the scrum master's role being separate and abstracted; he has no rank, and no authority to be asking anyone why a ticket isn't done, nor when it will be. Similarly the project manager isn't supposed to ask in the standup itself; he can of course (and probably should) ask later.
What's supposed to happen, of course, is the developer volunteers the information himself, without being asked; but, the Darker the Scrum gets, the less likely this is to happen.
posted by Cardinal Fang at 2:03 AM on August 24, 2019 [7 favorites]
IANACSM, but the idea of the standup is information exchange, not project management. Specifically, the scrum master is not the project manager, and vice versa. This is the whole point of the scrum master's role being separate and abstracted; he has no rank, and no authority to be asking anyone why a ticket isn't done, nor when it will be. Similarly the project manager isn't supposed to ask in the standup itself; he can of course (and probably should) ask later.
What's supposed to happen, of course, is the developer volunteers the information himself, without being asked; but, the Darker the Scrum gets, the less likely this is to happen.
posted by Cardinal Fang at 2:03 AM on August 24, 2019 [7 favorites]
I think the biggest "Agile is a cult" realisation I had was when reading the Atlassian documentation on Scrum and realised that they were quoting and interpreting the agile manifesto almost exactly like people quote scripture.
It is bizarre how willing people are to cargo cult this stuff.
posted by leo_r at 2:08 AM on August 24, 2019 [5 favorites]
It is bizarre how willing people are to cargo cult this stuff.
posted by leo_r at 2:08 AM on August 24, 2019 [5 favorites]
Yes, a silver bullet. Many of them if you go by Brooks original "one order of magnitude improvement" as a silver bullet.
posted by aleph at 2:43 AM on August 24, 2019
posted by aleph at 2:43 AM on August 24, 2019
I'm working on a project with a team of three other developers, and this year, we've been reimplementing the functionality of a 30-year-old core system running on a mainframe. 95% of what that system does hasn't been touched, but we've been delivering great stuff every two weeks, and are on track to sell it to our first internal customer.
The main reason?
Working on a project with a team of three other developers.
Four is a good size for a development team, and projects that can usefully keep four developers busy until they're done are a good size for projects.
posted by flabdablet at 3:47 AM on August 24, 2019 [8 favorites]
The main reason?
Working on a project with a team of three other developers.
Four is a good size for a development team, and projects that can usefully keep four developers busy until they're done are a good size for projects.
posted by flabdablet at 3:47 AM on August 24, 2019 [8 favorites]
"We woefully underestimated how complicated this was because the person estimating it had zero expertise and now that we're trying to cobble this together for reals we are literally months behind."The point of estimating games is not correct estimates, it is to build consensus knowledge among a consistent team about where dragons are and what a reasonable unit of work is in the current system.
As above, agile isn't other management, it's communication and risk management through well defined definitions of done and a tendency for gross estimates to be better than pure chance. Such as "will this with item be done inside this cycle?"
But yes, most management sees it as a way to pretend that they can dictate all edges of the iron triangle. It's good for some kinds of software project but not necessarily the "we have no damn idea how to do this big thing yet" type.
It's also terrible for hardware, and I've watched way too many projects tank as a result of impedance and risk mismatch between software and hardware expectations across agile boundaries.
posted by abulafa at 4:28 AM on August 24, 2019 [11 favorites]
Agile is a good fit for projects that you can iterate on and it’s ok to deliver something that kinda mostly works. But for projects where requirements are known and fixed, or the thing you deliver has to be pretty much perfect, then Agile may not be the optimum choice.
posted by forforf at 5:53 AM on August 24, 2019 [8 favorites]
posted by forforf at 5:53 AM on August 24, 2019 [8 favorites]
I think the biggest "Agile is a cult" realisation I had was when reading the Atlassian documentation on Scrum and realised that they were quoting and interpreting the agile manifesto almost exactly like people quote scripture.
All Calvinism Sucks.
posted by mikelieman at 6:02 AM on August 24, 2019 [4 favorites]
All Calvinism Sucks.
posted by mikelieman at 6:02 AM on August 24, 2019 [4 favorites]
Agile is the worst possible software development method, except for all the others.
I mean, I have lots of complaints myself about Scrum and how it's implemented at my organization but I'd still never want to go back to working at a waterfall shop. I do QA and quality and testing in a long-term waterfall project has always been a disaster on any project I've worked on. Because all of the dates are set in stone and development always takes longer than budgeted, the QA process always got squeezed and there was never time to actually fix any issues we found. So my job was largely one of cataloging bugs in Jira that would never actually be fixed unless a customer complained.
Now at least I can find things up front and quickly because there's always a working system to test on and I can insist that the issue gets fixed before the story gets accepted. For me it's been a much more satisfying way to work.
I do hate that we're perpetually stuck in a two week release cycle and madly try to get things done before Tuesday because the sprint ends on Monday and not really any other reason. We build up way too much technical debt trying to get things in a sprint without doing them correctly. I'd much rather work in Kanban but managers love their artificial deadlines and metrics.
posted by octothorpe at 6:54 AM on August 24, 2019 [10 favorites]
I mean, I have lots of complaints myself about Scrum and how it's implemented at my organization but I'd still never want to go back to working at a waterfall shop. I do QA and quality and testing in a long-term waterfall project has always been a disaster on any project I've worked on. Because all of the dates are set in stone and development always takes longer than budgeted, the QA process always got squeezed and there was never time to actually fix any issues we found. So my job was largely one of cataloging bugs in Jira that would never actually be fixed unless a customer complained.
Now at least I can find things up front and quickly because there's always a working system to test on and I can insist that the issue gets fixed before the story gets accepted. For me it's been a much more satisfying way to work.
I do hate that we're perpetually stuck in a two week release cycle and madly try to get things done before Tuesday because the sprint ends on Monday and not really any other reason. We build up way too much technical debt trying to get things in a sprint without doing them correctly. I'd much rather work in Kanban but managers love their artificial deadlines and metrics.
posted by octothorpe at 6:54 AM on August 24, 2019 [10 favorites]
Even if Agile disappears from software development (and I'm not saying it will), it's far from dead. Other businesses have taken up the Agile banner and are waving it around as the mark of the New Way of Doing Business.(TM)
As an example, I happen to be aware of one very, very, very major company that reorganized its legal department and all of its legal processes using an Agile/Scrum approach, and from what I gather it likely to take that same approach to revamping other aspects of the business.
For good or bad, Agile is here to stay, at least for the foreseeable future. Don't be too surprised when you discover that the next time your kid's soccer team/band/etc. holds a bake sale/car wash/etc. fundraising activity that it was planned using Agile (or Agile-ish) concepts and buzzwords.
posted by sardonyx at 7:49 AM on August 24, 2019
As an example, I happen to be aware of one very, very, very major company that reorganized its legal department and all of its legal processes using an Agile/Scrum approach, and from what I gather it likely to take that same approach to revamping other aspects of the business.
For good or bad, Agile is here to stay, at least for the foreseeable future. Don't be too surprised when you discover that the next time your kid's soccer team/band/etc. holds a bake sale/car wash/etc. fundraising activity that it was planned using Agile (or Agile-ish) concepts and buzzwords.
posted by sardonyx at 7:49 AM on August 24, 2019
Agile, like most management "methodologies", is at its core an attempt to remove the messy human component from a complex problem. As such, it's always doomed to fail in some sense.
A good manager working with good team leads, working unmolested by a larger toxic organizational structure, can probably be successful regardless of methodology, or with no formal methodology at all.
Given the right ingredients, a good team will self-organize, possibly into something that looks like an 'agile' methodology from a distance. The only thing that imposing a methodology on a team does, in the best case, is remove some of the time/effort that it would take the team to cohere and find a stable state around their own set of processes, built up from first principles; it eliminates a sort of wheel-reinvention, but at the cost of possibly not discovering anything better for that specific project or problem space.
Good teams organizing themselves is how most methodologies come about, though: someone, at one point, had a really bitchin' good team, where everything worked really well, and someone thought to themselves "a ha! let's try to replicate this for all the other (less good) teams!" And so they took notes and promulgated it as the Secret Success Sauce, generally neglecting to mention that you can put as much sauce as you want on a turd and it's still a turd, and filet mignon probably doesn't need the sauce anyway. (It's the iffy cube steak that benefits from the sauce.)
Software development, like most complex social activities humans perform in groups, isn't really amenable to cookie-cutter systematization. The team will only be as good as the sum of its parts times how well everyone "gels" together (a factor that can be greater or less than 1, depending). If managers spent more time on ensuring people worked well together, that the team was cohesive and people enjoyed and were interested in the work, and less time on formal methodology-following, I think they'd probably do better overall, in terms of actual output. But this requires a markedly different skillset than the typical corporate project manager has, however, and it's not easily reflected in short-term KPIs; it also requires higher management to trust the project/program manager.
Low-trust organizations have an obsession with trying to turn people into interchangeable parts, and seemingly prefer to have a large number of mediocre managers and teams by following a formal methodology, vs. having a smaller number of really high-performing teams and some number of low-performing teams (because not all managers or teams are created equal) that they'd have to deal with on a case-by-case basis. Interestingly, I think this is why small companies and startups are so competitive in tech: it's at the small end of the market where you get both really good and really bad managers/leads running wild. The badly-managed teams tend (hopefully, in my experience usually) to crash and burn, while the better ones are successful—but only to the point where they get acquired, and whatever bottom-up processes have been created get crushed by top-down "thou shall" management by the new acquirer. Then they become just as mediocre as the rest of the big, low-trust organization, and the cycle restarts somewhere else.
posted by Kadin2048 at 7:51 AM on August 24, 2019 [23 favorites]
A good manager working with good team leads, working unmolested by a larger toxic organizational structure, can probably be successful regardless of methodology, or with no formal methodology at all.
Given the right ingredients, a good team will self-organize, possibly into something that looks like an 'agile' methodology from a distance. The only thing that imposing a methodology on a team does, in the best case, is remove some of the time/effort that it would take the team to cohere and find a stable state around their own set of processes, built up from first principles; it eliminates a sort of wheel-reinvention, but at the cost of possibly not discovering anything better for that specific project or problem space.
Good teams organizing themselves is how most methodologies come about, though: someone, at one point, had a really bitchin' good team, where everything worked really well, and someone thought to themselves "a ha! let's try to replicate this for all the other (less good) teams!" And so they took notes and promulgated it as the Secret Success Sauce, generally neglecting to mention that you can put as much sauce as you want on a turd and it's still a turd, and filet mignon probably doesn't need the sauce anyway. (It's the iffy cube steak that benefits from the sauce.)
Software development, like most complex social activities humans perform in groups, isn't really amenable to cookie-cutter systematization. The team will only be as good as the sum of its parts times how well everyone "gels" together (a factor that can be greater or less than 1, depending). If managers spent more time on ensuring people worked well together, that the team was cohesive and people enjoyed and were interested in the work, and less time on formal methodology-following, I think they'd probably do better overall, in terms of actual output. But this requires a markedly different skillset than the typical corporate project manager has, however, and it's not easily reflected in short-term KPIs; it also requires higher management to trust the project/program manager.
Low-trust organizations have an obsession with trying to turn people into interchangeable parts, and seemingly prefer to have a large number of mediocre managers and teams by following a formal methodology, vs. having a smaller number of really high-performing teams and some number of low-performing teams (because not all managers or teams are created equal) that they'd have to deal with on a case-by-case basis. Interestingly, I think this is why small companies and startups are so competitive in tech: it's at the small end of the market where you get both really good and really bad managers/leads running wild. The badly-managed teams tend (hopefully, in my experience usually) to crash and burn, while the better ones are successful—but only to the point where they get acquired, and whatever bottom-up processes have been created get crushed by top-down "thou shall" management by the new acquirer. Then they become just as mediocre as the rest of the big, low-trust organization, and the cycle restarts somewhere else.
posted by Kadin2048 at 7:51 AM on August 24, 2019 [23 favorites]
Agile is a good fit for projects that you can iterate on and it’s ok to deliver something that kinda mostly works. But for projects where requirements are known and fixed, or the thing you deliver has to be pretty much perfect, then Agile may not be the optimum choice.
Having worked within various agile methodologies (mostly scrum) it seems to me that the main selling point for agile is identifying and managing risk. Risk to features, time, budget (See also: "good, fast, cheap"). It generally does help with that, but I also think it is oversold to managers who expect it to eliminate risk, which is just not realistic. There is One True Way to eliminate risk and that is to cancel the project.
These are true statements that explain most of most people's experiences with Agile.
The only thing I will add is that the usefulness in identifying risk is deeply related to whether time-risk and feature-risk are convertible between each other in both directions.
posted by PMdixon at 7:53 AM on August 24, 2019 [6 favorites]
Having worked within various agile methodologies (mostly scrum) it seems to me that the main selling point for agile is identifying and managing risk. Risk to features, time, budget (See also: "good, fast, cheap"). It generally does help with that, but I also think it is oversold to managers who expect it to eliminate risk, which is just not realistic. There is One True Way to eliminate risk and that is to cancel the project.
These are true statements that explain most of most people's experiences with Agile.
The only thing I will add is that the usefulness in identifying risk is deeply related to whether time-risk and feature-risk are convertible between each other in both directions.
posted by PMdixon at 7:53 AM on August 24, 2019 [6 favorites]
I was fortunate to not have to deal directly with Agile. I got to see members of my former team (I was in customer support, which got separated out by the acquiring mega-corporation) spend most of their time in meetings instead of doing the work. It looked like this was headed toward the support teams as well, but I got to retire before that came to pass. It seemed to me to be another one of those systems that give more emphasis on the managers instead of the people doing the work. (see 'interchangeable parts' above)
The article just reminded me that I hope to never encounter a dashboard again.
posted by MtDewd at 8:04 AM on August 24, 2019
The article just reminded me that I hope to never encounter a dashboard again.
posted by MtDewd at 8:04 AM on August 24, 2019
The majority of these management "solutions" (Agile, Six Sigma, etc.) smell like MLM to me.
posted by Sphinx at 8:18 AM on August 24, 2019 [2 favorites]
posted by Sphinx at 8:18 AM on August 24, 2019 [2 favorites]
→ We're an outside group that has patiently but diligently worked to isolate ourselves from the overall organization and have worked in an agile fashion to always be focused on the most important undone capability.
posted by scruss at 8:27 AM on August 24, 2019 [7 favorites]
- If your development group is isolated from the organization that uses and understands that 95% of the decades-old mainframe system, how will you know their needs when you replace it?
- How will your outside group avoid not-invented-here opposition from the users when you're trying to get your new system accepted?
posted by scruss at 8:27 AM on August 24, 2019 [7 favorites]
A good manager working with good team leads, working unmolested by a larger toxic organizational structure, can probably be successful regardless of methodology, or with no formal methodology at all.
Sure, but when you're dependent on a bad team with a bad manager, getting them to show up more than once a quarter and tell you that they haven't done any work at least lets you know *faster* that you have to replace them all.
(I've been in shops with waterfall and with agile, and both suck, for sure, but you can shake out some of the entrenched slackers by switching from one to the other so they lose their favorite napping spots.)
posted by restless_nomad at 9:04 AM on August 24, 2019 [5 favorites]
Sure, but when you're dependent on a bad team with a bad manager, getting them to show up more than once a quarter and tell you that they haven't done any work at least lets you know *faster* that you have to replace them all.
(I've been in shops with waterfall and with agile, and both suck, for sure, but you can shake out some of the entrenched slackers by switching from one to the other so they lose their favorite napping spots.)
posted by restless_nomad at 9:04 AM on August 24, 2019 [5 favorites]
And so they took notes and promulgated it as the Secret Success Sauce, generally neglecting to mention that you can put as much sauce as you want on a turd and it's still a turd, and filet mignon probably doesn't need the sauce anyway. (It's the iffy cube steak that benefits from the sauce.)
It benefits even more from not being expected to be filet mignon at half the price.
posted by flabdablet at 9:27 AM on August 24, 2019 [1 favorite]
It benefits even more from not being expected to be filet mignon at half the price.
posted by flabdablet at 9:27 AM on August 24, 2019 [1 favorite]
It generally does help with that, but I also think it is oversold to managers who expect it to eliminate risk, which is just not realistic. There is One True Way to eliminate risk and that is to cancel the project.
I think agile and Agile-like methodologies do work, but they must be coupled with a certain tolerance for risk to result in building something useful.
Management doesn't want to risk money, engineering doesn't want to risk time (or risk needing to throw away code, which is basically the same thing.) The result has been minimum viable products too minimal to be viable as products. Both groups then look into the analytics and conclude the project to be too risky to extend, and then we all move on to the next shiny thing.
posted by elwoodwiles at 9:40 AM on August 24, 2019 [5 favorites]
I think agile and Agile-like methodologies do work, but they must be coupled with a certain tolerance for risk to result in building something useful.
Management doesn't want to risk money, engineering doesn't want to risk time (or risk needing to throw away code, which is basically the same thing.) The result has been minimum viable products too minimal to be viable as products. Both groups then look into the analytics and conclude the project to be too risky to extend, and then we all move on to the next shiny thing.
posted by elwoodwiles at 9:40 AM on August 24, 2019 [5 favorites]
The result has been minimum viable products too minimal to be viable as products.
I have to say this my exact opposite experience as a developer. I mean, I struggle to imagine an industry where software is not currently carrying the load for a total lack of decent business/social ideas, and ones that are less reliant on cargo cults and that products are differentiated in some way beyond feature overload.
Think about it, a few industries:
Residential real estate: if your freakin' lawn is slightly different from the one next door it'll bring down the value of the entire neighborhood. Solution: smart homes
Commerical real estate: We only design for one type of customer, the rest can go to hell. Solution: customer analytics that are so screwed up Ross Dress for Less, Aldi, and Goodwill stores are viable for mega new developments.
Finance: we have mastered all the ideas of the stock,bond, and risk markets, so the software solution is to do them all the same but way way faster!
Civil Engineering: build it and they will come (but use software to identify minimal viable construction techniques because they may come but they will not stay because they will move on to our next project)
Medicine: not sure, what's up -no need to wait and advise healthier lifestyle or anything like that. Let's invent some newer tests.
teaching: the best way to manage students is to have them sit in (mostly) windowless rooms listening to a 1-20 teacher/student ratio. The outcomes have sucked for many, let's rate them via standardized tests. If you do them on a computer, you can do them many times a year.
Appliances: can we make a better dishwasher/washer/vent hood dryer? Yes we could make it quieter/faster/more reliable but instead let's just put wifi in there.
posted by The_Vegetables at 1:04 PM on August 24, 2019 [2 favorites]
I have to say this my exact opposite experience as a developer. I mean, I struggle to imagine an industry where software is not currently carrying the load for a total lack of decent business/social ideas, and ones that are less reliant on cargo cults and that products are differentiated in some way beyond feature overload.
Think about it, a few industries:
Residential real estate: if your freakin' lawn is slightly different from the one next door it'll bring down the value of the entire neighborhood. Solution: smart homes
Commerical real estate: We only design for one type of customer, the rest can go to hell. Solution: customer analytics that are so screwed up Ross Dress for Less, Aldi, and Goodwill stores are viable for mega new developments.
Finance: we have mastered all the ideas of the stock,bond, and risk markets, so the software solution is to do them all the same but way way faster!
Civil Engineering: build it and they will come (but use software to identify minimal viable construction techniques because they may come but they will not stay because they will move on to our next project)
Medicine: not sure, what's up -no need to wait and advise healthier lifestyle or anything like that. Let's invent some newer tests.
teaching: the best way to manage students is to have them sit in (mostly) windowless rooms listening to a 1-20 teacher/student ratio. The outcomes have sucked for many, let's rate them via standardized tests. If you do them on a computer, you can do them many times a year.
Appliances: can we make a better dishwasher/washer/vent hood dryer? Yes we could make it quieter/faster/more reliable but instead let's just put wifi in there.
posted by The_Vegetables at 1:04 PM on August 24, 2019 [2 favorites]
I always saw agile as a way to talk to business stakeholders about what was ACTUALLY possible. Through stack ranking requirements and through seeing what could actually get done in 2-4 weeks of work, my business partners often became much more savvy and reasonable product owners. I also always liked that they HAD to be involved and see the messiness of development. I think it helped us build true partnerships in the best cases.
I do agree that data management projects are not a great fit for lots of business stakeholder involvement and that people who are too rigid about “must have something to demo” aren’t really treating business folks like partners, but rather like children who need shiny things to remain interested. Sometimes you have to spend time building the non-demonstrable things.
posted by CMcG at 2:11 PM on August 24, 2019 [9 favorites]
I do agree that data management projects are not a great fit for lots of business stakeholder involvement and that people who are too rigid about “must have something to demo” aren’t really treating business folks like partners, but rather like children who need shiny things to remain interested. Sometimes you have to spend time building the non-demonstrable things.
posted by CMcG at 2:11 PM on August 24, 2019 [9 favorites]
Shhh no one talks about documentation
WHO DARES STIR THE TECHNICAL WRITER FROM MY SLUMBER?
So you guys didn't document the EDW or ETL process AT ALL? Oh, okay, the guy that built it kept everything in his head and he moved to Montana 3 months ago. Wonderful. Brilliant. And best practices for the developers? Don't have them? Amazing. What happens when the system goes down? You...call the guy in India that knows how to bring it back up and hope he answers the phone. Fabulous.
posted by Ghostride The Whip at 2:32 PM on August 24, 2019 [15 favorites]
WHO DARES STIR THE TECHNICAL WRITER FROM MY SLUMBER?
So you guys didn't document the EDW or ETL process AT ALL? Oh, okay, the guy that built it kept everything in his head and he moved to Montana 3 months ago. Wonderful. Brilliant. And best practices for the developers? Don't have them? Amazing. What happens when the system goes down? You...call the guy in India that knows how to bring it back up and hope he answers the phone. Fabulous.
posted by Ghostride The Whip at 2:32 PM on August 24, 2019 [15 favorites]
Our developers write all of our documentation. It's, um, mostly grammatical.
posted by octothorpe at 3:14 PM on August 24, 2019 [7 favorites]
posted by octothorpe at 3:14 PM on August 24, 2019 [7 favorites]
The problem isn't agile. The problem is management structures that want organizational and development processes to be a magic spell, whereby if they do a precise number of spins and say the right words, everything works out without ever actually bothering with the introspection required to build functioning organizations.
I have found it borderline hilarious how heavily my company has embraced all of the Agile buzzwords while remaining actively hostile to most of the necessary concepts. I've realized a lot of it has to do with consultants.
Corporate executives are understandably averse to being told that their organizations are screwed up at a core level. By itself, this would be a problem. But then there's a whole industry of people out there who show up and say, no, you don't have a core issue! You just need to pay us and it'll get fixed! Send some people to training. Those consultants, Agile is the best thing they have to sell, because it sounds good and because it's hard to immediately identify that it isn't working.
Which is to say, Agile as a corporate religion is a problem because of who's evangelizing it. The execs are not converts because they met people who were using Agile who were like them and they saw that it worked great and they thought they'd join up. People who don't do what we do walked in with Powerpoints and training courses with comb-bound workbooks, and management thought those things seemed good and familiar and that therefore the evangelists were trustworthy. We've gotten exactly the same dumb thing going for automated testing, now. All buzzwords and stupid plans that involve paying for consultants for ludicrously little training, and no plan for how to update our processes. These people can turn all manner of fine ideas into dumb corporate initiatives if enough money is on the table.
posted by Sequence at 3:44 PM on August 24, 2019 [8 favorites]
I have found it borderline hilarious how heavily my company has embraced all of the Agile buzzwords while remaining actively hostile to most of the necessary concepts. I've realized a lot of it has to do with consultants.
Corporate executives are understandably averse to being told that their organizations are screwed up at a core level. By itself, this would be a problem. But then there's a whole industry of people out there who show up and say, no, you don't have a core issue! You just need to pay us and it'll get fixed! Send some people to training. Those consultants, Agile is the best thing they have to sell, because it sounds good and because it's hard to immediately identify that it isn't working.
Which is to say, Agile as a corporate religion is a problem because of who's evangelizing it. The execs are not converts because they met people who were using Agile who were like them and they saw that it worked great and they thought they'd join up. People who don't do what we do walked in with Powerpoints and training courses with comb-bound workbooks, and management thought those things seemed good and familiar and that therefore the evangelists were trustworthy. We've gotten exactly the same dumb thing going for automated testing, now. All buzzwords and stupid plans that involve paying for consultants for ludicrously little training, and no plan for how to update our processes. These people can turn all manner of fine ideas into dumb corporate initiatives if enough money is on the table.
posted by Sequence at 3:44 PM on August 24, 2019 [8 favorites]
Oh, also, I'm curious, as long as we're here, if anybody hereabouts has actually read or tried to apply the Shape Up stuff that Basecamp has been promoting recently as an alternative? I don't think it's any better suited to being a religion than Agile is, but it seems like there's some potential there to get back to the sensible "get stuff done" bits. I found it really interesting that they released the book for free, under the circumstances.
posted by Sequence at 4:05 PM on August 24, 2019 [1 favorite]
posted by Sequence at 4:05 PM on August 24, 2019 [1 favorite]
As an example, I happen to be aware of one very, very, very major company that reorganized its legal department and all of its legal processes using an Agile/Scrum approach, and from what I gather it likely to take that same approach to revamping other aspects of the business.
As it happens, Fred Brooks had a son who is a fairly well-known lawyer in tech litigation circles, best known among the people who worked for him at his firm for his stubborn refusal to add people to a litigation team regardless of how hairy it got. As far as I know, though, he didn't try to impose Agile on anybody.
Major litigation is weird in that, although the sequence of events/deliverables is theoretically well-known, each case is so sui generis that you always end up standing up your own handmade, artisanal process for getting things done. It's always a mess, yet I've always expected that any attempt to rationalize and standardize would be worse. At least we don't have to spend time on cargo-cult rituals. Maybe that's why--no client is willing to pay for that billing.
posted by praemunire at 6:21 PM on August 24, 2019 [3 favorites]
As it happens, Fred Brooks had a son who is a fairly well-known lawyer in tech litigation circles, best known among the people who worked for him at his firm for his stubborn refusal to add people to a litigation team regardless of how hairy it got. As far as I know, though, he didn't try to impose Agile on anybody.
Major litigation is weird in that, although the sequence of events/deliverables is theoretically well-known, each case is so sui generis that you always end up standing up your own handmade, artisanal process for getting things done. It's always a mess, yet I've always expected that any attempt to rationalize and standardize would be worse. At least we don't have to spend time on cargo-cult rituals. Maybe that's why--no client is willing to pay for that billing.
posted by praemunire at 6:21 PM on August 24, 2019 [3 favorites]
Sure, but when you're dependent on a bad team with a bad manager, getting them to show up more than once a quarter and tell you that they haven't done any work at least lets you know *faster* that you have to replace them all.
This also happens when you're dependent on a good team with a bad manager.
posted by Cardinal Fang at 12:50 AM on August 25, 2019 [2 favorites]
This also happens when you're dependent on a good team with a bad manager.
posted by Cardinal Fang at 12:50 AM on August 25, 2019 [2 favorites]
So much to unpack, and way too many thoughts in my head to create a coherent response here. SO MANY great responses already.
Love octothorpe’s “Agile is the worst possible software development method, except for all the others.”
So, I’ll just say a couple of things.
I’ve been using (little “a”) agile for about...15 years, maybe? And I can say it “works” (for small values of “works”), if you don’t turn it into a ritual and adapt it to the work at hand. I avoid using the word “agile” in front of management because it makes me feel dirty every time and they always think I mean “Agile”.
That said, software development as a profession is so badly broken that I’m really glad I’m retiring pretty soon, but it’ll still probably kill me after I quit working.
posted by shorstenbach at 12:42 PM on August 25, 2019 [5 favorites]
Love octothorpe’s “Agile is the worst possible software development method, except for all the others.”
So, I’ll just say a couple of things.
I’ve been using (little “a”) agile for about...15 years, maybe? And I can say it “works” (for small values of “works”), if you don’t turn it into a ritual and adapt it to the work at hand. I avoid using the word “agile” in front of management because it makes me feel dirty every time and they always think I mean “Agile”.
That said, software development as a profession is so badly broken that I’m really glad I’m retiring pretty soon, but it’ll still probably kill me after I quit working.
posted by shorstenbach at 12:42 PM on August 25, 2019 [5 favorites]
Being required to hold a speaking stick at 8AM is legit grounds for making a beeline to an exit.
In fact, the use of talking sticks as a method of settling conflicts, and answering questions - represents some long-established leadership practice that could be useful for software developers when properly followed.
Tribal meeting involving talking sticks take place in a sacred context. The audience are taught to listen very carefully to the view of whoever is holding the stick - even if they personally disagree with it. The "sacred truth" that each person speaks when they hold the stick is modulated by that person's own viewpoint - and to be infused with wisdom which may derive from the spirituals powers of "peace", "growth", "truth", "wisdom", "far-sightedness", "protection", "abundance", "love", "strength", "energy", "knowledge", "healing", "focus" and "cleansing". The stick holder has the job of identifying which of those spiritual powers should be informing whatever they say and the audience accepts that each person will tend to have particular expertise in some of these areas.
All of these headings apply to software just as they do to other joint endeavours in life - and many of them represent important aspects of a development that are often overlooked (the "why" rather than the "what" or the "how"). As with Agile - the trick is to really understand the power, purpose and limitations of the method before applying it.
posted by rongorongo at 2:40 AM on August 28, 2019 [1 favorite]
In fact, the use of talking sticks as a method of settling conflicts, and answering questions - represents some long-established leadership practice that could be useful for software developers when properly followed.
Tribal meeting involving talking sticks take place in a sacred context. The audience are taught to listen very carefully to the view of whoever is holding the stick - even if they personally disagree with it. The "sacred truth" that each person speaks when they hold the stick is modulated by that person's own viewpoint - and to be infused with wisdom which may derive from the spirituals powers of "peace", "growth", "truth", "wisdom", "far-sightedness", "protection", "abundance", "love", "strength", "energy", "knowledge", "healing", "focus" and "cleansing". The stick holder has the job of identifying which of those spiritual powers should be informing whatever they say and the audience accepts that each person will tend to have particular expertise in some of these areas.
All of these headings apply to software just as they do to other joint endeavours in life - and many of them represent important aspects of a development that are often overlooked (the "why" rather than the "what" or the "how"). As with Agile - the trick is to really understand the power, purpose and limitations of the method before applying it.
posted by rongorongo at 2:40 AM on August 28, 2019 [1 favorite]
→ Tribal meeting involving talking sticks take place in a sacred context
Yeah, but it's the fucking 8 am part that's the problem. It could be a stick, it could be a pumpkin, but at that time in the morning it's just a hell no
posted by scruss at 6:08 AM on August 28, 2019 [1 favorite]
Yeah, but it's the fucking 8 am part that's the problem. It could be a stick, it could be a pumpkin, but at that time in the morning it's just a hell no
posted by scruss at 6:08 AM on August 28, 2019 [1 favorite]
I always saw agile as a way to talk to business stakeholders about what was ACTUALLY possible.
Yeah I mean you need some kind of forcing function to get people to accept what is actually possible as opposed to conflict averse devs and PMs just saying yes to everything (or risk averse devs and PMs just saying no to everything) and it's nice if that acceptance happens before something nobody wants to make or paid for is made and waiting to be paid for. No one's come up with great ones for product work. (SLO/As work pretty good in service work)
posted by PMdixon at 6:31 AM on August 28, 2019
Yeah I mean you need some kind of forcing function to get people to accept what is actually possible as opposed to conflict averse devs and PMs just saying yes to everything (or risk averse devs and PMs just saying no to everything) and it's nice if that acceptance happens before something nobody wants to make or paid for is made and waiting to be paid for. No one's come up with great ones for product work. (SLO/As work pretty good in service work)
posted by PMdixon at 6:31 AM on August 28, 2019
Yeah, but it's the fucking 8 am part that's the problem
I could do without the self-congratulating New Age cultural appropriation, too.
posted by thelonius at 6:43 AM on August 28, 2019 [2 favorites]
I could do without the self-congratulating New Age cultural appropriation, too.
posted by thelonius at 6:43 AM on August 28, 2019 [2 favorites]
It could be a stick, it could be a pumpkin
Ha ha, at one job we had a bag of Dragon's Eye candy (apparently RIP: a burlap bag of "green scales" gum with an individually wrapped white gumball in red syrup) that was passed around to the person currently using a one-person-at-a-time resource.
posted by rhizome at 11:15 AM on August 28, 2019
Ha ha, at one job we had a bag of Dragon's Eye candy (apparently RIP: a burlap bag of "green scales" gum with an individually wrapped white gumball in red syrup) that was passed around to the person currently using a one-person-at-a-time resource.
posted by rhizome at 11:15 AM on August 28, 2019
conflict averse devs and PMs just saying yes to everything
In my experience it's not devs and PMs saying yes to everything; it's clueless sales types who don't understand that software is not soap powder and have no grasp at all of the difference between the kinds of change that are quickly achievable and those that would require from-the-ground-up re-architecting.
The core insight that gave rise to Agile is that deep inclusion of well-informed customer representation in an ongoing design and implementation process saves wasted work and therefore time and money. Any so-called Agile process that doesn't actually make that inclusion completely central is just management trying to convince itself it's being all like cool and cutting-edge and shit.
posted by flabdablet at 8:17 PM on August 28, 2019
In my experience it's not devs and PMs saying yes to everything; it's clueless sales types who don't understand that software is not soap powder and have no grasp at all of the difference between the kinds of change that are quickly achievable and those that would require from-the-ground-up re-architecting.
The core insight that gave rise to Agile is that deep inclusion of well-informed customer representation in an ongoing design and implementation process saves wasted work and therefore time and money. Any so-called Agile process that doesn't actually make that inclusion completely central is just management trying to convince itself it's being all like cool and cutting-edge and shit.
posted by flabdablet at 8:17 PM on August 28, 2019
I could do without the self-congratulating New Age cultural appropriation, too
It's not like a token-passing mutex needs window-dressing before software developers can understand what it's for.
posted by flabdablet at 8:21 PM on August 28, 2019 [2 favorites]
It's not like a token-passing mutex needs window-dressing before software developers can understand what it's for.
posted by flabdablet at 8:21 PM on August 28, 2019 [2 favorites]
It's not like a token-passing mutex needs window-dressing before software developers can understand what it's for.
Well done. Well done indeed.
posted by PMdixon at 6:58 AM on August 29, 2019
Well done. Well done indeed.
posted by PMdixon at 6:58 AM on August 29, 2019
« Older PostYourAnimal meets FeelGoodFilter | Between cancer and diabetes Newer »
This thread has been archived and is closed to new comments
posted by He Is Only The Imposter at 7:22 PM on August 23, 2019 [15 favorites]