Rebecca's post 
described by Brian Marick as "the most amazingly disheartening thread" ⇐ Marick and Others on Agile. post
My hot take is that agile is bad actually.
Every real world implementation I've seen since the term was introduced has rapidly developed into either an attempt to micromanage or an attempt to make programmers fungible or both.
@iarna I like some aspects of it, such as user stories and close contact with the product/business side.
But scrum, sprints and point estimates are pure bullshit.
@fabio @iarna ironically, I think all of your bullshit list are scrum originally (which was distinct from agile, before it all got smooshed together)
@fabio @iarna and daily meetings.. let’s face it, most of them are simply useless and wasting precious development time.
@kanedoku @iarna Nobody needs daily meetings except in emergency situations. Standups can be done on slack if people really insist. Anything beyond that is micro-management.
@iarna or waterfall but with lots of deadlines and we don't call it that
@iarna and making workers fungible is the point
@iarna Couldn’t agree more. It’s extra annoying that when you point out the real world failings, you tend to get a “no true agile” response. I couldn’t care less what perfect agile looks like in a vacuum. In practice, it’s a hot mess.
@juliepagano @iarna I waste so much time and effort in this company on agile it is mind-boggling. I'm nearing the end of a 40 year career that never needed agile and produced far more prior to encountering agile for the first time 4 years ago. Horrific.
@juliepagano @iarna I remember stumbling upon a web site which looked like it was "the source" for the Agile movement. I read all the founders' descriptions of it, and it didn't look like they agreed on much. What a weird cult.
@Urethramancer @juliepagano @iarna
This is what the founders agreed upon:
https:// agilemanifesto.org/
This is literally their agreement.
They flew in, to get together at a small conference center. This is what they agreed to.
.
I know the original site quite well. I was involved in it for quite a few years. Yes, it's full of discussion and disagreement. One could call it poorly organized. It's still here, but is read only.
in my opinion, the discussion and disagreement lead to agreement
@iarna I've had it work well a handful of of times ever. And most of those were small teams that would've worked pretty well together anyway.
@iarna yes.
@iarna Agile, when implemented properly, increases the agency of labour and decreases the influence of capital.
From this perspective you can probably understand why people can spend an entire career without ever having seen it implemented properly. Instead, they suffer through the cargo cult version where all or some of the terminology and rituals are used but corrupted to the point of ineffective process-theatre because capital insists on overriding it and calling all the shots.
@smn @iarna I agree; the operative phrase is "when implemented properly."
In my entire career, I've worked on a properly functioning agile team exactly once.
So, while such teams do exist, I tend to agree that, as a broad generalization, agile today tends towards process theater. It's the software equivalent to ISO-9001 for the manufacturing sector.
Edit: mis-attribution fixed.
@iarna Cosigning this so hard. Not to knock actual agility, but "agile" and especially "Agile" with a capital A, are exactly about micromanagement and fungibility. They are specifically designed to empower management (in the guise of planning) and disempower workers (in the form of alienation from the work itself, replaced by arbitrary and sometimes vicious metrics)
It's scientific management all over again.
"It's scientific management all over again."
@aredridel @iarna
but with post-its!
@iarna A team, choosing of its members own volition to use many of these tools? Might in fact do amazing things with them, light and agile, but that's because the power structure is not in conflict with the goal or anyone's humanity.
But the moment it's trying to coerce more work out of workers, which it always does when there's adverse power structure, it turns into this. And that's the key to the deception: if you ignore the power structure it all seems fine.
@aredridel @iarna yeah, agile is so outdated ans backwards, it's laughable, but then again, it's capitalism. a pyramid of bosses controlling theirnhuman resources and it will never end until workers start owning the means of resources and connect with each other tonrun the businesess themselves sadly... ..hope we will get there one day, but then again, most workers get enough money to stick with this shit and just occasionally bitch about the management with no real intentions to change anything
@serapath https:// abookapart.com/blogs/press/mee t-the-book-you-deserve-a-tech-union-by-ethan-marcotte :D
@aredridel @iarna
In the early days of "agile," I experienced two local companies that quite intentionally chose Extreme Programming and "forced" it on their employees, and were quite successful at it, with nearly all employees being really happy about it. And yes, it did get more useful and valuable work done per person. That wasn't the goal. But it was a really obvious effect.
My experience has been, that in a positive environment, people like getting more useful stuff done.
@JeffGrigg out of curiosity, who actually chose? Companies don’t decide things so much as people do.
@aredridel
There is the usual problem of the decision processes of upper management are opaque. And one is practically never given any rationale for decisions. And rarely does anyone publicly take individual responsibility for any decisions.
But it did seem clear, in both cases, that the decision "came from the top." *Everyone and all projects* in both relatively small software development shops were doing it. And both upper and lower management required it.
@JeffGrigg I am _shocked_ that worked TBH
@aredridel
It's not easy.
But it has been done.
Quite successfully.
@JeffGrigg I'm much more interested in the usual and general cases — unless there's clear insight into _why_ it worked well. Merely using the tools is (I speak from experience) not enough.
@aredridel
As a team member, I have encouraged, inspired, and led a number of teams to be more agile.
On one project, I walked in the door and the Business Analyst handed me the project plan, which started with a month of writing code to populate this application's database with derived data computed from data it would read from a data warehouse, and then we could start building the screens.
...
@JeffGrigg Now being more agile, that seems great, but to _be Agile_, and especially Do Agile, that's where things always turn suspect to me. And even so, agility is in tension with durable, quality-checked, compliant, often.
@aredridel
I said, "I don't want to do that. Show me the first screen. I'll make that work first."
"But it'll be too slow!!!" he objected.
I said, "But we'll see real numbers on the screen, for demos. I'll do performance optimization after we first see it working."
So I got the "summary" screen running, with correct numbers. And it was slow. And the business owners sponsoring this project tried it out, with real production data, on the most important customers. ...
@JeffGrigg Yup. But at the same time, I've seen so many corners cut. "We'll come back and fix that security bug” “That temporary patch will totally get fixed” “That case only happens to a few users, we'll handle it manually. (that user happens to be me, and it outs me as transgender to an entire company while the manual process is handled by someone on vacation or who no longer works there)”
@JeffGrigg And at the same time, that's not an agile system, that's prototyping. It's quickly doing something to prove a concept, not Being Agile To Be Agile. Once it's the thing measured, it goes sideways.
@aredridel
At one of the companies that did Extreme Programming on all projects, we did a project with a production release every two weeks, for nine years, adding features with each. Then the customer decided to "insource" the development back into their company, and continue development there.
(... and probably made "hash" out of the automated tests, etc. after that. But it's impossible for me to know for sure.)
@aredridel
They verified that the numbers were correct. And they also immediately realized that their business justification for the project was fatally flawed. The system was supposed to show the customers that they should switch to the new pricing structure, but the actual real-world numbers quite clearly showed exactly the opposite. ...
@aredridel
Clearly, no one had done the proper due diligence, to check the business justification, with data from their data warehouse, before proposing, funding, and staffing the project.
"Not a serious problem!" I said, "Just adjust your marketing program in any way you may need to make it successful, and I'll make the system do that. We're only a week or so into this multi-month project. We can do an entirely different plan, if you can come up with one."
...
@JeffGrigg nice :D
@aredridel
But they were completely unable to even try to come up with a new business marketing plan. I don't know how many months it took them to come up with the completely unviable business plan in the first place. But they immediately gave up, and canceled the whole project.
...
@aredridel
While my employer, a contracting company, "hated" me, for losing billable hours, I would call this a big business "success" for the customer, as they saved most of the project funding, for what turned out to be an entirely unviable product. And we could have implemented a different business plan, if they could have come up with one, for practically no additional money.
...
@JeffGrigg Ooh, there's one of the power dynamics that often wrecks things — how did that get managed?
@aredridel
The official "Project Manager" on that project was mostly absent and "hands-off."
The "Business Analyst" had been "planning and managing" the project, project plan, high level designs, etc.
... until I walked in, tossed the plans, and said, "To heck with this. I want to do agile!"
And he said, "OK. I'm willing to go with that."
@aredridel
It would have been even worse for them if they had done all the marketing for the system to the customers, as intended. And *then* found out that it was unviable. And then they'd pretty much *have to* roll it out and support it, long term. And it would provide them *no business value at all*, because it was clearly going to fail to achieve its business objectives.
So I saved the customer *a lot* of money.
(I and my employer lost out, however. )
X
@JeffGrigg Sounds familiar — we followed an "agile" system to exactly that end in my last job. Rapidly iterated while viability was never checked. And several people had performance problems because nothing was grounded in reality, so “didn't work hard enough” or “work is bigger than expected" were always abstract.
@aredridel
If your "Performance Evaluation" is based on "Did you produce Lots and Lots of Code?!?", then solving business problems with little effort and low cost is *NOT* something that is rewarded.
@JeffGrigg Yeah, not even “lots of code”, just “did you do the next 'agile' increment?”; And in this case, there was no easy way to validate some things. And a lot of it was fixing a lumbering system that needed replacement. (at least they let me hedge on that and replace only part at a time, instead of a big System 2.0 rewrite)... but a lot of things have no value until they're done. Not a lot of smaller things you can validate with.
@aredridel
Decades before there even was a thing called "agile software development," I was refactoring existing legacy systems to improve their designs. Quite successfully.
That was long before there was a word for "refactoring." And honestly, I didn't want there to be a word for it. If there was, a number of my "superiors" ("managers") would most likely have ordered me *NOT* to do "refactoring."
@aredridel @iarna Exactly this! Xi have been on "Actually Agile" teams before (we got an app into government hospital ERs in 9 months from a cold start!) but as soon as management dictates JIRA, for instance, the agility goes away.
Can't apply No True Scotsman if we're actually talking about Austrians any more than we can call a workplace "unionized" just because management quoted Marx in a presentation that one time.
@aredridel @iarna I've found that the task estimation and planning tools available in Agile are great for both self-management of teams and enabling workers push back against unreasonable asks and timelines from management.
That's not an argument in support of Agile, but rather an argument in support of co-opting tools developed for Agile to the benefit of workers and teams.
@tess @aredridel @iarna
That was the purpose of creating those tools in the first place. Please feel free to use them that way, as often as possible.
@iarna Absolutely no argument from me whatsoever. It's also added to meeting load, involved unhelpful and pseudo-competitive activities like "story point bidding", and damaged team morale. All that, and I've never seen it actually add anything to a team of mine.
Even worse is that I often work in firmware and other low-level components, which are tied to the inflexible schedules of hardware design and factory runs and which commands a more "waterfall" process; Agile kills in these environments
@iarna This accords with my experience as well. Ceremony can never replace thinking without loss of quality. So either we don't care about quality or we don't do agile.
@iarna @aredridel And some flavors even smell like sects. I once attended a Scrum meetup (topic sounded fun: parallels between agile processes and dancing tango) and in the Q&A part someone asked a good (that I can't remember) and the speaker's face petrified, he grabbed a self printed copy of the Scrum guide from his desk (really, he brought it to the meetup ), held it up like a TV preacher a Bible and said with a quavering voice: "This … this … is not in the guiiide!"
I can be considered lucky they didn't do a collecte at the end
@iarna almost like the problem isn't with the latest software development methodology or process, but with the project managers.
@iarna Taylorism is a helluva drug.
@iarna @kstewart have you found a viable alternative? (I ask not to be combative, but out of genuine curiosity. Color me skeptical on scrum at least, if not most of agile.)
@iarna do you think there is something(s) about agile that makes it more susceptible to micromanaging and/or treating programmers as fungible?
@piannaf @iarna For a start, though I think this may not be what the more experienced people here would say: Most flavors of agile seek to reduce the relevance of a contributor's individual knowledge/wisdom to the level of atomic features. So if you lose this one person, your productivity loss (in theory) is highly constrained. As I say, more experienced devs will have more to say than that.
@FeralRobots @iarna It's interesting to see this from the perspective of mitigating the risk of losing a person.
In my experience, orgs that try to reduce relevance of IC knowledge to individual features within an agile context usually do so in service of "higher velocity" (a term made famous by Scrum flavors). They believe that by specializing ICs to a specific area, they can optimize assigning relevant tasks and thereby increase velocity.
Do you see that as well?
@piannaf I have very little personal experience working on an agile team, so here I'm talking about the experiences of others, & I think the way you're putting it would be consistent with what I've been told. Your observations are clearly first-hand, so I defer. That having been said, my general experience is that more specialization causes problems. But my career has mostly been in more or less heterogenous web stacks where too much specialization can be deadly. @iarna
@piannaf Nah, it's been reduced to a management trend, and this is what happens to every management trend regardless of what it was or how it started.
My thesis is that most "agile" shops do not embody the values of the agile manifesto. It requires culture change and culture change is really really really hard to plug into an existing org. (And it's even hard to maintain in a new org, because every hire will drag you back toward the industry mean -- which is why fast growing startups risk a tipping point where their culture evaporates.)
(Total Quality Management is my go to example of this same phenomenon happening in other fields. Education reform is another example -- we've had better ways of schooling our kids for ~100 years now (starting with the New School movement) but getting those changes to stick seems depressingly difficult.)
@iarna it does seem bizarre to me that somehow software developers managed to convince a whole industry that their weird idea about how to manage a project was better than the normal way but at the same time it has not caught on even slightly in literally any other industry, like traditional management is definitely a lot of bullshit but how many times have techies come in and changed everything and actually improved it?
@andrewt @iarna
"the normal way" is carrying a lot of weight here.
In World War II, W. Edwards Deming developed the ideas of "Total Quality Management." He took it to Japan, to rebuild. Toyota built on it to create "Lean" (manufacturing, and later design and software development)
Toyota used this to darn near put our Detroit automakers out of business. They have never really caught up or recovered.
...
@andrewt @iarna
The agile community was initially skeptical of this "lean" software development thing. But as we learned more, we found that, in spite of starting from completely different places, with very different values and direction, both do end up with similar and even overlapping final results.
So all "agile" leaders that I've seen have embraced "lean" methods.
And all "true agile" projects I've heard about mix "agile" and "lean" methods.
...