Agile Crisis
-
-
@izzion Spiral methodology will never be widely acknowledged.
-
@izzion
While reading, this line stands out a bit:Rather than clearing the way for software developers to build, waterfall gummed up the works with binders of paperwork and endless meetings.
Because that doesn't sound like every bloody process or methodology that's been applied to software development ever.
It's mostly all because of managers having anxiety over not being involved. And the MONIES!Now to read the rest.
...
And this:It’s also worth considering how Agile might have played a role in creating a work culture that is increasingly revealed to be toxic for women, people of color, and members of gender minority groups. It’s an inescapable fact that the authors of the Agile Manifesto were a very specific group of people: white men who, whatever their varying experiences, have probably not spent much time in workplaces where they composed the minority. The working group has since acknowledged the deficit in the team’s diversity and vowed to incorporate a larger set of voices in the Agile Alliance, a nonprofit associated with the manifesto.
-
@izzion said in In other news today...:
This is a bad article. There are problems with Agile, but the author glosses over them in favor of problems that exist in software development in general.
My favorite part is this.
Wischweh himself encountered a turning point while describing a standup meeting to an aunt, a lawyer. She was incredulous. The notion that a competent professional would need to justify his work every day, in tiny units, was absurd to her.
His aunt is a lawyer that's never heard of "billable hours"?
Anyway, Agile isn't your HR department. If you have problems with sexual harassment or people being contentious objectors to building your product, that would have existed regardless of what software engineering methodology you use. And if you have other engineering departments, you probably have the same issues there.
The tension that agile actually invites is that it forces PMs and management to make specific decisions about resource allocation and desired outputs. Some of the Agile ceremonies (specifically backlog refinement and sprint planning) force the PMs and the developers to collaborate so that they both understand each other. It makes it harder for each side of the table to BS each other. If your management style depends on demanding the impossible from your employees, you're going to run into tension. But if your engineering style consists of BSing your boss and screwing around (c.f. Wally from Dilbert), you're also going to have difficulty.
I bet a lot of teams have at least a little of both.
A better article would discuss this mechanic, and maybe point out some ways to solve it.
-
@Carnage said in In other news today...:
Because that doesn't sound like every bloody process or methodology that's been applied to software development ever.
It's mostly all because of managers having anxiety over not being involved. And the MONIES!Well, that's true - and Scrum's rituals certainly put some of that power back in the hands of the (insert-type) managers, with the as-described standups becoming low-key surveillance (whether intentionally or not).
To the minority angle, I don't agree. Is there a huge imbalance in the demographics and makeup of the majority of engineering teams? For sure. Is that the fault of Agile? Doubtful.
Specifically, I don't think Agile pushed an agenda here, even unintentionally: I think the makeup of the team that produced the manifesto is a representation of the makeup of the people who at the time were most likely, most able and most willing to become engineers.
Because there's societal forces at work that enable people to be able to become engineers, and that the structural inequalities will be more of a contributing factor than anything else.
-
Personally, my issue with agile adjacent methods is that things that don't fit naturally into a sprint never (or rarely) get finished. So you do an "MVP" and then move on, leaving things half finished everywhere. Which actually is a bad look. I've talked to a lot of customers who prioritize stability and everything working over speed of development. "Everything's always alpha" leads to lots of half features instead of an actually working thing.
And then when you try to come back and finish the features, the whole system and model have drifted far enough that those old features have to be entirely reworked.
-
@Arantor said in In other news today...:
@Carnage said in In other news today...:
Because that doesn't sound like every bloody process or methodology that's been applied to software development ever.
It's mostly all because of managers having anxiety over not being involved. And the MONIES!Well, that's true - and Scrum's rituals certainly put some of that power back in the hands of the (insert-type) managers, with the as-described standups becoming low-key surveillance (whether intentionally or not).
To the minority angle, I don't agree. Is there a huge imbalance in the demographics and makeup of the majority of engineering teams? For sure. Is that the fault of Agile? Doubtful.
Specifically, I don't think Agile pushed an agenda here, even unintentionally: I think the makeup of the team that produced the manifesto is a representation of the makeup of the people who at the time were most likely, most able and most willing to become engineers.
Because there's societal forces at work that enable people to be able to become engineers, and that the structural inequalities will be more of a contributing factor than anything else.
I can appreciate the grift to call agile racism to get rid of it though.
-
@Benjamin-Hall said in In other news today...:
Personally, my issue with agile adjacent methods is that things that don't fit naturally into a sprint never (or rarely) get finished. So you do an "MVP" and then move on, leaving things half finished everywhere. Which actually is a bad look. I've talked to a lot of customers who prioritize stability and everything working over speed of development. "Everything's always alpha" leads to lots of half features instead of an actually working thing.
And then when you try to come back and finish the features, the whole system and model have drifted far enough that those old features have to be entirely reworked.
Yeah. I want the shit I create to be good. The last few years I've spent my time fighting with managers under the guise of "agile" much in exactly the same way I did before "agile" was the new hotness. The main problem is managers that don't understand and let me do my shit in peace. It always was. Every project where managers basically fucked off and kept the beancounters off my back and let me do my think the ones where i surprisingly liked to work the best. And where my output was pretty damned good. Or "Best in class!" as the bureaucrat wankers say.
-
@Benjamin-Hall said in In other news today...:
Personally, my issue with agile adjacent methods is that things that don't fit naturally into a sprint never (or rarely) get finished. So you do an "MVP" and then move on, leaving things half finished everywhere. Which actually is a bad look. I've talked to a lot of customers who prioritize stability and everything working over speed of development. "Everything's always alpha" leads to lots of half features instead of an actually working thing.
And then when you try to come back and finish the features, the whole system and model have drifted far enough that those old features have to be entirely reworked.
What does half done mean? If it means something like a MS Word competitor where you don't have a Save button at all, it's a badly scoped MVP. If it means "ideally X can do A, B, and C and our MVP is A" and A is useful on its own, then that's the point. I suppose my first example could be a valid internal-only MVP as long as it doesn't leak out.
-
@ObjectMike said in In other news today...:
@Benjamin-Hall said in In other news today...:
Personally, my issue with agile adjacent methods is that things that don't fit naturally into a sprint never (or rarely) get finished. So you do an "MVP" and then move on, leaving things half finished everywhere. Which actually is a bad look. I've talked to a lot of customers who prioritize stability and everything working over speed of development. "Everything's always alpha" leads to lots of half features instead of an actually working thing.
And then when you try to come back and finish the features, the whole system and model have drifted far enough that those old features have to be entirely reworked.
What does half done mean? If it means something like a MS Word competitor where you don't have a Save button at all, it's a badly scoped MVP. If it means "ideally X can do A, B, and C and our MVP is A" and A is useful on its own, then that's the point. I suppose my first example could be a valid internal-only MVP as long as it doesn't leak out.
In the area I work in, the MVP might look like a new page where you can clock in and clock out and see your logged time.
But the thing is, that's not what people want or are willing to pay for. That adds ~0 value by itself. And if you try to iterate on that...well...you don't have anyone using it so you don't have any feedback to iterate on (or worse, you have a few people using it but their feedback is biased because human). So you switch to some other, half-baked thing. And when you finally get users and you figure out that what they really wanted was something quite different and that your basic domain model was wrong, now you have to rip out all that previous stuff and rebuild. And the costs incurred with all those "false starts" end up dragging you down.
And the customers (who are quite change-averse and value stability over "fast iteration") start feeling like they're paying $$$ for a beta version. "You're not done?" is a common worry. They don't want an "agile, evolving" project. They want something mature. And working at the sprint level doesn't get you there. It gets you 10k different little things.
Now this might be different when working from the base of an already-mostly-mature product with well-defined problem domain and feature set (ie for enhancing something already existing). Agile works great for tweaking things that already mostly exist. But for greenfield stuff where you actually have to do a lot of "overhead" planning and research? Yeah. Not so much. At least in my (limited) experience.
The number of times I've had to say (or think) something to the effect of "well, we planned to add that, but haven't gotten around to it yet" for some very basic things (because we needed an MVP that we could release in a sprint cycle is...way too large.
-
@Benjamin-Hall said in In other news today...:
@ObjectMike said in In other news today...:
@Benjamin-Hall said in In other news today...:
Personally, my issue with agile adjacent methods is that things that don't fit naturally into a sprint never (or rarely) get finished. So you do an "MVP" and then move on, leaving things half finished everywhere. Which actually is a bad look. I've talked to a lot of customers who prioritize stability and everything working over speed of development. "Everything's always alpha" leads to lots of half features instead of an actually working thing.
And then when you try to come back and finish the features, the whole system and model have drifted far enough that those old features have to be entirely reworked.
What does half done mean? If it means something like a MS Word competitor where you don't have a Save button at all, it's a badly scoped MVP. If it means "ideally X can do A, B, and C and our MVP is A" and A is useful on its own, then that's the point. I suppose my first example could be a valid internal-only MVP as long as it doesn't leak out.
In the area I work in, the MVP might look like a new page where you can clock in and clock out and see your logged time.
But the thing is, that's not what people want or are willing to pay for. That adds ~0 value by itself. And if you try to iterate on that...well...you don't have anyone using it so you don't have any feedback to iterate on (or worse, you have a few people using it but their feedback is biased because human). So you switch to some other, half-baked thing. And when you finally get users and you figure out that what they really wanted was something quite different and that your basic domain model was wrong, now you have to rip out all that previous stuff and rebuild. And the costs incurred with all those "false starts" end up dragging you down.
And the customers (who are quite change-averse and value stability over "fast iteration") start feeling like they're paying $$$ for a beta version. "You're not done?" is a common worry. They don't want an "agile, evolving" project. They want something mature. And working at the sprint level doesn't get you there. It gets you 10k different little things.
Now this might be different when working from the base of an already-mostly-mature product with well-defined problem domain and feature set (ie for enhancing something already existing). Agile works great for tweaking things that already mostly exist. But for greenfield stuff where you actually have to do a lot of "overhead" planning and research? Yeah. Not so much. At least in my (limited) experience.
The number of times I've had to say (or think) something to the effect of "well, we planned to add that, but haven't gotten around to it yet" for some very basic things (because we needed an MVP that we could release in a sprint cycle is...way too large.
Agile works very well for greenfield. However the data stuff I work on lends itself nicely to a spike->set of stories model. Sounds like the problem you're running into is more about gathering initial requirements. Especially if you're frequently running into users saying they want something completely different. I would hope there's some kind of user SME involved. That could be talking to internal users or somebody who works with account management for paying customers.
-
@Benjamin-Hall said in In other news today...:
The number of times I've had to say (or think) something to the effect of "well, we planned to add that, but haven't gotten around to it yet" for some very basic things (because we needed an MVP that we could release in a sprint cycle is...way too large.
I'm not a fan of the idea that each sprint is a release I've seen touted in some agile methodologies. Some features take 2 sprints. Some take a quarter, or even longer. I think it makes sense that the code at the end of a sprint is hypothetically releasable. Ideally there'd be some kind of CI/CD process going on and not-yet-done features are hidden behind feature flags.
-
@ObjectMike said in In other news today...:
not-yet-done features are hidden behind feature flags.
NOPE thread is
. Trying to manage feature flags for anything non-trivial is a nightmare waiting to happen.
-
@Benjamin-Hall said in In other news today...:
@ObjectMike said in In other news today...:
@Benjamin-Hall said in In other news today...:
Personally, my issue with agile adjacent methods is that things that don't fit naturally into a sprint never (or rarely) get finished. So you do an "MVP" and then move on, leaving things half finished everywhere. Which actually is a bad look. I've talked to a lot of customers who prioritize stability and everything working over speed of development. "Everything's always alpha" leads to lots of half features instead of an actually working thing.
And then when you try to come back and finish the features, the whole system and model have drifted far enough that those old features have to be entirely reworked.
What does half done mean? If it means something like a MS Word competitor where you don't have a Save button at all, it's a badly scoped MVP. If it means "ideally X can do A, B, and C and our MVP is A" and A is useful on its own, then that's the point. I suppose my first example could be a valid internal-only MVP as long as it doesn't leak out.
In the area I work in, the MVP might look like a new page where you can clock in and clock out and see your logged time.
But the thing is, that's not what people want or are willing to pay for. That adds ~0 value by itself. And if you try to iterate on that...well...you don't have anyone using it so you don't have any feedback to iterate on (or worse, you have a few people using it but their feedback is biased because human). So you switch to some other, half-baked thing. And when you finally get users and you figure out that what they really wanted was something quite different and that your basic domain model was wrong, now you have to rip out all that previous stuff and rebuild. And the costs incurred with all those "false starts" end up dragging you down.
And the customers (who are quite change-averse and value stability over "fast iteration") start feeling like they're paying $$$ for a beta version. "You're not done?" is a common worry. They don't want an "agile, evolving" project. They want something mature. And working at the sprint level doesn't get you there. It gets you 10k different little things.
Now this might be different when working from the base of an already-mostly-mature product with well-defined problem domain and feature set (ie for enhancing something already existing). Agile works great for tweaking things that already mostly exist. But for greenfield stuff where you actually have to do a lot of "overhead" planning and research? Yeah. Not so much. At least in my (limited) experience.
The number of times I've had to say (or think) something to the effect of "well, we planned to add that, but haven't gotten around to it yet" for some very basic things (because we needed an MVP that we could release in a sprint cycle is...way too large.
Then something in your requirements gathering & sprint planning process is broken. Features should be contained efforts that span as many sprints as they take. And those features should be broken down into discrete tasks that work together to complete the feature. Some tasks may be parallelizable, and some may have a dependency chain (eg must set up the user database first, then the add user endpoint, then the change user and remove user endpoints as parallel-capable tasks).
Sprints should get done as much of the current feature as makes sense, without killing your developers, destabilizing your product, or leaving you without enough time to respond to bug reports and unforeseens. If the sprint review winds up being mostly back end, then that sprint is preparing the product to move forward. If you’re not doing features because they don’t fit into sprints, you’re doing Waterfail with a really tiny 2 week hill.
-
@Benjamin-Hall said in In other news today...:
@ObjectMike said in In other news today...:
not-yet-done features are hidden behind feature flags.
NOPE thread is
. Trying to manage feature flags for anything non-trivial is a nightmare waiting to happen.Seemed to work well at the last place I was at. But I didn't work on the frontend where they were used so I can't speak to it in great detail. I think we used Launch Darkly. You add the flag, you can turn it on to a particular user login for testing, and the code that cares just needs an if-statement around the relevant code. Did seem to sometimes run into dependency problems but those were the same as a release-to-prod dependency that were instead a enable-related-flags dependency.
-
@ObjectMike said in In other news today...:
@Benjamin-Hall said in In other news today...:
@ObjectMike said in In other news today...:
not-yet-done features are hidden behind feature flags.
NOPE thread is
. Trying to manage feature flags for anything non-trivial is a nightmare waiting to happen.Seemed to work well at the last place I was at. But I didn't work on the frontend where they were used so I can't speak to it in great detail. I think we used Launch Darkly. You add the flag, you can turn it on to a particular user login for testing, and the code that cares just needs an if-statement around the relevant code. Did seem to sometimes run into dependency problems but those were the same as a release-to-prod dependency that were instead a enable-related-flags dependency.
But then if you have two features that touch the same area of code, you end up with nested or conflicting feature flags. And whenever you're reading the code to figure out what the heck is going on, you have to juggle all the state of all the configuration simultaneously, along with the actual code flow.
Plus you either have a morass of "stale" flags that are just set to true or you spend a bunch of time ripping them out again once it's released. And hope you don't hit the wrong ones. And hope that your tests cover all the possible combinations.
-
@Benjamin-Hall said in In other news today...:
@ObjectMike said in In other news today...:
@Benjamin-Hall said in In other news today...:
@ObjectMike said in In other news today...:
not-yet-done features are hidden behind feature flags.
NOPE thread is
. Trying to manage feature flags for anything non-trivial is a nightmare waiting to happen.Seemed to work well at the last place I was at. But I didn't work on the frontend where they were used so I can't speak to it in great detail. I think we used Launch Darkly. You add the flag, you can turn it on to a particular user login for testing, and the code that cares just needs an if-statement around the relevant code. Did seem to sometimes run into dependency problems but those were the same as a release-to-prod dependency that were instead a enable-related-flags dependency.
But then if you have two features that touch the same area of code, you end up with nested or conflicting feature flags. And whenever you're reading the code to figure out what the heck is going on, you have to juggle all the state of all the configuration simultaneously, along with the actual code flow.
Like I said I didn't work with that at all, just heard the frontend devs talk about it and had the basics explained to me once. The devs and QA seemed to work with it pretty easily. Though if you're having that many competing changes among the flags, I wonder if too much code is being put in the guarded section that maybe shouldn't be? Or maybe my old job's code was better laid out to avoid those kinds of problems? Or you're putting stories in the same sprint that aren't really parallelizable?
-
@Benjamin-Hall said in In other news today...:
Plus you either have a morass of "stale" flags that are just set to true or you spend a bunch of time ripping them out again once it's released. And hope you don't hit the wrong ones. And hope that your tests cover all the possible combinations.
Our team generally removed flags the sprint after they were turned on in prod and never really seemed to be that troublesome. I think there was one flag that took a half day because it was a bit hairy because that part of the changed code was particularly gross, but I got the impression it was usually a quick change (almost always 1 pointers).
-
@ObjectMike said in In other news today...:
Or you're putting stories in the same sprint that aren't really parallelizable?
But if features take multiple sprints, then you have to commit to doing it all up front. Because if you pivot... Now you have conflicts between sprints. And one of the big selling points is that you can pivot quickly.
Sure, in a perfect world, it works. But I'm coming more and more around to the idea that taking it a bit slower and doing it better on round 1 (including spending more time doing design and research on the product side first) would save lots of effort and pain in the long run. And prevent lots of tech debt.
I'm also bitter because we're coming out of phase 1 of a big architecture overhaul. A needed one. But the transition is a mess, and we'll have to do at least one more big ugly step before we can clean up. And looking at the priority queue... That's gonna be a while. So we'll have to live with ugly neither one nor the other for much longer than I'd like.
-
@Benjamin-Hall said in In other news today...:
Personally, my issue with agile adjacent methods is that things that don't fit naturally into a sprint never (or rarely) get finished. So you do an "MVP" and then move on, leaving things half finished everywhere. Which actually is a bad look. I've talked to a lot of customers who prioritize stability and everything working over speed of development. "Everything's always alpha" leads to lots of half features instead of an actually working thing.
And then when you try to come back and finish the features, the whole system and model have drifted far enough that those old features have to be entirely reworked.
-
@Benjamin-Hall said in In other news today...:
The number of times I've had to say (or think) something to the effect of "well, we planned to add that, but haven't gotten around to it yet" for some very basic things (because we needed an MVP that we could release in a sprint cycle is...way too large.
@Benjamin-Hall said in In other news today...:
But then if you have two features that touch the same area of code, you end up with nested or conflicting feature flags. And whenever you're reading the code to figure out what the heck is going on, you have to juggle all the state of all the configuration simultaneously, along with the actual code flow.
Plus you either have a morass of "stale" flags that are just set to true or you spend a bunch of time ripping them out again once it's released. And hope you don't hit the wrong ones. And hope that your tests cover all the possible combinations.
Please, stop. You're hurting me.
-
@Benjamin-Hall said in In other news today...:
I'm coming more and more around to the idea that taking it a bit slower and doing it better on round 1 (including spending more time doing design and research on the product side first) would save lots of effort and pain in the long run. And prevent lots of tech debt.
I believe that one of the key things is to regard the things found out by doing the research and design to be sprint outcomes in themselves.
-
Still reading through TFA but this struck me:
Even as the team is pulled in multiple directions, it’s asked to move projects forward at an ever-accelerating pace. “Sprinting,” after all, is fast by definition. And indeed, the prospect of burnout loomed large for many of the tech workers I spoke to. “You’re trying to define what’s reasonable in that period of time,” said technical writer Sarah Moir. “And then run to the finish line and then do it again. And then on to that finish line, and on and on. That can be kind of exhausting if you’re committing 100 percent of your capacity.”
As opposed to what? Dragging your feet on tasks because you have no accountability and so nothing ever gets done?
-
Re: standups:
Particularly when work is decomposed into small parts, workers feel an obligation to enumerate every task they’ve accomplished.
That's a fucking personal problem. I really hate it when people go into lots of detail. I don't fucking care. And neither does anyone else (unless you're saying you need help, which gets handled in a follow up, not in the stand up itself).
Damn. This article is really making me angry. Perfect start to a Monday morning.
-
But by turning features into “user stories” on a whiteboard, Agile has the potential to create what Yvonne Lam calls a “chain of deniability”: an assembly line in which no one, at any point, takes full responsibility for what the team has created.
It's like she doesn't know what a team is. The more I read, the more I hate the author for whining about a bunch of shit that comes down to the fact that people ruin everything. Trying to blame "agile" here is doing exactly what he claims the agile advocates are doing.7/10 would hate read again.
-
@ObjectMike said in Agile Crisis:
@Benjamin-Hall said in In other news today...:
The number of times I've had to say (or think) something to the effect of "well, we planned to add that, but haven't gotten around to it yet" for some very basic things (because we needed an MVP that we could release in a sprint cycle is...way too large.
I'm not a fan of the idea that each sprint is a release I've seen touted in some agile methodologies. Some features take 2 sprints. Some take a quarter, or even longer. I think it makes sense that the code at the end of a sprint is hypothetically releasable. Ideally there'd be some kind of CI/CD process going on and not-yet-done features are hidden behind feature flags.
Eh, everyone should have access to version control capable of branches. When we've had significant stuff like this we've just split it out that way. And yes, even svn's branching is capable of this these days. I know because that's what we still use.
OTOH, we tend not to do feature branches for the vast majority of our work.
-
@boomzilla said in Agile Crisis:
As opposed to what? Dragging your feet on tasks
It just occurs to me that a marathon isn't run by stringing a lot of sprints together. Whether that is relevant I neither know nor really care. But the analogy is already there so why not push on it and see if it falls over?
because you have no accountability and so nothing ever gets done?
False dichotomy?
-
@Watson said in Agile Crisis:
False dichotomy?
Quite.
It just occurs to me that a marathon isn't run by stringing a lot of sprints together. Whether that is relevant I neither know nor really care. But the analogy is already there so why not push on it and see if it falls over?
She says that she's responsible for estimating the time it will take her. Maybe give estimates that aren't unreasonable for you in the first place? Whether the tasks are grouped by two weeks or any other thing, presumably you expect to generally keep working.
This is either just another bit of mismanagement that is orthogonal to agile or someone who is bitter that she actually has to do work. Or, I suppose, a writer looking for spicy quotes for the sake of making his article sound more interesting than it really is.
-
I hope I never fall to the point where I believe it to be a good use of my time to write an article about how Agile is not only ineffective and racist, but also an opportunity for the workers of the world to unite, padded with the entire history of software engineering for length.
-
@Groaner said in Agile Crisis:
I hope I never fall to the point where I believe it to be a good use of my time to write an article about how Agile is not only ineffective and racist, but also an opportunity for the workers of the world to unite, padded with the entire history of software engineering for length.
In Soviet Russia, Agile program you!
-
@Benjamin-Hall said in Agile Crisis:
@ObjectMike said in In other news today...:
Or you're putting stories in the same sprint that aren't really parallelizable?
But if features take multiple sprints, then you have to commit to doing it all up front. Because if you pivot... Now you have conflicts between sprints. And one of the big selling points is that you can pivot quickly.
I should probably mention that our sprints are in a larger context of quarterly objectives/epic goals. We call it "release planning" but we do releases of our software as we have need.
While Agile does encourage the ability to pivot, if you're doing it enough it's frequently causing you to have a bunch of incomplete epics, you're probably not doing enough planning and/or backlog grooming and pivoting too much. Your team or product should have somebody in charge of priorities and they should have a clear picture of what those are for I'd say a minimum of the next quarter, calendar or rolling.
-
@dkf said in Agile Crisis:
@Benjamin-Hall said in In other news today...:
I'm coming more and more around to the idea that taking it a bit slower and doing it better on round 1 (including spending more time doing design and research on the product side first) would save lots of effort and pain in the long run. And prevent lots of tech debt.
I believe that one of the key things is to regard the things found out by doing the research and design to be sprint outcomes in themselves.
Yes, "spike" or "discovery" stories that are timeboxed need to be part of your regular sprint/quarter/release/$WHATEVER process, just like any other story.
-
@boomzilla said in Agile Crisis:
a writer looking for spicy quotes for the sake of making his article sound more interesting than it really is.
-
@dkf said in Agile Crisis:
one of the key things is to regard the things found out by doing the research and design to be sprint outcomes in themselves
Unfortunately, at some places, higher-ups will bitch at you if your design, and I quote, takes too long, accounts for corner cases that are unlikely, etc. AMHIK.
-
@Benjamin-Hall this problem is reduced when the code is written closely enough to domain terms that the flag namespace has a decent chance at making sense, and by not flagging every damn thing.
-
@boomzilla feature flags are not the same as feature branches. Although, if you really want, you could use branch SHAs as flag names.
-
-
@boomzilla said in Agile Crisis:
@Gribnit said in Agile Crisis:
feature flags are not the same as feature branches.
Duh.
Have fun on Merge Day
-
@izzion linked an article in Agile Crisis that said:
It’s also worth considering how Agile might have played a role in creating a work culture that is increasingly revealed to be toxic for women, people of color, and members of gender minority groups.
by @Carnage, but repeating because it's the highlight of the bovine manure of the article.I won't bother quoting the follow-up HR problems. If people on a team that needs to closely cooperate are not comfortable working with each other, it's a problem independent of methodology. Some people are impolite and some people take it too personally. Needs a good manager (or HR) to deal with independent of methodology.
This issue becomes especially pressing when one considers that contemporary software is likely to involve things like machine learning, large datasets, or artificial intelligence—technologies that have shown themselves to be potentially destructive, particularly for minoritized people.
Again completely gratuitous mention of “minoritized” people. Now lets move on to the commie manure:
The digital theorist Ian Bogost argues that this move-fast-and-break-things approach is precisely why software developers should stop calling themselves “engineers”: engineering, he points out, is a set of disciplines with codes of ethics and recognized commitments to civil society. Agile promises no such loyalty, except to the product under construction.
Um, excuse me, but which circle of hell does this come from? Engineer, in any field that is called that, is someone who designs and build things, and their loyalty is always primarily to the product they are constructing.
The Agile Manifesto paints an alluring picture of workplace democracy. The problem is, it’s almost always implemented in workplaces devoted to the bottom line, not to workers’ well-being.
… the point of a corporation—any and every business corporation—is to make money. It can't exist without making money. Of course every process used in a successful business corporation must support that goal, otherwise the corporation can't thrive.
Sometimes those priorities align; the manifesto makes a strong case that businesses’ products can be strengthened by worker autonomy. But they’re just as likely to conflict, as when a project manager is caught between a promise to a client and the developers’ own priorities.
When doing work, one should mind, and take pride, in satisfying the customer. Tricking the customer to pay you more money often works too, though long term the former usually ends up better. But if the developers have other priorities than those two, well, they can go do them as a hobby or go find someone else who will pay for that, but here they are obviously not doing their job.
Some people I talked to pointed out that Agile has the potential to foster solidarity among workers. If teams truly self-organize, share concerns, and speak openly, perhaps Agile could actually lend itself to worker organization. Maybe management, through Agile, is producing its own gravediggers.
Well, no gravediggers, because this is the intent of agile. There are concerns that the technical side has to manage itself. No true salesman will ever understand things like technical debt. Nor they need to, nor are they supposed to. The technical people have to manage this. If there is a good technical leader (and the product manager is excluded from the stand-up as they are supposed to be and only present on planning), this works well. If not, well, doing good work with crap people is kinda problematic.
Part of the issue is Agile’s flexibility. Jan Wischweh, a freelance developer, calls this the “no true Scotsman” problem. Any Agile practice someone doesn’t like is not Agile at all, it inevitably turns out.
I wouldn't call it a problem. Agile is simply accepting that things can't be planned a year into the future so we just give up and adjust the plan as we go. For the rest, just pick the techniques that work for you—YMWV.
-
@Gribnit said in Agile Crisis:
@boomzilla said in Agile Crisis:
@Gribnit said in Agile Crisis:
feature flags are not the same as feature branches.
Duh.
Have fun on Merge Day
Lots of merge days. You have to keep your branch up to date. Still sounds less painful than using flags, especially when your data structures change.
-
I haven't really got any beef in all that, but two things from this post:
@Bulb said in Agile Crisis:
I won't bother quoting the follow-up HR problems. If people on a team that needs to closely cooperate are not comfortable working with each other, it's a problem independent of methodology. Some people are impolite and some people take it too personally. Needs a good manager (or HR) to deal with independent of methodology.
I think part of the issue with the agile-hype is that it was touted by some people as the solution to HR problems. Which it obviously isn't, but I believe the main reason it was pushed this way is that if things go swimmingly well, you don't really bother changing your process (and why would you?), and you don't listen to a management consultant (i.e. those that are going to push agile onto your organisation in the first place). So the most receptive people to "let's try agile!" are teams that don't work well, and a huge number of those are teams with HR problems (because IMO a huge number of teams have HR problems in the first place!).
So yeah, maybe in the middle of all that there are teams that don't work well but don't have HR problems, or teams that have HR problems that are caused by them not working well, and agile can help those. But I believe they're a tiny number.
And thus we get what (one part of) TFA complains about, that any complaints about agile is deflected as "it's your team's fault" (and/or a HR problem). And both sides are right. It's not agile's fault, but conversely agile was likely sold as something that would solve those problems, so it's fair to blame it when it doesn't.
Besides, given how widespread HR problems are everywhere (to various degrees, but still), I believe that a fair assessment of a method shouldn't be "does it work with a team with no HR problems?" but rather "how resilient is it to a team with any number of HR problems?" A method that's very efficient but only in a perfect team, is probably not so useful widely speaking. And that might be where agile is...
The Agile Manifesto paints an alluring picture of workplace democracy. The problem is, it’s almost always implemented in workplaces devoted to the bottom line, not to workers’ well-being.
… the point of a corporation—any and every business corporation—is to make money. It can't exist without making money. Of course every process used in a successful business corporation must support that goal, otherwise the corporation can't thrive.
Both sides of this argument often pop up (in various discussions) and to me the second one is almost as caricatural as the first one. Sure, a company will die if it doesn't make money, but look at any company and you'll see tons of things that don't directly support that goal, starting with the obvious perks (free coffee...). Now you'll immediately say that it indirectly contributes by making workers happy (or by making them not go away, which amounts to the same). But then suddenly you've accepted that "workers’ well-being" matters. OK, the company is still not "devoted" to it. But that doesn't mean it doesn't matter.
Also, companies are ultimately made of humans (citation needed) and profit isn't the only thing that matters to humans. Unless you really have (had) an ultra-shitty career, you probably don't need to think very hard to find examples of people (coworkers, low-level managers...) that did things that ultimately were in the interest of the business (i.e. I'm not talking of Wally-types here) but only cost the company money. And no, "taking care of workers' well-being" doesn't cover everything. Because sometimes humans just are humans and are OK with not maximising profit. That's likely more true in smaller companies, but that happens even in large ones.
In other words, saying that the point of a corporation is to make money is about as true as saying that the point of a family is to make babies. Yes, sure, it's part of it, and a big part, but that doesn't mean every single tiny thing that the family does is geared towards producing more (or better) children.
-
@remi said in Agile Crisis:
I think part of the issue with the agile-hype is that it was touted by some people as the solution to HR problems.
Ok, it wasn't touted to me like that, but as far as that's done, yeah, then it counts against agile.
A method that's very efficient but only in a perfect team, is probably not so useful widely speaking. And that might be where agile is...
I suppose pair programming is there. I've never actually done pair programming. I've done reviews. All we've done is reviews. And yes, even reviews do exacerbate some people problems. But then, leaving the mess caused by those people problems in the repository would probably end up being worse still.
Now you'll immediately say that it indirectly contributes by making workers happy
Not only I will say that, I will say that I don't distinguish the cases. The indirect ways (and where is the boundary anyway) of supporting the bottom line are all part of the business.
But most of the cases where “Sometimes those priorities align; the manifesto makes a strong case that businesses’ products can be strengthened by worker autonomy. But they’re just as likely to conflict, as when a project manager is caught between a promise to a client and the developers’ own priorities.” is when the worker priorities are playing ownership games or making big strategic mistakes, and agile is right to eliminate those.
… of course working sanely under agile requires following the “Boy Scout Rule”, and I admit there are many teams that fail to do that and then get frustrated. But I again don't think different methodology would help; better technical leader, or more trust in the technical leader from the business side, would.
-
@remi said in Agile Crisis:
Also, companies are ultimately made of humans (citation needed)
Counter-example:
-
For example, Ken Schwaber [a manifesto author] was vocal and explicit about his goal to get rid of all project managers.
No. You need someone to run interference with the rest of the company to buy time for a solution. There's also lots of tedious bullshit that they usually deal with that got transferred to developers in the likes of scrum.
The problem is that they had a manifesto. It was more of what you would call goals rather than a plan. That's why scrum ran rickshaw over everything. Scrum has the illusion of a game plan with enough random output to feed the metrics of every bureaucracy no matter how small.
And it is remarkably immune to criticism, since it can’t be reduced to a specific set of methods. “If you do one thing wrong and it’s not working for you, people will assume it’s because you’re doing it wrong,” one product manager told me. “Not because there’s anything wrong with the framework.””
The process, the process! All hail the process!
Well that definitely took a left turn towards clown world towards the end.
-
@DogsB said in Agile Crisis:
For example, Ken Schwaber [a manifesto author] was vocal and explicit about his goal to get rid of all project managers.
No. You need someone to run interference with the rest of the company to buy time for a solution.
The last huge company I worked for seemed to understand how to use Project Managers. Their job was to know the corporate bureaucracy and force the project to follow the rules.
For example, if they oversaw a project that was starting to define its own users and roles, they would bring in someone from Identity Management to do one of two things; either encourage the team to use an already established identity platform, or follow the corporate identity rules and build it in such a way that the helpdesk can support adds/moves/changes and account lockouts.
-
@Jaime said in Agile Crisis:
@DogsB said in Agile Crisis:
For example, Ken Schwaber [a manifesto author] was vocal and explicit about his goal to get rid of all project managers.
No. You need someone to run interference with the rest of the company to buy time for a solution.
The last huge company I worked for seemed to understand how to use Project Managers. Their job was to know the corporate bureaucracy and force the project to follow the rules.
Good project managers are like SSDs and vehicle backup cameras - you don't know how much you need them until you experience them.
-
-
@boomzilla eh, you run into a few but it's mostly dehumanized shells
-
Why “Agile” and especially Scrum are terrible
Note: My first novel, Farisa’s Crossing, will be released in spring 2022. Agility is a good thing, no doubt, and the Agile Manifesto isn’t unreasonable. Compared to a straw-man practice…
-
@Groaner said in Agile Crisis:
@Jaime said in Agile Crisis:
@DogsB said in Agile Crisis:
For example, Ken Schwaber [a manifesto author] was vocal and explicit about his goal to get rid of all project managers.
No. You need someone to run interference with the rest of the company to buy time for a solution.
The last huge company I worked for seemed to understand how to use Project Managers. Their job was to know the corporate bureaucracy and force the project to follow the rules.
Good project managers are like SSDs and vehicle backup cameras - you don't know how much you need them until you experience them.
At my last job we went through 7 managers in the 7 years I was there. The longest tenure was ~2 years, the shortest was ~4 weeks and we had probably 6 months without one at all. The difference between a good project manager, a bad project manager and not having one at all is crazy.
Agile and the Long Crisis of Software
