I Have No Mouth And I Must Scrum
July 19, 2021 1:26 PM Subscribe
Is your team working within a Scrum framework? Is it not working for you? Do you feel micromanaged, overworked, overwhelmed with meaningless meetings? Your team might be using Scream. The Scream Guide explains all.
What is Scream? And what is the Scream Guide?
What is Scream? And what is the Scream Guide?
Scream is a framework built as an imitation of Scrum, giving unwitting observers the appearance that the organization might be using Scrum. Scream is a framework for cementing the status quo, preserving existing mindsets and creating an illusion that things are improving. This Guide contains important elements of Scream. This definition consists of Scream roles, events, artifacts and the rules that bind them together. While Ken Schwaber and Jeff Sutherland developed Scrum, Scream patterns are provided by thousands of organizations, self-proclaimed “experts” and people who passed mickey mouse exams worldwide who claim to understand and be doing Scrum.
The Daily Scream is held at the most inconvenient time for parents with kindergarten age kids and at the place which is most difficult to reach.
My company is on the opposite coast from me. I'm too tired to scream during the 6:30 AM Daily Scream.
posted by bendy at 1:44 PM on July 19, 2021 [6 favorites]
My company is on the opposite coast from me. I'm too tired to scream during the 6:30 AM Daily Scream.
posted by bendy at 1:44 PM on July 19, 2021 [6 favorites]
Related item from the software development antipatterns desk: SAFe 5 for Lean Enterprises which combines the words "scaled" and "agile" into something that ends up an unholy incarnation of darkness. Look out for the weirdly implemented trademark protection though. I'm not sure I'm allowed to mention it by name.
posted by fedward at 2:02 PM on July 19, 2021 [4 favorites]
posted by fedward at 2:02 PM on July 19, 2021 [4 favorites]
I started reading this but got too sad and had to stop.
posted by aubilenon at 2:06 PM on July 19, 2021 [24 favorites]
posted by aubilenon at 2:06 PM on July 19, 2021 [24 favorites]
I started reading this but got too sad and had to stop.
Ditto. Like a sitcom set in a concentration camp, not everyone is going to find it funny.
posted by Cardinal Fang at 2:15 PM on July 19, 2021 [16 favorites]
Ditto. Like a sitcom set in a concentration camp, not everyone is going to find it funny.
posted by Cardinal Fang at 2:15 PM on July 19, 2021 [16 favorites]
I am only here to praise the post title.
posted by doctornemo at 2:16 PM on July 19, 2021 [33 favorites]
posted by doctornemo at 2:16 PM on July 19, 2021 [33 favorites]
I started reading this but got too sad and had to stop.
I'm concerned about how that will impact the burn-downs.
posted by thelonius at 2:17 PM on July 19, 2021 [6 favorites]
I'm concerned about how that will impact the burn-downs.
posted by thelonius at 2:17 PM on July 19, 2021 [6 favorites]
To be used with Abject Oriented Programming for best results
posted by merlynkline at 2:36 PM on July 19, 2021 [15 favorites]
posted by merlynkline at 2:36 PM on July 19, 2021 [15 favorites]
I work in a tech company utilizing a Scum framework extruded from an algal mindset.
posted by It's Raining Florence Henderson at 2:45 PM on July 19, 2021 [14 favorites]
posted by It's Raining Florence Henderson at 2:45 PM on July 19, 2021 [14 favorites]
I’m supposing this is satire, but I’m not sure if they’re saying most scrums are done badly, or just all of them. I only got to see this from the sidelines, as many of my coworkers had all of their productivity drained away. Fortunately I retired before my team got sucked into it.
posted by MtDewd at 3:09 PM on July 19, 2021 [5 favorites]
posted by MtDewd at 3:09 PM on July 19, 2021 [5 favorites]
I would send this to my co-workers but after sixteen months of not seeing them I don’t remember which ones would have a sense of humor about this sort of thing.
posted by madcaptenor at 3:33 PM on July 19, 2021 [13 favorites]
posted by madcaptenor at 3:33 PM on July 19, 2021 [13 favorites]
Every software engineering shop I’ve been in for the past few decades feels deeply attacked by this…
posted by mystyk at 3:33 PM on July 19, 2021 [4 favorites]
posted by mystyk at 3:33 PM on July 19, 2021 [4 favorites]
The worst scrum I ever worked in wasn't anything like the one described in this doc, and I don't know whether to be impressed or sad at how different the failure modes can be.
posted by fedward at 3:42 PM on July 19, 2021 [9 favorites]
posted by fedward at 3:42 PM on July 19, 2021 [9 favorites]
I sent this to my coworkers in our entirely not-coding-based profession (our team doesn't even technically use Scrum--we don't technically use anything, we are 11 golden retrievers pretending to be a company) and all of them were like Oh Fuck they're on to us.
posted by We put our faith in Blast Hardcheese at 3:53 PM on July 19, 2021 [27 favorites]
posted by We put our faith in Blast Hardcheese at 3:53 PM on July 19, 2021 [27 favorites]
My company is on the opposite coast from me. I'm too tired to scream during the 6:30 AM Daily Scream.
Yeah I'm grateful that my employer is headquartered in the Central time zone of the U.S. Not just because our HQ time is an ok compromise for our North American offices, but because it naturally encourages a
culture that time is relative and that it's important to schedule meetings around the personal and family schedules of the humans who have lives.
posted by traveler_ at 3:55 PM on July 19, 2021 [4 favorites]
Yeah I'm grateful that my employer is headquartered in the Central time zone of the U.S. Not just because our HQ time is an ok compromise for our North American offices, but because it naturally encourages a
culture that time is relative and that it's important to schedule meetings around the personal and family schedules of the humans who have lives.
posted by traveler_ at 3:55 PM on July 19, 2021 [4 favorites]
Don't have to be a developer on a scrum team to recognize every place I've ever worked:
The Scream Team consists of a Product Owner, the Development Team, and a Scream Master - plus their manager. Scream Teams are strictly controlled by their manager who requires them to proclaim they are self-organizing and cross-functional. The manager chooses how to assign and accomplish the work. The manager adds or subtracts people as needed to get just far enough to be “almost done”.
The team model in Scream is designed to optimize control, submission and being busy. The Scream Team has proven itself to be unquestioningly loyal for all the earlier stated uses, and any further abuse. Scream Teams build up frustration iteratively and incrementally, maximizing opportunities for outbursts of anger. Incremental deliveries of “Almost Done” (though totally useless) product ensure there’s a constant sense of guilt and threat within the team while the business gets nothing of value.
^ Literally the whole last 10 years of my life.
And the best part is in order to get out of jobs like this you have to somehow turn the actual bullshit that happened into an alternate universe fan fiction where you had any agency or control at any time.
posted by bleep at 4:22 PM on July 19, 2021 [11 favorites]
The Scream Team consists of a Product Owner, the Development Team, and a Scream Master - plus their manager. Scream Teams are strictly controlled by their manager who requires them to proclaim they are self-organizing and cross-functional. The manager chooses how to assign and accomplish the work. The manager adds or subtracts people as needed to get just far enough to be “almost done”.
The team model in Scream is designed to optimize control, submission and being busy. The Scream Team has proven itself to be unquestioningly loyal for all the earlier stated uses, and any further abuse. Scream Teams build up frustration iteratively and incrementally, maximizing opportunities for outbursts of anger. Incremental deliveries of “Almost Done” (though totally useless) product ensure there’s a constant sense of guilt and threat within the team while the business gets nothing of value.
^ Literally the whole last 10 years of my life.
And the best part is in order to get out of jobs like this you have to somehow turn the actual bullshit that happened into an alternate universe fan fiction where you had any agency or control at any time.
posted by bleep at 4:22 PM on July 19, 2021 [11 favorites]
I want to hear more about the 11 golden retrievers pretending to be a company.
posted by fedward at 4:32 PM on July 19, 2021 [29 favorites]
posted by fedward at 4:32 PM on July 19, 2021 [29 favorites]
I'm hoping some of them get to wear little suits
posted by nebulawindphone at 4:35 PM on July 19, 2021 [13 favorites]
posted by nebulawindphone at 4:35 PM on July 19, 2021 [13 favorites]
I'm hoping some of them get to wear little suits
We're all in one trench coat; it smells AWFUL
posted by We put our faith in Blast Hardcheese at 4:44 PM on July 19, 2021 [36 favorites]
We're all in one trench coat; it smells AWFUL
posted by We put our faith in Blast Hardcheese at 4:44 PM on July 19, 2021 [36 favorites]
Works best in a "matrix" organization.
And best post title evah!
posted by sammyo at 4:55 PM on July 19, 2021 [3 favorites]
And best post title evah!
posted by sammyo at 4:55 PM on July 19, 2021 [3 favorites]
I'm a new-ish certified Scrum Master (as much as "certified" means anything) and it actually suits a lot of my skills. Agile, done well, is actually a great system for getting things accomplished.
But definitely, Agile done badly is just an excuse to have way too many meetings. I actually pushed back on overscheduling people. We do have our daily meetings (they're scheduled for 15 minutes but they're more like 5 most days) but we were also setting asides like 6 hour blocks for people every other week for reviews, retrospectives and sprint planning. And that was waaaaaaaaaaay too much. That's now about 2 hours every other week and we manage to get all three things done in those two hours (and usually it isn't the entire two hours).
I think too many workplaces think if you're not having meetings, you're not working. But if you have too many meetings, you can't actually get any work done.
posted by edencosmic at 4:58 PM on July 19, 2021 [9 favorites]
But definitely, Agile done badly is just an excuse to have way too many meetings. I actually pushed back on overscheduling people. We do have our daily meetings (they're scheduled for 15 minutes but they're more like 5 most days) but we were also setting asides like 6 hour blocks for people every other week for reviews, retrospectives and sprint planning. And that was waaaaaaaaaaay too much. That's now about 2 hours every other week and we manage to get all three things done in those two hours (and usually it isn't the entire two hours).
I think too many workplaces think if you're not having meetings, you're not working. But if you have too many meetings, you can't actually get any work done.
posted by edencosmic at 4:58 PM on July 19, 2021 [9 favorites]
Does Scrum work best if people actually care about what they're doing? Because that's a pretty unrealistic burden to put on the workers in an entire sector of the economy.
posted by clawsoon at 5:10 PM on July 19, 2021 [9 favorites]
posted by clawsoon at 5:10 PM on July 19, 2021 [9 favorites]
Agile, done well, is actually a great system for getting things accomplished.
For 10 years this is all I've heard about Agile. And. It. Just doesn't work well unless every single person involved from the CEO down to the Scrum Master, buys into it, and has taken all the training and never deviates from that training.
Have a team who decides that 5 points is the max a task can be? No problem, the SM will just ask if you can take the already pared down task and further break it down. Could you for instance, have a ticket of 1 point where you create the header files and then a 2 point to ticket to write the main function? So you do and then when the sprint kicks off only the 2 point ticket is pulled in, because there are other more important tasks the CEO wanted and no one understands why you can't get your work done.
Don't get me started on an Epic called 'Unplanned work the CEO thought of 3 weeks after we planned the whole PI while on a yacht in Italy'
posted by 922257033c4a0f3cecdbd819a46d626999d1af4a at 5:29 PM on July 19, 2021 [23 favorites]
For 10 years this is all I've heard about Agile. And. It. Just doesn't work well unless every single person involved from the CEO down to the Scrum Master, buys into it, and has taken all the training and never deviates from that training.
Have a team who decides that 5 points is the max a task can be? No problem, the SM will just ask if you can take the already pared down task and further break it down. Could you for instance, have a ticket of 1 point where you create the header files and then a 2 point to ticket to write the main function? So you do and then when the sprint kicks off only the 2 point ticket is pulled in, because there are other more important tasks the CEO wanted and no one understands why you can't get your work done.
Don't get me started on an Epic called 'Unplanned work the CEO thought of 3 weeks after we planned the whole PI while on a yacht in Italy'
posted by 922257033c4a0f3cecdbd819a46d626999d1af4a at 5:29 PM on July 19, 2021 [23 favorites]
These links are making me cry.
posted by pompomtom at 5:39 PM on July 19, 2021 [1 favorite]
posted by pompomtom at 5:39 PM on July 19, 2021 [1 favorite]
In rugby, a scrum is a set-piece where two sets of people try to shove each other around, going nowhere and wasting substantial amounts of time. Eventually the whole thing collapses and the referee assigns blame at random.
posted by kersplunk at 5:53 PM on July 19, 2021 [53 favorites]
posted by kersplunk at 5:53 PM on July 19, 2021 [53 favorites]
The volume of anguish in the Scream increases shareholder value. It must, because otherwise I have no idea why this is done in so many companies around the world.
Me flailing around trying to figure out what the acceptance criteria for this story are, after it's been written, designed, groomed, and pulled into the sprint? That HAS to power some sort of ectoplasmic generator that turns frustration into bonuses for the important people.
posted by fifteen schnitzengruben is my limit at 5:57 PM on July 19, 2021 [9 favorites]
Me flailing around trying to figure out what the acceptance criteria for this story are, after it's been written, designed, groomed, and pulled into the sprint? That HAS to power some sort of ectoplasmic generator that turns frustration into bonuses for the important people.
posted by fifteen schnitzengruben is my limit at 5:57 PM on July 19, 2021 [9 favorites]
Agile was such an absolute shitshow where I work that the only thing remaining was the standups and the moving cards around in the mornings, and then we were doing that virtually, and then we stopped doing anything at all beyond a quick message in the morning: "Hey I'm doing X and a bit of Y today, savvy?" and that works perfectly fine for 99% of anything that ever happens in the world.
posted by turbid dahlia at 6:02 PM on July 19, 2021 [16 favorites]
posted by turbid dahlia at 6:02 PM on July 19, 2021 [16 favorites]
Every few years some asshole in Silicon Valley thinks they’ve reinvented the todo list. Sigh
posted by interogative mood at 6:06 PM on July 19, 2021 [14 favorites]
posted by interogative mood at 6:06 PM on July 19, 2021 [14 favorites]
The volume of anguish in the Scream increases shareholder value. It must, because otherwise I have no idea why this is done in so many companies around the world.
I am sorry to inform you that the Scream is not limited to organisations with shareholders.
posted by pompomtom at 6:13 PM on July 19, 2021 [4 favorites]
I am sorry to inform you that the Scream is not limited to organisations with shareholders.
posted by pompomtom at 6:13 PM on July 19, 2021 [4 favorites]
Before teams are ready to Scream, they must complete an obligatory “Sprint 0” where they spend as much time as possible sorting through the organizational mess which prevents them from doing any actual development work.
I'm going to keep this in my back pocket for the biannual "management's telling us to be agile" push. I have done so god damn many sprint zeros I can't even
Translating fixed requirements into a “User Stories” template, filling all the mandatory fields in the tracking tool;
My maenad origin story in one sentence
posted by snerson at 6:18 PM on July 19, 2021 [1 favorite]
I'm going to keep this in my back pocket for the biannual "management's telling us to be agile" push. I have done so god damn many sprint zeros I can't even
Translating fixed requirements into a “User Stories” template, filling all the mandatory fields in the tracking tool;
My maenad origin story in one sentence
posted by snerson at 6:18 PM on July 19, 2021 [1 favorite]
have a ticket of 1 point where you create the header files and then a 2 point to ticket to write the main function?
Nope. That is a fundamental misunderstanding of how it's supposed to work. A story has to be exactly that: a story. From the perspective of the end user. A user has to be able to achieve some task for it to be called a story. Users don't create header files. Users add a product to a cart, or filter a list by color, etc. If you're writing stories from the perspective of what the software does, you're doing it totally wrong.
posted by nushustu at 6:18 PM on July 19, 2021 [7 favorites]
Nope. That is a fundamental misunderstanding of how it's supposed to work. A story has to be exactly that: a story. From the perspective of the end user. A user has to be able to achieve some task for it to be called a story. Users don't create header files. Users add a product to a cart, or filter a list by color, etc. If you're writing stories from the perspective of what the software does, you're doing it totally wrong.
posted by nushustu at 6:18 PM on July 19, 2021 [7 favorites]
And if you have lots of fixed requirements, then you literally can't be agile. The entire purpose is to be able to change direction when you realize you need to change direction. Management can say they want you to be agile all they want, but they are the ones who have to accept it.
posted by nushustu at 6:21 PM on July 19, 2021 [8 favorites]
posted by nushustu at 6:21 PM on July 19, 2021 [8 favorites]
In rugby, a scrum is a set-piece where two sets of people try to shove each other around, going nowhere and wasting substantial amounts of time.
Also, occasionally someone tries to grab someone else's genitalia, or jam a thumb up someone's behind.
posted by TheWhiteSkull at 6:27 PM on July 19, 2021 [6 favorites]
Also, occasionally someone tries to grab someone else's genitalia, or jam a thumb up someone's behind.
posted by TheWhiteSkull at 6:27 PM on July 19, 2021 [6 favorites]
Scrumiting.
posted by silentbicycle at 6:42 PM on July 19, 2021 [10 favorites]
posted by silentbicycle at 6:42 PM on July 19, 2021 [10 favorites]
The fact that it opened in a view-only google doc rather than a webpage was already too much.
posted by silentbicycle at 6:44 PM on July 19, 2021 [14 favorites]
posted by silentbicycle at 6:44 PM on July 19, 2021 [14 favorites]
Nope. That is a fundamental misunderstanding of how it's supposed to work. A story has to be exactly that: a story. From the perspective of the end user. A user has to be able to achieve some task for it to be called a story. Users don't create header files. Users add a product to a cart, or filter a list by color, etc. If you're writing stories from the perspective of what the software does, you're doing it totally wrong.
Some day I'll find a company ( 5 so far ) that don't do it this way. One day I'll get to see that Agile is great if done right nirvana.
posted by 922257033c4a0f3cecdbd819a46d626999d1af4a at 6:56 PM on July 19, 2021 [1 favorite]
Some day I'll find a company ( 5 so far ) that don't do it this way. One day I'll get to see that Agile is great if done right nirvana.
posted by 922257033c4a0f3cecdbd819a46d626999d1af4a at 6:56 PM on July 19, 2021 [1 favorite]
posted by Slothrup at 7:01 PM on July 19, 2021 [17 favorites]
I hate agile, I hate scrum, and I hate pretending I know how to do either.
The day that I, a Senior designer, do not have to write my own user stories in JIRA bc the 100 PMs at my company are too nervous to do it before design starts even though that's how design starts = a glorious fucking day
posted by Hermione Granger at 7:04 PM on July 19, 2021 [9 favorites]
The day that I, a Senior designer, do not have to write my own user stories in JIRA bc the 100 PMs at my company are too nervous to do it before design starts even though that's how design starts = a glorious fucking day
posted by Hermione Granger at 7:04 PM on July 19, 2021 [9 favorites]
Agile and Design are sworn enemies. Agile kills holistic design. Sure you can work around it but then you’re no longer agile.
posted by misterpatrick at 7:24 PM on July 19, 2021 [3 favorites]
posted by misterpatrick at 7:24 PM on July 19, 2021 [3 favorites]
I am going to run out of favorites in here, y'all.
I feel so seen.
posted by Alterscape at 7:26 PM on July 19, 2021 [5 favorites]
I feel so seen.
posted by Alterscape at 7:26 PM on July 19, 2021 [5 favorites]
The day that I, a Senior designer, do not have to write my own user stories in JIRA bc the 100 PMs at my company are too nervous to do it before design starts even though that's how design starts = a glorious fucking day
I will say we finally _finally_ got the PM to make sure design is done one full sprint ahead of development work. Took 4.5 years but hey small victories.
posted by 922257033c4a0f3cecdbd819a46d626999d1af4a at 7:33 PM on July 19, 2021 [3 favorites]
I will say we finally _finally_ got the PM to make sure design is done one full sprint ahead of development work. Took 4.5 years but hey small victories.
posted by 922257033c4a0f3cecdbd819a46d626999d1af4a at 7:33 PM on July 19, 2021 [3 favorites]
Is the guide somewhere that isn’t gdocs? ‘Cause that’s pretty ironic.
posted by snuffleupagus at 7:33 PM on July 19, 2021 [3 favorites]
posted by snuffleupagus at 7:33 PM on July 19, 2021 [3 favorites]
I'm a new-ish certified Scrum Master (as much as "certified" means anything) and it actually suits a lot of my skills.
What's involved in scrum master/mistress training? After working in Agile shops for almost twenty years, I feel like I could be one.
Also, what are female scrum masters called?
posted by bendy at 7:49 PM on July 19, 2021 [1 favorite]
What's involved in scrum master/mistress training? After working in Agile shops for almost twenty years, I feel like I could be one.
Also, what are female scrum masters called?
posted by bendy at 7:49 PM on July 19, 2021 [1 favorite]
*Sigh* I can't believe you guys aren't using LAFABLE yet: Large Agile Framework Appropriate for Big, Lumbering Enterprises.
posted by TheophileEscargot at 8:10 PM on July 19, 2021 [8 favorites]
posted by TheophileEscargot at 8:10 PM on July 19, 2021 [8 favorites]
Our female scrum master was just called a scrum master. We mostly called her by her name, though, which was better than any job-based epithet she might have earned. The company decision(1) to force us into an ill-advised scrum(2) and bring her in to run it wasn't her fault, but her utter failure to understand the compliance constraints(3) we had to work under sure was.
(1) The problem this was supposed to solve was that our release cycles took too long, at six weeks per release. The reason they took so long was not dev, it was QA. In a six week cycle we'd end up finishing our queue early and then we'd have a week of no work (sometimes two), because if we started work on the next release it would just get bogged down later in QA. Our releases were, in fact, sized for QA and not code velocity. We pointed out that we could do two week cycles instead of six week cycles and the problem would still be QA, but instead the higher ups decided we needed to be a scrum team.
(2) Seventeen people in one scrum team. Seventeen. Five developers, our manager, a couple DBAs and a couple dev ops for some reason, and the rest QA(4).
(3) Developers couldn't do QA; QA had to do QA. So there was no cross-approval of code between devs, everything had to be committed for QA to test. Devs had to be available to fix bugs identified in QA and occasionally do rework, but no dev could ever do the actual work of QA.
(4) You know what QA couldn't do in a two week sprint? Review code written during that same two week sprint. First the scrum master tried to make everything work in one sprint (after she finally understood that devs really couldn't do QA), but eventually even she understood that having everybody work on the same code during the same sprint meant that the first week QA had nothing to do, and the second week the devs had nothing to do. So then our sprints became two different sprints still run out of the same standups, where dev would always be a sprint ahead, but for some reason all 17 of us were still there every day. Nominally this was for the bugs and rework, but really all seventeen of us had our time wasted every day.
posted by fedward at 8:27 PM on July 19, 2021 [8 favorites]
(1) The problem this was supposed to solve was that our release cycles took too long, at six weeks per release. The reason they took so long was not dev, it was QA. In a six week cycle we'd end up finishing our queue early and then we'd have a week of no work (sometimes two), because if we started work on the next release it would just get bogged down later in QA. Our releases were, in fact, sized for QA and not code velocity. We pointed out that we could do two week cycles instead of six week cycles and the problem would still be QA, but instead the higher ups decided we needed to be a scrum team.
(2) Seventeen people in one scrum team. Seventeen. Five developers, our manager, a couple DBAs and a couple dev ops for some reason, and the rest QA(4).
(3) Developers couldn't do QA; QA had to do QA. So there was no cross-approval of code between devs, everything had to be committed for QA to test. Devs had to be available to fix bugs identified in QA and occasionally do rework, but no dev could ever do the actual work of QA.
(4) You know what QA couldn't do in a two week sprint? Review code written during that same two week sprint. First the scrum master tried to make everything work in one sprint (after she finally understood that devs really couldn't do QA), but eventually even she understood that having everybody work on the same code during the same sprint meant that the first week QA had nothing to do, and the second week the devs had nothing to do. So then our sprints became two different sprints still run out of the same standups, where dev would always be a sprint ahead, but for some reason all 17 of us were still there every day. Nominally this was for the bugs and rework, but really all seventeen of us had our time wasted every day.
posted by fedward at 8:27 PM on July 19, 2021 [8 favorites]
we stopped doing anything at all beyond a quick message in the morning: "Hey I'm doing X and a bit of Y today, savvy?" and that works perfectly fine for 99% of anything that ever happens in the world.
LOLOLOLOL. Know what that is? The first effing line of the agile manifesto.
Agile never works in hierarchical organizations because they think it's a process to be implemented, when it's the complete opposite.
It's pretty basic. Have a set of goals or objectives. Make sure everyone knows the goals and objectives. Encourage everyone to communicate what they're planning to do. Let people figure out how to work together (and maybe train them in how to communicate and collaborate--people don't really know this without help). Let people solve the problems. That's basically it.
("make money" is generally a poor choice of a goal, which means most companies are screwed. if you have a thing you want to do and earning money is necessary to allow you to keep doing the thing, you might be OK.)
Unfortunately, the above doesn't have people in control, so the typical control freaks in charge of companies make sure the above never happens.
I think agile is beautiful, but I also think it's a pipe dream for the most part.
-----
The summary of the summary of the summary:
People are a problem.
posted by Ickster at 9:09 PM on July 19, 2021 [15 favorites]
LOLOLOLOL. Know what that is? The first effing line of the agile manifesto.
Agile never works in hierarchical organizations because they think it's a process to be implemented, when it's the complete opposite.
It's pretty basic. Have a set of goals or objectives. Make sure everyone knows the goals and objectives. Encourage everyone to communicate what they're planning to do. Let people figure out how to work together (and maybe train them in how to communicate and collaborate--people don't really know this without help). Let people solve the problems. That's basically it.
("make money" is generally a poor choice of a goal, which means most companies are screwed. if you have a thing you want to do and earning money is necessary to allow you to keep doing the thing, you might be OK.)
Unfortunately, the above doesn't have people in control, so the typical control freaks in charge of companies make sure the above never happens.
I think agile is beautiful, but I also think it's a pipe dream for the most part.
-----
The summary of the summary of the summary:
People are a problem.
posted by Ickster at 9:09 PM on July 19, 2021 [15 favorites]
The fundamental question is always “Are you Agile or are you agile?”
If your organisational culture does not support agility and empowerment then you may as well use cave paintings or ritual combat as a delivery mechanism. “Agile” will make no difference.
I’ve led the delivery of very very large and complex services using agile techniques. It works, there is really no other way, and it is hugely demanding on the people and the organisations involved. It’s simpler for all concerned to set up a few token rituals like SCRUMS which are just as fetishised as GANTT charts or risk registers are in other methodologies.
posted by fallingbadgers at 10:16 PM on July 19, 2021 [4 favorites]
If your organisational culture does not support agility and empowerment then you may as well use cave paintings or ritual combat as a delivery mechanism. “Agile” will make no difference.
I’ve led the delivery of very very large and complex services using agile techniques. It works, there is really no other way, and it is hugely demanding on the people and the organisations involved. It’s simpler for all concerned to set up a few token rituals like SCRUMS which are just as fetishised as GANTT charts or risk registers are in other methodologies.
posted by fallingbadgers at 10:16 PM on July 19, 2021 [4 favorites]
My current employer is actually running Agile, as far as I can tell. At the very least, our team's looking after our bit of the app, getting user feedback and implementing changes that users seem to appreciate.
One of the keys to it, I'm told, was that they had to train the company leadership that they couldn't offer suggestions or feature requests. Given the whole point of running a company is that you get to tell people what to do, this was a hard problem to solve!
Also you need product managers who do actually understand what they're doing - one role I was in, the product manager was doing Scrum and had a lovely design to implement something that a) depended on another part of the business and b) was technically impossible for them to do. It was a bit of a trainwreck.
posted by Merus at 2:35 AM on July 20, 2021 [5 favorites]
One of the keys to it, I'm told, was that they had to train the company leadership that they couldn't offer suggestions or feature requests. Given the whole point of running a company is that you get to tell people what to do, this was a hard problem to solve!
Also you need product managers who do actually understand what they're doing - one role I was in, the product manager was doing Scrum and had a lovely design to implement something that a) depended on another part of the business and b) was technically impossible for them to do. It was a bit of a trainwreck.
posted by Merus at 2:35 AM on July 20, 2021 [5 favorites]
One of the delights, privileges even, of MetaFilter is the way it opens up new worlds. It is especially important when these worlds are the living breathing reality of my fellow man. How can I begin to know who I am if I don't know who you are and what life you live? How can I understand my own world? Loquacious wrote a stunning, brutal paen of truth and praise to the dishwasher and showed me life in a professional kitchen that I'd never glimpsed. Even when the worlds might readily serve as nastier back rooms for the seriously and serially evil in Dante's Inferno, their depiction is a gift.
Scream was no more or less likely/feasible than Scrum, on or off the rugby field or in a heated exclamation from my Mum in the Christmas sales. Agile was sister to nimble. I hadn't heard of any of them. I looked them up. My God. How do you satirise this stuff? "Dystopian nightmare" doesn't cut it - my nuts made a run for it and are hiding out in my arm pits somewhere. Is there a Martin Bormann School of Management? Do people speak like this? Think like this? Behave like this? Live like this? I read the comments. I now know they do and I wince for you. I really do. It is inhuman.
And I count my goose pimpled blessings that I'm a fossil, that I wrote my phd on paper with a fountain pen, that I spent all that time under the desk, scrabbling about, uncrumpling discarded sentences on crumpled sheets, scissoring lines and paragraphs and sellotaping it all together in 'continuous' pages yards long, chasing my toddler who'd run off with precious scraps delighted to be playing the best game ever with his Dad, that meetings at the university were for 5 minutes in the corridor on the way to the bathroom, that my first Head of Department told me to stop writing, "you can't be expected to know anything yet....have you read X,Y,Z? Do some serious reading. Let's chat in 6 weeks." I thought it was hell, it was paradise!!
posted by dutchrick at 3:57 AM on July 20, 2021 [12 favorites]
Scream was no more or less likely/feasible than Scrum, on or off the rugby field or in a heated exclamation from my Mum in the Christmas sales. Agile was sister to nimble. I hadn't heard of any of them. I looked them up. My God. How do you satirise this stuff? "Dystopian nightmare" doesn't cut it - my nuts made a run for it and are hiding out in my arm pits somewhere. Is there a Martin Bormann School of Management? Do people speak like this? Think like this? Behave like this? Live like this? I read the comments. I now know they do and I wince for you. I really do. It is inhuman.
And I count my goose pimpled blessings that I'm a fossil, that I wrote my phd on paper with a fountain pen, that I spent all that time under the desk, scrabbling about, uncrumpling discarded sentences on crumpled sheets, scissoring lines and paragraphs and sellotaping it all together in 'continuous' pages yards long, chasing my toddler who'd run off with precious scraps delighted to be playing the best game ever with his Dad, that meetings at the university were for 5 minutes in the corridor on the way to the bathroom, that my first Head of Department told me to stop writing, "you can't be expected to know anything yet....have you read X,Y,Z? Do some serious reading. Let's chat in 6 weeks." I thought it was hell, it was paradise!!
posted by dutchrick at 3:57 AM on July 20, 2021 [12 favorites]
One of the keys to it, I'm told, was that they had to train the company leadership that they couldn't offer suggestions or feature requests. Given the whole point of running a company is that you get to tell people what to do, this was a hard problem to solve!Ok, this seems honestly bizarre to me, since I've got no firsthand experience with this stuff. In "real Agile," what do the people running a software company do? What decisions are they allowed to make, if they can't even suggest new features?
posted by nebulawindphone at 4:19 AM on July 20, 2021 [3 favorites]
Where I am, we've moved away from "scrum masters" due to the problematic history of "master," and now we have Agile Delivery Leads. Scrum still doesn't make much sense for my hybrid team of designers and developers.
posted by emelenjr at 4:29 AM on July 20, 2021 [2 favorites]
posted by emelenjr at 4:29 AM on July 20, 2021 [2 favorites]
Agile is the Cargo Cult of development methodologies. Organizations buy into this idea that if they follow a bunch of rituals it will lead to success without understanding the point/value of those actions. The stand up meetings I was involved with in my last few years were about as useful as if everyone stood around with coconuts on their heads waiting for radio signals. But I'm an old and have retired now - Scram!
posted by whatevernot at 4:39 AM on July 20, 2021 [21 favorites]
posted by whatevernot at 4:39 AM on July 20, 2021 [21 favorites]
My training was a two-day class (virtual in this case) my employer paid for. I actually learned a lot! But I think being "certified" is basically meaningless, honestly.
posted by edencosmic at 5:13 AM on July 20, 2021 [3 favorites]
posted by edencosmic at 5:13 AM on July 20, 2021 [3 favorites]
The other way of doing this is to have a manager/director/boss who knows the system you are working in to a high degree and who then drives, with feedback, a series of goals forward that are needed.
Sadly so many managers seem to be slot-in external hires that are assigned to five hours of meetings about metrics and have no time to learn the system they lead.
posted by Slackermagee at 5:37 AM on July 20, 2021 [2 favorites]
Sadly so many managers seem to be slot-in external hires that are assigned to five hours of meetings about metrics and have no time to learn the system they lead.
posted by Slackermagee at 5:37 AM on July 20, 2021 [2 favorites]
But I think being "certified" is basically meaningless, honestly.
Unless you're Frances Farmer.
posted by Cardinal Fang at 6:26 AM on July 20, 2021 [1 favorite]
Unless you're Frances Farmer.
posted by Cardinal Fang at 6:26 AM on July 20, 2021 [1 favorite]
But I think being "certified" is basically meaningless, honestly.
After thirty years in IT, I can tell you: certification, in general, is meaningless. There are plenty of people who go out and take a boot camp for a week that teaches the test. For $1000-3000, they can then update their resume with "Certified in PRODUCT OR METHODOLOGY." At best, it means they'll vaguely recall what they need to Google.
If it's a product (like Microsoft or AWS certification), it's basically advertising: "you can get support from thousands of certified professionals."
If it's a methodology, it increases the buzz and market. More certified people on your team means the methodology is used more. Other teams want to use it, so you need to hire more certified professionals. Oh--and let's not forget buying the Official Guides and methodology-compliant tool sets.
I absolutely know there are experienced professionals out there who bring years of experience in the skillset to the table, worked on every version since 1.0, and know it inside and out. They'll study to cover any esoteric features no one actually (or rarely) uses, take the test, and pass. One would hope their resume would help them rise above the Boot Camp Bois. Unfortunately, I think recruiters don't see the difference.
posted by MrGuilt at 6:42 AM on July 20, 2021 [8 favorites]
After thirty years in IT, I can tell you: certification, in general, is meaningless. There are plenty of people who go out and take a boot camp for a week that teaches the test. For $1000-3000, they can then update their resume with "Certified in PRODUCT OR METHODOLOGY." At best, it means they'll vaguely recall what they need to Google.
If it's a product (like Microsoft or AWS certification), it's basically advertising: "you can get support from thousands of certified professionals."
If it's a methodology, it increases the buzz and market. More certified people on your team means the methodology is used more. Other teams want to use it, so you need to hire more certified professionals. Oh--and let's not forget buying the Official Guides and methodology-compliant tool sets.
I absolutely know there are experienced professionals out there who bring years of experience in the skillset to the table, worked on every version since 1.0, and know it inside and out. They'll study to cover any esoteric features no one actually (or rarely) uses, take the test, and pass. One would hope their resume would help them rise above the Boot Camp Bois. Unfortunately, I think recruiters don't see the difference.
posted by MrGuilt at 6:42 AM on July 20, 2021 [8 favorites]
what do the people running a software company do? What decisions are they allowed to make, if they can't even suggest new features?
They make financial decisions. They hire, they make marketing budget decisions, and set max budgets (if the budget is open-ended, you don't really need agile). They can suggest new product lines, or enhancements to existing products that align with the financial and marketing decisions they make.
Or the opposite of Agile is they make all the decisions up front, and then everybody codes to that standard for 4 months and tests for 2 months. New releases every 6 weeks? More like 3X a year.
posted by The_Vegetables at 7:38 AM on July 20, 2021 [1 favorite]
They make financial decisions. They hire, they make marketing budget decisions, and set max budgets (if the budget is open-ended, you don't really need agile). They can suggest new product lines, or enhancements to existing products that align with the financial and marketing decisions they make.
Or the opposite of Agile is they make all the decisions up front, and then everybody codes to that standard for 4 months and tests for 2 months. New releases every 6 weeks? More like 3X a year.
posted by The_Vegetables at 7:38 AM on July 20, 2021 [1 favorite]
For one of the most successful teams I've managed, I:
a) hired 2 people I know and trust and had trained myself.
b) hired 1 other I didn't know but was recommended by somebody I trust and interviewed her and felt like she knew what she was talking about.
c) laid out a yearly plan together with the team, with specific milestones.
d) stepped back and let them work.
e) met with them about once a month.
f) was available for when they got stuck and needed me to help them make specific decisions or solve specific problems.
g) basked in the reflected glow of their success.
The most important step, IMO, is hiring people you trust to get the job done. No amount of methods or meetings or whiteboards or post-its will help you if you don't trust your team.
posted by signal at 7:52 AM on July 20, 2021 [8 favorites]
a) hired 2 people I know and trust and had trained myself.
b) hired 1 other I didn't know but was recommended by somebody I trust and interviewed her and felt like she knew what she was talking about.
c) laid out a yearly plan together with the team, with specific milestones.
d) stepped back and let them work.
e) met with them about once a month.
f) was available for when they got stuck and needed me to help them make specific decisions or solve specific problems.
g) basked in the reflected glow of their success.
The most important step, IMO, is hiring people you trust to get the job done. No amount of methods or meetings or whiteboards or post-its will help you if you don't trust your team.
posted by signal at 7:52 AM on July 20, 2021 [8 favorites]
c) laid out a yearly plan together with the team, with specific milestones.
d) stepped back and let them work.
e) met with them about once a month.
f) was available for when they got stuck and needed me to help them make specific decisions or solve specific problems.,
You sound like a team leader/people manager, which is not the same as a scrum master/scrum team. The agile team is the people your employees are working with on a daily basis, grouped into a formal team as long as the work lasts. But the daily team is not doing upper mgmt stuff for them, like hiring or doing performance evaluations. That's still you.
posted by The_Vegetables at 8:03 AM on July 20, 2021
d) stepped back and let them work.
e) met with them about once a month.
f) was available for when they got stuck and needed me to help them make specific decisions or solve specific problems.,
You sound like a team leader/people manager, which is not the same as a scrum master/scrum team. The agile team is the people your employees are working with on a daily basis, grouped into a formal team as long as the work lasts. But the daily team is not doing upper mgmt stuff for them, like hiring or doing performance evaluations. That's still you.
posted by The_Vegetables at 8:03 AM on July 20, 2021
They make financial decisions. They hire, they make marketing budget decisions, and set max budgets (if the budget is open-ended, you don't really need agile). They can suggest new product lines, or enhancements to existing products that align with the financial and marketing decisions they make.Yeah, to be clear, I'm not arguing against Agile or arguing in favor of some heinous misinterpretation of Agile. I'm not an engineer and this is all outside my knowledge. It just... on the planet where I do live, it would be surreal to suggest that the owner write budgets, hire staff, sign checks, and stay out of the rest.
Or the opposite of Agile is they make all the decisions up front, and then everybody codes to that standard for 4 months and tests for 2 months. New releases every 6 weeks? More like 3X a year.
What happens if a client comes to them and says "We need feature X or we're going to your competitor"? Do they say "It's out of my hands"? Or "Uh, I guess we should wait and see if the development team comes up with the same idea independently"? I assume there's a better answer than that, but I'm struggling to see what it would be under these rules.
posted by nebulawindphone at 8:05 AM on July 20, 2021 [1 favorite]
Agile doesn’t create an ivory tower unconstrained by business requirements or budget. Agile teams are working below the organizational level the CEO operates at. Projects still have goals and deliverables, they get turned into user stories by the project manager (“product owner”), you just build the minimum viable product and then iterate to get there rather than doing Big Design Upfront and a cascading waterfall of milestones.
It can be justified along the same lines as any other management strategy, and it only has to clear the fairly low bar of the duty of care in a derivative action, under the business judgment rule.
That said, it isn’t all that compatible with traditional contracting regimes that depend on milestones, like game dev.
What I’ve never been clear on is the distinction between Agile and XP, except for trademarks.
posted by snuffleupagus at 8:19 AM on July 20, 2021 [2 favorites]
It can be justified along the same lines as any other management strategy, and it only has to clear the fairly low bar of the duty of care in a derivative action, under the business judgment rule.
That said, it isn’t all that compatible with traditional contracting regimes that depend on milestones, like game dev.
What I’ve never been clear on is the distinction between Agile and XP, except for trademarks.
posted by snuffleupagus at 8:19 AM on July 20, 2021 [2 favorites]
what do the people running a software company do? What decisions are they allowed to make, if they can't even suggest new features?
The problem isn't that they can't suggest new features, it's that they can't interrupt the cycle to add whatever they're excited about right now. If you're doing work that requires intense focus, multitasking is wasteful.
The common leadership failure mode I've seen is a failure to stick to long term priorities, and/or an environment where political winds change faster than the release cycle. Even though we were focused on Alice's highest priority stuff, Bob is now pulling rank and we have to do his thing instead. Decades ago the org I was in moved to a system where any ticket had to be assigned a numeric priority from 1 (highest) to 5 (lowest). But then some exec would get a bee in his bonnet and whatever that guy wanted would be priority 0, preempting however many priority 1 tickets, and yes, we appreciated the irony ("sure, I'll assign zero priority to that"). The best version of this was when they'd already thrown a priority 0 thing at us and then they threw two more at us in the same week.
The way you keep developers productive is to have an organized task queue where they can finish whatever they're working on and grab the next thing in the queue, finish that, and then grab the thing after that. What agile is supposed to do is provide a way to organize that queue so your developers always have a next thing, but the rest of the org has some idea of when any given item in the queue can be expected to be done (and the ability to adjust priorities for future development). If you have a defined sprint (e.g. two weeks), you're setting an expectation of a particular code/feature velocity, and at the end of it you're also supposed to be verifying the velocity and using that to adjust how you estimate things in the future.
What you're not supposed to do is change current tasks. You can reshuffle what's coming in the next cycle but you should be leaving the current cycle alone. If you're on a two week sprint you should take that exec's new feature and add it to the backlog for the next sprint, as long as the exec can wait. But often they can't (or won't), because they assume that (A) whatever they're asking can be done quickly (sometimes false), and (2) regardless of how long the new task does or doesn't take there won't be any effect on the rest of the queue (always false).
While a lot of scrum jargon makes my teeth hurt ("user stories" and "story points" somehow seem infantilizing, as useful as they are, and certification means nothing to me) it can be a pretty good way for a development team to manage up. It's a way of saying "we're working on these things right now and they'll be done by next Friday as long as you don't interrupt us." As long as you really do get everything in your sprint done on time, you can set expectations for delivery of the stuff in future sprints as long as the stories really do describe what they say they do. But your management has to be able to wait a few weeks for new features every now and then for any of it to work. On that front: good luck.
posted by fedward at 8:51 AM on July 20, 2021 [11 favorites]
The problem isn't that they can't suggest new features, it's that they can't interrupt the cycle to add whatever they're excited about right now. If you're doing work that requires intense focus, multitasking is wasteful.
The common leadership failure mode I've seen is a failure to stick to long term priorities, and/or an environment where political winds change faster than the release cycle. Even though we were focused on Alice's highest priority stuff, Bob is now pulling rank and we have to do his thing instead. Decades ago the org I was in moved to a system where any ticket had to be assigned a numeric priority from 1 (highest) to 5 (lowest). But then some exec would get a bee in his bonnet and whatever that guy wanted would be priority 0, preempting however many priority 1 tickets, and yes, we appreciated the irony ("sure, I'll assign zero priority to that"). The best version of this was when they'd already thrown a priority 0 thing at us and then they threw two more at us in the same week.
The way you keep developers productive is to have an organized task queue where they can finish whatever they're working on and grab the next thing in the queue, finish that, and then grab the thing after that. What agile is supposed to do is provide a way to organize that queue so your developers always have a next thing, but the rest of the org has some idea of when any given item in the queue can be expected to be done (and the ability to adjust priorities for future development). If you have a defined sprint (e.g. two weeks), you're setting an expectation of a particular code/feature velocity, and at the end of it you're also supposed to be verifying the velocity and using that to adjust how you estimate things in the future.
What you're not supposed to do is change current tasks. You can reshuffle what's coming in the next cycle but you should be leaving the current cycle alone. If you're on a two week sprint you should take that exec's new feature and add it to the backlog for the next sprint, as long as the exec can wait. But often they can't (or won't), because they assume that (A) whatever they're asking can be done quickly (sometimes false), and (2) regardless of how long the new task does or doesn't take there won't be any effect on the rest of the queue (always false).
While a lot of scrum jargon makes my teeth hurt ("user stories" and "story points" somehow seem infantilizing, as useful as they are, and certification means nothing to me) it can be a pretty good way for a development team to manage up. It's a way of saying "we're working on these things right now and they'll be done by next Friday as long as you don't interrupt us." As long as you really do get everything in your sprint done on time, you can set expectations for delivery of the stuff in future sprints as long as the stories really do describe what they say they do. But your management has to be able to wait a few weeks for new features every now and then for any of it to work. On that front: good luck.
posted by fedward at 8:51 AM on July 20, 2021 [11 favorites]
What I’ve never been clear on is the distinction between Agile and XP
Agile is an umbrella term for a number of software development methodologies, that aim to be more responsive to change and less bureaucratic than traditional "waterfall" development.
XP, Kanban and Scrum are all particular methodologies that fit within agile.
Between those methodologies, Scrum is one of the more bureaucratic ones that still class as "agile".
Basically the bigger the project, the more people you have working on it, the more bureaucracy you need.
But organisations often tend to add unnecessary bureaucracy. That happens particularly with Scrum. I think because bureaucratic organisations tend to think "Crap, we need to jump on this Agile bandwagon, what's the least agile and most bureaucratic version of it we can find?"
I am a Scrum Master and I think for medium-sized projects, Scrum is as good as any other methodology and better than most.
But a bad corporate culture or a bad team will make a mess out of any methodology.
It's a bit like expensive cookwear. If you're a good cook, you can make a nice meal despite flimsy aluminium pans and cheap knives. If you're a bad cook, you're going to make a bad meal even with expensive Le Creuset pans and the finest Japanese carbon steel knives.
The right methodology makes your life a bit easier but it doesn't primarily determine the output.
posted by TheophileEscargot at 8:59 AM on July 20, 2021 [8 favorites]
Agile is an umbrella term for a number of software development methodologies, that aim to be more responsive to change and less bureaucratic than traditional "waterfall" development.
XP, Kanban and Scrum are all particular methodologies that fit within agile.
Between those methodologies, Scrum is one of the more bureaucratic ones that still class as "agile".
Basically the bigger the project, the more people you have working on it, the more bureaucracy you need.
But organisations often tend to add unnecessary bureaucracy. That happens particularly with Scrum. I think because bureaucratic organisations tend to think "Crap, we need to jump on this Agile bandwagon, what's the least agile and most bureaucratic version of it we can find?"
I am a Scrum Master and I think for medium-sized projects, Scrum is as good as any other methodology and better than most.
But a bad corporate culture or a bad team will make a mess out of any methodology.
It's a bit like expensive cookwear. If you're a good cook, you can make a nice meal despite flimsy aluminium pans and cheap knives. If you're a bad cook, you're going to make a bad meal even with expensive Le Creuset pans and the finest Japanese carbon steel knives.
The right methodology makes your life a bit easier but it doesn't primarily determine the output.
posted by TheophileEscargot at 8:59 AM on July 20, 2021 [8 favorites]
The problem isn't that they can't suggest new features, it's that they can't interrupt the cycle to add whatever they're excited about right now. If you're doing work that requires intense focus
Worked with a company that was 100% on-board with this until the VP in charge was told no a second time. Suddenly we were from then on a Waterfall shop.
posted by 922257033c4a0f3cecdbd819a46d626999d1af4a at 9:13 AM on July 20, 2021 [2 favorites]
Worked with a company that was 100% on-board with this until the VP in charge was told no a second time. Suddenly we were from then on a Waterfall shop.
posted by 922257033c4a0f3cecdbd819a46d626999d1af4a at 9:13 AM on July 20, 2021 [2 favorites]
If you want to know what agile is supposed to be, just read the manifesto. It's short, so I'll just paste the gist here:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
If teams are being given tasks because someone is negotiating with the customer about features and cost, most of the benefit is being lost. Instead, teams should be working with the customer.
If teams are working a task backlog to get to a deliverable feature set at some point in the future rather than producing new value all the time, most of the benefit is lost.
If teams are in meetings because the holy bible of Scrum says they should follow the process, most of the value is being lost.
If a company is 'making development agile' without changing the rest of the organization, they're just wasting time and effort.
It's simple, but it sure ain't easy.
As much as the agile manifesto resonates with me, I'd really like to see organizations stop trying to be 'Agile'. I'd settle for them looking at what they're doing and asking, "What can we take away that would make us better at what we do?" Ask the question, execute on the answer, and repeat. Eventually they'd probably look agile, but honestly, who cares about the label?
posted by Ickster at 9:31 AM on July 20, 2021 [4 favorites]
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
If teams are being given tasks because someone is negotiating with the customer about features and cost, most of the benefit is being lost. Instead, teams should be working with the customer.
If teams are working a task backlog to get to a deliverable feature set at some point in the future rather than producing new value all the time, most of the benefit is lost.
If teams are in meetings because the holy bible of Scrum says they should follow the process, most of the value is being lost.
If a company is 'making development agile' without changing the rest of the organization, they're just wasting time and effort.
It's simple, but it sure ain't easy.
As much as the agile manifesto resonates with me, I'd really like to see organizations stop trying to be 'Agile'. I'd settle for them looking at what they're doing and asking, "What can we take away that would make us better at what we do?" Ask the question, execute on the answer, and repeat. Eventually they'd probably look agile, but honestly, who cares about the label?
posted by Ickster at 9:31 AM on July 20, 2021 [4 favorites]
Every few years some asshole in Silicon Valley thinks they’ve reinvented the todo list. Sigh
Well... IIRC, Agile did not come from Silicon Valley and commercial product development industry - it came from consulting - specifically in the "Enterprise" realm of bespoke applications. (Someone correct me if I am wrong, but were not some of the core people involved essentially an internal product team for GM ? Or was that only for TDD/XP and Pair Programming?)
posted by rozcakj at 9:35 AM on July 20, 2021
Well... IIRC, Agile did not come from Silicon Valley and commercial product development industry - it came from consulting - specifically in the "Enterprise" realm of bespoke applications. (Someone correct me if I am wrong, but were not some of the core people involved essentially an internal product team for GM ? Or was that only for TDD/XP and Pair Programming?)
posted by rozcakj at 9:35 AM on July 20, 2021
Chrysler. If memory serves, run by Ward Cunningham of the C2 Wiki (and Portland Pattern Repository).
Although I think that was XP not Agile.
Edit: looks like one of Cunningham's colleagues and/or proteges, rather.
The C2 page on C3's termination.
posted by snuffleupagus at 9:49 AM on July 20, 2021 [2 favorites]
Although I think that was XP not Agile.
Edit: looks like one of Cunningham's colleagues and/or proteges, rather.
The C2 page on C3's termination.
posted by snuffleupagus at 9:49 AM on July 20, 2021 [2 favorites]
I’ve been a scrum master before, and I’m still disappointed the role doesn’t come with leather and a crop.
posted by gelfin at 9:56 AM on July 20, 2021 [12 favorites]
posted by gelfin at 9:56 AM on July 20, 2021 [12 favorites]
Last I checked, Fetlife is hiring front-end developers. Though it sounds like you might be looking for back-end work.
posted by snuffleupagus at 9:58 AM on July 20, 2021 [16 favorites]
posted by snuffleupagus at 9:58 AM on July 20, 2021 [16 favorites]
Well... IIRC, Agile did not come from Silicon Valley
I think the term 'Silicon Valley' has come to be used to describe a mindset rather than a geographical location.
posted by Cardinal Fang at 10:36 AM on July 20, 2021 [4 favorites]
I think the term 'Silicon Valley' has come to be used to describe a mindset rather than a geographical location.
posted by Cardinal Fang at 10:36 AM on July 20, 2021 [4 favorites]
If teams are being given tasks because someone is negotiating with the customer about features and cost, most of the benefit is being lost. Instead, teams should be working with the customer.
Wait, are you saying the whole team should be working directly with the customer, or that the product portion of the team should do that part, while the developers mostly, uh, develop? Too much direct developer interaction with the customer can be deadly to code velocity between scope creep, perfect-is-the-enemy-of-good, and context switching costs. Some amount of intermediation is valuable just to let people do the jobs they're good at.
If teams are working a task backlog to get to a deliverable feature set at some point in the future rather than producing new value all the time, most of the benefit is lost.
If your backlog is so bad that catching up with it isn't producing value, then you maybe have things on your backlog you shouldn't have or you haven't broken it out into the right units. But that's not an agility issue, and is true of the backlog in any organization that makes software.
posted by fedward at 10:42 AM on July 20, 2021 [2 favorites]
Wait, are you saying the whole team should be working directly with the customer, or that the product portion of the team should do that part, while the developers mostly, uh, develop? Too much direct developer interaction with the customer can be deadly to code velocity between scope creep, perfect-is-the-enemy-of-good, and context switching costs. Some amount of intermediation is valuable just to let people do the jobs they're good at.
If teams are working a task backlog to get to a deliverable feature set at some point in the future rather than producing new value all the time, most of the benefit is lost.
If your backlog is so bad that catching up with it isn't producing value, then you maybe have things on your backlog you shouldn't have or you haven't broken it out into the right units. But that's not an agility issue, and is true of the backlog in any organization that makes software.
posted by fedward at 10:42 AM on July 20, 2021 [2 favorites]
fedward: The way you keep developers productive is to have an organized task queue where they can finish whatever they're working on and grab the next thing in the queue, finish that, and then grab the thing after that.
This is the one thing I have tried to accomplish in my current job for all the developers I work with. I think we've basically established the principle with everybody we have meetings with. Thankfully we're not a software dev shop as such, so people in upper management don't really care about us and nobody (so far) has been doing the dumb pulling rank priority 0 thing.
posted by clawsoon at 10:52 AM on July 20, 2021
This is the one thing I have tried to accomplish in my current job for all the developers I work with. I think we've basically established the principle with everybody we have meetings with. Thankfully we're not a software dev shop as such, so people in upper management don't really care about us and nobody (so far) has been doing the dumb pulling rank priority 0 thing.
posted by clawsoon at 10:52 AM on July 20, 2021
To be honest I think the change from Waterfall to Agile was mostly about how software is delivered.
Years ago, if you were working on mass-market software, you deployed it by getting a plant to produce tens of thousands of disks, all of which had to be packaged and wrapped. You couldn't do a new version more than every year or so. So you needed a methodology that would deliver on a long timescale without any critical bugs.
Even in the corporate software world, when I started we had to work our way round all the PCs in the department with an install disk and manually install the software package on every computer.
These days, most software is delivered online. If you find a bug, you can patch it almost immediately. You can release every week or every day if you want. So you're best off with a methodology that allows you to change things quickly.
Agile is mostly about you not having to ship to a CD-pressing plant anymore.
posted by TheophileEscargot at 11:19 AM on July 20, 2021 [8 favorites]
Years ago, if you were working on mass-market software, you deployed it by getting a plant to produce tens of thousands of disks, all of which had to be packaged and wrapped. You couldn't do a new version more than every year or so. So you needed a methodology that would deliver on a long timescale without any critical bugs.
Even in the corporate software world, when I started we had to work our way round all the PCs in the department with an install disk and manually install the software package on every computer.
These days, most software is delivered online. If you find a bug, you can patch it almost immediately. You can release every week or every day if you want. So you're best off with a methodology that allows you to change things quickly.
Agile is mostly about you not having to ship to a CD-pressing plant anymore.
posted by TheophileEscargot at 11:19 AM on July 20, 2021 [8 favorites]
"Courage" means accepting more work than can be done
"Commitment" means doing it in unpaid overtime
"Openness" means still taking another task whenever asked
"Focus" means juggling many balls without being caught dropping any
"Respect" means not complaining about any of the above when talking to managers
If there was one part that struck me in this that tied 100% of Scream to performance reviews in real life - *this* was it. I mean, I either know the company that this originated from, or whatever consultant my company hired to wordsmith the company I work for wrote this in jest... because those are the exact titles with just 'truer' definitions.
posted by Nanukthedog at 11:33 AM on July 20, 2021 [8 favorites]
"Commitment" means doing it in unpaid overtime
"Openness" means still taking another task whenever asked
"Focus" means juggling many balls without being caught dropping any
"Respect" means not complaining about any of the above when talking to managers
If there was one part that struck me in this that tied 100% of Scream to performance reviews in real life - *this* was it. I mean, I either know the company that this originated from, or whatever consultant my company hired to wordsmith the company I work for wrote this in jest... because those are the exact titles with just 'truer' definitions.
posted by Nanukthedog at 11:33 AM on July 20, 2021 [8 favorites]
"Respect" means not complaining about any of the above when talking to managers
Always have something positive to say! Is what I'm told when I 'complain' too much.
posted by 922257033c4a0f3cecdbd819a46d626999d1af4a at 11:40 AM on July 20, 2021 [1 favorite]
Always have something positive to say! Is what I'm told when I 'complain' too much.
posted by 922257033c4a0f3cecdbd819a46d626999d1af4a at 11:40 AM on July 20, 2021 [1 favorite]
"This is a really impressive mess!"
posted by snuffleupagus at 11:42 AM on July 20, 2021 [4 favorites]
posted by snuffleupagus at 11:42 AM on July 20, 2021 [4 favorites]
"I'm positive you have oversubscribed to the 'fail fast' ethos."
posted by It's Raining Florence Henderson at 11:44 AM on July 20, 2021 [2 favorites]
posted by It's Raining Florence Henderson at 11:44 AM on July 20, 2021 [2 favorites]
Agile -like conservatism- cannot fail, it can only BE failed.
posted by Orb2069 at 12:04 PM on July 20, 2021 [2 favorites]
posted by Orb2069 at 12:04 PM on July 20, 2021 [2 favorites]
The problem is always the shared understanding of current priorities on an unending todo list. Teams that have a high level understanding and appropriate skills and experience tend to get things done regardless of what project management buzzword system you use. These frameworks don’t help those that don’t.
posted by interogative mood at 1:56 PM on July 20, 2021 [4 favorites]
posted by interogative mood at 1:56 PM on July 20, 2021 [4 favorites]
922257033c4a0f3cecdbd819a46d626999d1af4a: Always have something positive to say! Is what I'm told when I 'complain' too much.
Evans-Pritchard said that the Azande would accuse people who expressed negative feelings (which were subsequently followed by something bad happening) of witchcraft. That immediately made me think of modern corporate life.
He also said that the Azande were some of the happiest people he had ever met. That also reminded me of the enforced cheerfulness of modern corporate life...
posted by clawsoon at 2:39 PM on July 20, 2021 [4 favorites]
Evans-Pritchard said that the Azande would accuse people who expressed negative feelings (which were subsequently followed by something bad happening) of witchcraft. That immediately made me think of modern corporate life.
He also said that the Azande were some of the happiest people he had ever met. That also reminded me of the enforced cheerfulness of modern corporate life...
posted by clawsoon at 2:39 PM on July 20, 2021 [4 favorites]
the idea of doing frequent releases with small and well defined scope seems great, but it also seems like many many people doing “Agile” dont do that…..they just carry on with big sprawling projects, now with a daily meeting
posted by thelonius at 3:09 PM on July 20, 2021 [2 favorites]
posted by thelonius at 3:09 PM on July 20, 2021 [2 favorites]
The_Vegetables: "You sound like a team leader/people manager, which is not the same as a scrum master/scrum team. The agile team is the people your employees are working with on a daily basis, grouped into a formal team as long as the work lasts…"
I wasn't trying to position myself within the bullshit-space. I was making a point about how no amount of buzzwords and methodology-of-the-week will actually help you get shit done.
posted by signal at 4:34 PM on July 20, 2021 [2 favorites]
I wasn't trying to position myself within the bullshit-space. I was making a point about how no amount of buzzwords and methodology-of-the-week will actually help you get shit done.
posted by signal at 4:34 PM on July 20, 2021 [2 favorites]
I like the Agile and/or Scrum mindset when it is "these are the things we can get done in this two-week* session and we can show that we did those things!" and that's great (although I also was not on board with the whole idea "if you can't have something to demonstrate, you did not work" idea because even as a developer, you may not have anything concrete to show. Sure, you can be "here is some code I wrote ..." but ... who cares?). Mostly, I think it's a good strategy for breaking down big projects into smaller pieces. A lot of people don't treat it like that, though. I think too many companies want it to be "metrics" of "what's been done" in terms of "work." And it's not always that. It's just a plan for stuff for people to work on. And if they didn't finish it, that's a conversation to be had and it's worth discussing why.
*Or however long your sprint is. I also don't think if you don't get everything done in a sprint that you failed. It's just sometimes -- a lot of times -- shit happens. I think it's a process where everyone needs to keep learning and improving. But yes, I know how most companies work.
posted by edencosmic at 5:50 PM on July 20, 2021 [3 favorites]
*Or however long your sprint is. I also don't think if you don't get everything done in a sprint that you failed. It's just sometimes -- a lot of times -- shit happens. I think it's a process where everyone needs to keep learning and improving. But yes, I know how most companies work.
posted by edencosmic at 5:50 PM on July 20, 2021 [3 favorites]
But then some exec would get a bee in his bonnet and whatever that guy wanted would be priority 0, preempting however many priority 1 tickets, and yes, we appreciated the irony ("sure, I'll assign zero priority to that"). The best version of this was when they'd already thrown a priority 0 thing at us and then they threw two more at us in the same week.
Best case scenario, the exec always forgets what they've already asked for and the ticket tumbles into the ever-growing vortex of tech-debt.
posted by bendy at 6:43 PM on July 20, 2021 [2 favorites]
Best case scenario, the exec always forgets what they've already asked for and the ticket tumbles into the ever-growing vortex of tech-debt.
posted by bendy at 6:43 PM on July 20, 2021 [2 favorites]
The funniest thing about the whole SCRUM/Agile thing is that the originators have always said and later emphasized that it should not be a dogma; the rules aren't set in stone and should be adjusted and discarded to suit the situation. IMO kinda like D&D rules :)
So if you are working towards a release ... well, sometimes a sprint should not take 2 weeks, but maybe it should be 3! Or 1! Sometimes your story can be broken up into tasks per platform ... sometimes it should be an epic with stories per platform which break down into tasks.
And story points? Oh, man ... these are not ephemeral things, subject to change (well, yeah, the amount per week is, but they can be precisely defined): they should be considered 'coding hours'. I have heard so many ways of defining them, so many limitations or abstractions.
But to me, the only way they make sense is: you work Z amount per week (say 40). You have Y amount of overhead per week (daily standup, meetings ... some weeks more, some weeks less). Add context switching overhead, some things taking up more communication overhead; this leaves X-Y=Z hours of coding. X is fixed-ish (barring holidays/time off), Y is very variable ... so Z is what is left. Z is variable. Z is the the hours of coding remaining! Which means it is the story points you can spend. And it's not some nebulous conflation of task-time, difficulty and skill! Story points should be hours!
Now how many story points something costs?! Well, that DOES depend on task, difficulty, skill and most importantly prior knowledge.
But how much points does a task take? Or a story? Shit, I've seen stories being given an amount of points whose tasks were divided into multiple platforms ... like: 'story is 4 points, we got 2 devs, one per platform: they get 4 points each'. Regardless of seniority or codebase!
And that is disregarding the fact that I think each platform should get it's own story :(
And I too am in the camp that 'epic/story/task' is a juvenile nomenclature which leads to ephemeral terms like 'story points' which lead to willful misunderstanding: an epic is a major feature/change. It is a GOAL.
That GOAL is broken up into FEATURES; concrete parts which can be finished separately, implemented and finished and integrated separately.
And FEATURES can be broken up into specific PARTS. A Part is a concrete change/addition/step. Often it is only when all PARTS are completed that a FEATURE fully works.
And a PART? Consists of TASKS: the actual bits of code, the methods. Making an Activity/Page, creating the convertor (with subtasks being the intermediate steps to make the convertor work).
And thus 'story points' are 'points' (AKA 'actual programming hours'). And once you determine how many points you have for this sprint you can do the feedback loop of 'ok, this is the FEATURE or PART we want to have done ... how many points do we think it will cost and how many do we have? Do we do the FEATURE? In 1, 2 or 3 weeks? Or do we break that up into PARTS which we do the first in 1 week, the second in 2 and the third in 1 again?'
So you look at the TASK or PART to estimate cost, spend points, see where you end up in your refinement. THEN you decide how to organise your sprint: what it will accomplish and how long it will be.
At least, that would be my ideal way of working :(
With a sprint being an almost inviolate section of work: except for hotfix worthy bugs, the plan doesn't get changed ... except maybe to lengthen or shorten the sprint (or maybe add/remove an optional item or two at the end as things get finished at the end and time-cost becomes clearer).
Sorry for the ramble :)
posted by MacD at 2:04 PM on July 22, 2021 [4 favorites]
So if you are working towards a release ... well, sometimes a sprint should not take 2 weeks, but maybe it should be 3! Or 1! Sometimes your story can be broken up into tasks per platform ... sometimes it should be an epic with stories per platform which break down into tasks.
And story points? Oh, man ... these are not ephemeral things, subject to change (well, yeah, the amount per week is, but they can be precisely defined): they should be considered 'coding hours'. I have heard so many ways of defining them, so many limitations or abstractions.
But to me, the only way they make sense is: you work Z amount per week (say 40). You have Y amount of overhead per week (daily standup, meetings ... some weeks more, some weeks less). Add context switching overhead, some things taking up more communication overhead; this leaves X-Y=Z hours of coding. X is fixed-ish (barring holidays/time off), Y is very variable ... so Z is what is left. Z is variable. Z is the the hours of coding remaining! Which means it is the story points you can spend. And it's not some nebulous conflation of task-time, difficulty and skill! Story points should be hours!
Now how many story points something costs?! Well, that DOES depend on task, difficulty, skill and most importantly prior knowledge.
But how much points does a task take? Or a story? Shit, I've seen stories being given an amount of points whose tasks were divided into multiple platforms ... like: 'story is 4 points, we got 2 devs, one per platform: they get 4 points each'. Regardless of seniority or codebase!
And that is disregarding the fact that I think each platform should get it's own story :(
And I too am in the camp that 'epic/story/task' is a juvenile nomenclature which leads to ephemeral terms like 'story points' which lead to willful misunderstanding: an epic is a major feature/change. It is a GOAL.
That GOAL is broken up into FEATURES; concrete parts which can be finished separately, implemented and finished and integrated separately.
And FEATURES can be broken up into specific PARTS. A Part is a concrete change/addition/step. Often it is only when all PARTS are completed that a FEATURE fully works.
And a PART? Consists of TASKS: the actual bits of code, the methods. Making an Activity/Page, creating the convertor (with subtasks being the intermediate steps to make the convertor work).
And thus 'story points' are 'points' (AKA 'actual programming hours'). And once you determine how many points you have for this sprint you can do the feedback loop of 'ok, this is the FEATURE or PART we want to have done ... how many points do we think it will cost and how many do we have? Do we do the FEATURE? In 1, 2 or 3 weeks? Or do we break that up into PARTS which we do the first in 1 week, the second in 2 and the third in 1 again?'
So you look at the TASK or PART to estimate cost, spend points, see where you end up in your refinement. THEN you decide how to organise your sprint: what it will accomplish and how long it will be.
At least, that would be my ideal way of working :(
With a sprint being an almost inviolate section of work: except for hotfix worthy bugs, the plan doesn't get changed ... except maybe to lengthen or shorten the sprint (or maybe add/remove an optional item or two at the end as things get finished at the end and time-cost becomes clearer).
Sorry for the ramble :)
posted by MacD at 2:04 PM on July 22, 2021 [4 favorites]
The best manager I’ve ever had used that definition for “points,” too. He called them “Ideal Engineer-Hours,” which I thought captured the spirit of the thing well. Of course he was a super-senior manager slumming it as an engineering leader for a bit in between super-ambitious jobs (but he had the skills to back it up, and the experience — like I said, good manager). Of course he lasted about a year before the siren song of more money lured him away to FAANG again..
posted by Alterscape at 2:59 PM on July 22, 2021 [1 favorite]
posted by Alterscape at 2:59 PM on July 22, 2021 [1 favorite]
I've been saying that I like agile because I like the way my current workplace does things and we are theoretically agile. But I have this suspicion that our process isn't "agile" so much as "benign neglect by management."
Come to think of it, maybe "benign neglect by management" is the only way to do agile right.
posted by Tehhund at 3:41 PM on July 22, 2021 [1 favorite]
Come to think of it, maybe "benign neglect by management" is the only way to do agile right.
posted by Tehhund at 3:41 PM on July 22, 2021 [1 favorite]
« Older Children's lit, digital humanities, Python, and a... | Bigfoot Is Blurry Newer »
This thread has been archived and is closed to new comments
https://www.agilegothenburg.org/blog/2019-posts/the-scream-guide-is-out
posted by bendy at 1:38 PM on July 19, 2021 [2 favorites]