The tragedy of Agile (IMHO) is that it started out (in the manifesto) as something like "No matter what the formal process is,when requirements change or complications arise, effective teams start a conversation about how to solve the problem. They do this regardless of process."
I have heard engineers declare a thing "Not Agile" because of esoteric disagreements about how to conduct a scrum or who attends retrospectives. I've even heard engineers declare that the Agile answer to "ETA?" is "When I'm done, old man!"
I've only worked one place that I would declare "Not Agile." It was a 6 month contract at a company writing software to be used by HR people just down the hallway. So, if I couldn't reproduce the problem they reported, I would walk the 50 ft down the hall and ask.
One day the CTO saw me doing this, and, red-in-the-face, forbade me to ever go speak to the users. Accused them of being manipulative liars. In a company of about 50 people, I was told any clarification I needed on a bug report should go through the PM.
Why? Well, so that they would "learn to write correct bug reports." But mostly, because their provocative attire was a tactic to manipulate men into...fixing the bug tickets we were already assigned to fix?!? I don't know, but I kid you not.
They weren't agile. Not because they were waterfall (there's actually nothing in the manifesto condemning waterfall), but because no amount of process ritual of any form could possibly undo an eng team that had declared a one-sided total war against their users and coworkers.
That team could observe every agile workshop ritual, and they would not be an agile team. And a team can observe all the forms of waterfall, and be agile, because they...basically ignore waterfall. If they are in design and realize a requirement was missed, they have lunch with the business analyst.
In the agile manifesto world view, process is management thing, done for the benefit of management, to meet organizational needs. Effective teams honor the forms, and then get things done. And any process works as long as no one gets in the way:
* by cultivating warfare between QA and dev
* by cultivating architects who build incoherent designs and then tell implementors "Not my problem, go figure it out."
* by telling the programmers that their users are (at the most extreme end) literal gold-digging whores.
In this understanding, one of the most unagile things in the world is actually the agile coach who walks into an effective team and declares that no one representing support should be at the retro, that people aren't saying things the right way during scrum, that story points are being used incorrectly, that nothing can change once the sprint has begun.
TrentonZero /
npub1sz…4g279
2022-08-18 23:46:22
Author Public Key
npub1szvxprymkgvxclns7rk4czsz79z50fkpenvfusgcq67ptlvctqws54g279Published at
2022-08-18 23:46:22Event JSON
{
"id": "1986c837183cdcecdfa3584880a67d6552ee45871e6bfddcf7b2c42474ff1bd5",
"pubkey": "8098608c9bb2186c7e70f0ed5c0a02f14547a6c1ccd89e411806bc15fd98581d",
"created_at": 1660866382,
"kind": 1,
"tags": [
[
"subject",
"Tragedy of Agile"
],
[
"client",
"more-speech - 202208171549"
]
],
"content": "The tragedy of Agile (IMHO) is that it started out (in the manifesto) as something like \"No matter what the formal process is,when requirements change or complications arise, effective teams start a conversation about how to solve the problem. They do this regardless of process.\"\n\nI have heard engineers declare a thing \"Not Agile\" because of esoteric disagreements about how to conduct a scrum or who attends retrospectives. I've even heard engineers declare that the Agile answer to \"ETA?\" is \"When I'm done, old man!\"\n\nI've only worked one place that I would declare \"Not Agile.\" It was a 6 month contract at a company writing software to be used by HR people just down the hallway. So, if I couldn't reproduce the problem they reported, I would walk the 50 ft down the hall and ask.\n\nOne day the CTO saw me doing this, and, red-in-the-face, forbade me to ever go speak to the users. Accused them of being manipulative liars. In a company of about 50 people, I was told any clarification I needed on a bug report should go through the PM.\n\nWhy? Well, so that they would \"learn to write correct bug reports.\" But mostly, because their provocative attire was a tactic to manipulate men into...fixing the bug tickets we were already assigned to fix?!? I don't know, but I kid you not.\n\nThey weren't agile. Not because they were waterfall (there's actually nothing in the manifesto condemning waterfall), but because no amount of process ritual of any form could possibly undo an eng team that had declared a one-sided total war against their users and coworkers.\n\nThat team could observe every agile workshop ritual, and they would not be an agile team. And a team can observe all the forms of waterfall, and be agile, because they...basically ignore waterfall. If they are in design and realize a requirement was missed, they have lunch with the business analyst.\n\nIn the agile manifesto world view, process is management thing, done for the benefit of management, to meet organizational needs. Effective teams honor the forms, and then get things done. And any process works as long as no one gets in the way:\n* by cultivating warfare between QA and dev\n* by cultivating architects who build incoherent designs and then tell implementors \"Not my problem, go figure it out.\"\n* by telling the programmers that their users are (at the most extreme end) literal gold-digging whores.\n\nIn this understanding, one of the most unagile things in the world is actually the agile coach who walks into an effective team and declares that no one representing support should be at the retro, that people aren't saying things the right way during scrum, that story points are being used incorrectly, that nothing can change once the sprint has begun.",
"sig": "38ab0b1b96987f8ef37bc6de7a9045c3c567938c7eb3544289a235a899fc0fd87ff29c2d48e3cfb351be43bab885ae27cb841702f3dd5714a989206d274e94cc"
}