[rightbyte]

I always knew agile was a CIA plant gone ammock. (/s?)

The article feels like one of these chain mail jokes rather than a serious article, but anyway.

"Insist on doing everything through “channels.” Never permit short-cuts to be taken in order to expedite decisions."

That bullet point list more or less describes Scrum.

[ljm]

I don’t think it does unless you take a dim view of it and perpetuate the simplistic scrum-agile bad meme.

An easy way to throw an effective team into disarray in tech is to waylay it with back channel requests and unplanned work. If you’re too busy fighting fires and working personal errands for disruptive managers and executives then you’re not delivering what your team is supposed to deliver.

The ‘proper channel’ isn’t a bureaucracy as described in the SSFM, it’s simply an ordered list of priorities with a gatekeeper.

Edit: as far as dogmatically adhering to this process goes, then any effective agile/scrum process will have a baked in allowance to handle the unexpected or adapt to change, rather than stubbornly stay the course.

[bartread]

I agree with your second point but...

> I don’t think it does unless you take a dim view of it and perpetuate the simplistic scrum-agile bad meme.

Look, the thing is, if you've worked in a load of different organisations, and lots of different teams, with other smart people and have never really seen Scrum done well, and have in some cases actively seen it inhibit the delivery of quality software, I think it's legitimate to start questioning the process. People - smart people - struggle to make it work effectively. Plus, 50% of software developers (UX, product management, QA, SRE, stakeholders, etc.) are worse than average: a process that top quartile people struggle to make work well, sometimes even under the most favourable of circumstances, is less valuable when broadly applied across the delivery professions as a whole, and over different industry sectors.

On the flip side, with any process being introduced, I think it's fair to spend some time, maybe 6 months (but it will vary, depending on the process), implementing that process fairly strictly. It does need time to bed in, and there will be areas of friction simply due to creating new habits or resistance to change rather than due to problems with the process during that time. You need time for those issues to shake out so that you can see how much value the process itself really delivers and where it can be improved. At the 6 month point you can review the process, implement improvements, and move forward. You can keep doing the same review/evolve process on whatever cycle you choose, and that way your processes are more in step with changes in the wider organisation (hopefully growth).

Your processes need to fit your organisation, your business model, your culture. So, by all means, you can start with a process like Scrum, but to be really successful with it you need to treat it as just that: a starting point. You need to evolve it to fit your business. We all like to mock cargo-culting and yet, somehow, Scrum and agile often seem to blag a free pass. I don't understand why, because they shouldn't get that free pass. Your processes need to work for your business, and they are always a means for delivering value and never an end in themselves.

[isityouyesitsme]

Scrum as a concept doesn't matter. Agile as a thing doesn't matter. Team structure doesn't matter.

All that matters is who has authority and the business both enforcing that authority and also making sure that authority is being used to accomplish business efficiently and not causing greater risk in the process. The rest just falls in to place. Or doesn't, and the business dies.

[ljm]

Yeah that’s a totally fair point, and one I took as given because it’s hard to discuss something like this if you need a disclaimer on facilitating organisational change every time the topic comes up. After explaining for years that no, doing agile doesn’t mean daily status reports and endless meetings, you start to consider that maybe these arguments are offered in poor faith and you want to focus on the good faith nuance.

Ironically, you can sabotage any attempt to apply some useful agile (or scrum) principles in earnest simply by trotting out a few strawman arguments against it.

[TheCleric]

I would also add that, in my experience, anyone who is involved with and doesn't buy into the process (any process, not just Scrum) will be indistinguishable from a purposeful sabateur.

[ljm]

IIRC this might have been covered in The Five Dysfunctions of a Team, in terms of a lack of commitment.

[patmorgan23]

On the cargo culting point. I just want to add. You can actually get pretty far by apeing what you've seen before even if you don't totally understand. You should definitely try and understand and figure out why it works but you can still get by without it sometimes.

[psunavy03]

This is all true. No one should dogmatically follow Scrum or any other framework. But the trouble is there's two kinds of people who deviate from it. Those who actually know what they're doing and can move beyond it, and those who are scared of or threatened by a new normal and want to kneecap it.

If an aspect of Scrum is inhibiting flow . . . junk it. But also first make sure that it actually IS inhibiting you, and it's not just highlighting a weakness or cultural flaw in your organization that you'd rather not deal with and pretend doesn't exist. Step 1 in moving beyond Scrum is to acknowledge the elephants in the room, feed them a peanut, and decide how to efficiently house them somewhere else.

[genocidicbunny]

The article might be a joke, but the subject of it -- the SSFM, is a very real thing. The whole point of it is to guide people on how to exploit the inherent inefficiencies in large organizations, so of course a lot of the concepts are probably familiar to us.

But you also need to understand the audience and the context. This was targeted towards people under the nazi yoke, and in many instances, if you were found to be sabotaging things, you would probably be facing a firing squad very shortly. So the point here is to exploit weaknesses in the system that also have plausible deniability.

[rgblambda]

To be fair, if you've seen a senior team member write a badly worded Jira ticket containing a large amount of possibly unnecessary work, then foist it upon a junior (Or just describe what the want in a call and let the junior write it) because they knew it wouldn't stand up to scrutiny in Backlog Refinement, you would be a bit more in favour of that rule.

[hibikir]

If you have malicious senior developers that foist work on people that would never be approved when the full team is there, your problem is not using one methodology or another: your problem is in hiring and firing.

It's one thing to have checks on other people's work to deal with honest mistakes as quality control. A system set up to show that you mistrust the decision making of your senior workers is making it clear efficiency is never the goal. If I can't trust a senior to make sure a junior is doing well, they ain't senior.

[ljm]

That kind of behaviour might only present after a long tenure at the organisation, once such an engineer sees themselves at the top of the pecking order.

At which point, it boils down to how willing an organisation is to fire someone for going rogue, or whether it’ll close ranks around the senior engineer for whatever reason/excuse and fire the junior.

[broast]

This doesn't add up to me. I thought "People over processes" was a pillar in the agile manifesto.

[XorNot]

And yet the only conversation in my daily stand up is a request to make sure the tickets are all in the right column on the board and deep consternation if the ticket has to be changed or gasp dropped in some way.

[ebiester]

I think the two are separate.

If I can look at a board such that I don't have to ask in standup what's going on with a ticket (unless it's going much longer than expected), then we can use that for more valuable conversations.

The whole point of the standup should be to handle learnings like "we don't need this work" or "we're doing the wrong thing. Let's fix that!"

[psunavy03]

"Individuals and interactions over processes and tools" does not mean no processes and tools. It means the processes and tools used in the organization should facilitate and enhance individual interactions. Everything on the right is still there, it just is used to enhance and promote what's on the left.

The best term I've heard used for this is Minimum Viable Bureaucracy. You can't ever get rid of all of it, and you shouldn't.

[psunavy03]

Half of the problem with implementing Agile is people like this who insist that shittily-implemented Agile is actually Agile implemented accurately, and then railing against the ensuing straw man.

I can't think of anything in the Scrum Guide that describes "insisting on doing everything through 'channels'" outside describing the roles and the division of labor between them. I mean, maybe in a really badly-run SAFe shop, this happens.

[pydry]

If developers do unionize this is essentially a recipe for the kind of industrial action that, unlike striking, would be very effective.

This + ramping up technical debt and seeding docs with outdated information would probably be enough to kill almost any project.

[samstave]

The thing I hate about Chain Mail is that regardless of how many links you may have in the Mail - your defenses are still susceptable to piercing by Spear Phishing. :-)

[psd1]

It's a loan word, but "amok" is the consensus spelling in English

[jurynulifcation]

I see that someone has already mentioned that it is indeed "amok". However, another slight correction: "/s" is an internet tone indicator for sarcasm. "sic"(?) stands for "spelling is correct." When simply stated, as a parenthetical like so "caret (sic) and a stick" then it means the writet is confident their spelling is correct. When posited as a question, as in "ammock (sic?)" then it expresses the authors' non-confidence in their spelling and is also an invitation for correction.

[ljm]

> "sic"(?) stands for "spelling is correct." (sic)

sic is Latin. ‘Spelling is correct’ is a backronym.

And you’d use it in writing to point out that the quoted thing is not an error or typo on the editor’s part.

[hairofadog]

I read their “/s” to mean sarcasm as in “haha, I don’t really think agile is a CIA thing” and then their question mark to mean “but maybe?”

[jurynulifcation]

Oh fair. I had not considered that interpretation.