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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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!"
"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.
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.
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. :-)
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.
> Haggle over precise wordings of communications, minutes, resolutions.
> Advocate “caution.” Be “reasonable” and urge your fellow-conferees to be “reasonable” and avoid haste which might result in embarrassments or difficulties later on.
I do both of these things.
Do I want to destroy my organisation? No. I want to prevent miscommunication and haste from destroying it.
I dislike the popularity of this list for this reason.
That's the point of this document. To enumerate types actions which are:
* 100% valid and necessary in some contexts (this is your point IIUC)
* ...but can nevertheless be used for organizational sabotage if overdone on purpose (point of the article)
* ...and lead to Dilbert hell if done because of bad incentives (the reason why this article keeps being so popular among office workers)
> Do I want to destroy my organisation? No. I want to prevent miscommunication and haste from destroying it.
And yet, do you not see how if _every single thing_ that your organization does went through this process, it would find itself in gridlock of decision making? How would your organization fare if it has to spend two weeks just do decide if the paper cups at the water cooler should have knurled or smooth bottoms. Or if the decision over whether you should implement a minor feature that would take an engineer half a day takes several months.
The manual isn't suggesting advocating caution when it's needed, it's advocating extreme caution when none is needed.
I think that's the reason why this list is so clever.
It is made so that it is hard to tell the difference between sabotage and being genuinely helpful. If you ask people to advocate caution when you know there is a good chance for an accident to happen, it is helpful. If you ask people to advocate caution even though the risk is low and everything goes well, it is sabotage.
Precise wording may be important in a legally binding contract, or when misinterpretation can have serious consequences. The way you sabotage is by doing that on points where it doesn't matter. For example, let's say you want to publish a memo telling people to bring back the encabulator to the store room after they finished using it, a common sense reminder. A saboteur can start arguing what is meant by "finishing", for example, what if it is needed an hour later, maybe suggest a logbook, special rules about overnight use, etc... when in reality, all that is needed it to remind Bob (who may be a fellow saboteur) not to be an asshole.
I've seen cases where 100+ people were required to attend multi-day meeting marathons to agree on the perfect sprint goal formulation, a negotiation held hostage by a few pedants that were never quite happy with the exact wording.
That's like 2000 man hours down the drain to produce a sentence I'm not even sure who is the intended audience for.
The flipside is seeing thousands of hours wasted building the wrong thing because people couldn't be bothered to communicate properly. "Getting the words right" turns out to be a fundamental step for producing successful software - not because the words themself are directly important, but because it's a reflection of a robust mental model of the problem.
To be clear, these wordings has no impact on what was to be built, that had already been decided at a separate set of meetings. This goal setting meeting was sheer process.
At some point, the cost of building not quite the right thing has to be weighed against the cost of spending literally millions deciding on what to build next.
There is a difference between what is perceived as effective communication and what is actually effective communication. More communication for the sheer sake of more communication almost never means more effective communication or coordination.
Honestly, it sounds like there will still be a few pedants who disagree with the phrasing of this new Commandment.
To me, what you described sounds like both Hell and entertaining Theater; Theater the first couple of times, Hell at 3+. It’s alternatively The Ninth Layer Of Hell if I have to provide input at any point for any reason.
I don't think the simple symptoms lead to the illness in this case. Which is to say, even if you do these things, you might do them in a well intended way, and with an overall positive impact. Lawful good and lawful evil are both lawful. Law in itself doesn't indicate evil (or good, for that matter!).
I think both of you are holding the idea of ranking organisational strategies on a linear scale. But what works for a tech startup might not be good for operating a chemical plant.
The worst cases of pointless busy work I've seen were when everyone follows an out of date plan that they know is out of date because the effort to change it is too high.
Everything exists on a gradient. Your goals are valid and methodology probably as well if you meet them.
Do you discuss the minutiae of what you guys can eat for lunch? Probably overdoing it.
Do you discuss the minutiae of a technical piece of equipment or software that is mission critical? Probably the right kind of effort to be as precise as possible.
I like the idea of this, but many of the list items come off as things the author doesn't like.
Lets restate some:
"Insist on doing everything through “channels.” Never permit short-cuts to be taken in order to expedite decisions." -> "Insist on doing everything through 'short-cuts'. Never permit official channels to be taken in order to expedite decisions"
"Bring up irrelevant issues as frequently as possible." -> "Insist that things you don't like are irrelevant as frequently as possible."
"Haggle over precise wordings of communications, minutes, resolutions." -> "Argue that people are being caught up trying to be precise, leading to documents that are lacking precision"
"Insist on perfect work in relatively unimportant products" -> "Insist that products are unimportant and so sloppy work is ok"
"Hold conferences when there is more critical work to be done." -> "Claim that doing work is the only important thing and that communication is wasteful"
"Do your work poorly and blame it on bad tools, machinery, or equipment. Complain that these things are preventing you from doing your job right." -> "When you have the right tools and equipment, use them well, but then claim you are just really talented and that a master can work with poor tools."
"Never pass on your skill and experience to a new or less skilful worker." -> "Watch new workers like a hawk and never let them think for themselves."
The idea is interesting, the implementation in the article is tepid.
I bet a lot of people already know Technology Connections, but I like to bring up the first video of his that I ever watched at a time like this - that's right, the one about heat pumps!
He goes on this rant towards the end about Midwestern Values and I had been living in Indiana for about 5 years at this point, and nobody ever explained it to me so concisely and bitingly accurate what that perspective was. The short version in a picture of the story is the old man going up two flights on a rickety old ladder to check the roof, because he's been using that ladder for 30 years and it's "perfectly fine." You should get a new ladder, or you'll probably kill yourself!
The ladder is not perfectly fine, and each year he goes on using it the risk gets bigger. But we don't strive for perfection because we're used to "making do" with "good enough" tools. I could never make these my core values. As a professional, I need the freedom to bring my own tools, and as a full-time employee I'm going to need the right tools provided on the job site (because it's not in my contract to provide my own tools!)
As an app dev for non-profit corp whose primary business is not app development, I couldn't hack it here. I still live here, but I work for a foreign company now, on the open source project that I wish we could have adopted to make my life as an app dev a bit easier, or at least a bit more livable.
Your perspective on this classic document (that gets reposted at least once every year) reminds me of this struggle of my own.
I haven’t seen this before and I can’t verify with the link to the actual field manual because it’s a 404. Does anyone have a PDF of the actual manual handy? (Edit: https://en.wikisource.org/wiki/Simple_Sabotage_Field_Manual/... Scroll to section (11a).)
The article seems to suggest that these things were lifted from the actual manual. Perhaps they cherry-picked these over things that are more relevant to commercial office work, but I would suspect instead that the statements which were excluded are less relevant.
If that’s the case, these are hardly things simply which the author dislikes. In the author’s own words: “If you are like me, many of these things sound surprisingly familiar.”
Perhaps the other methods as suggested by this comment’s parent are less effective (as an intentional means of sabotage) and so were excluded. It still seems worth it to be aware of these things and especially to look for them being perpetrated in bad faith.
they were not things from a modern author. They're direct quotes from the office of strategic services (so old that it's from before OSS was the CIA). Quick google would have helped you know that. https://www.cia.gov/stories/story/the-art-of-simple-sabotage...
Part of the purpose of the document is to sabotage surreptitiously. If you always take shortcuts and something gets messed up, it's easy for people to see that you were the cause. However, if you always insist on doing things through the proper channels then it's a lot harder for people to see that you're the problem or argue against your methodology.
> Lets restate some: "Insist on doing everything through “channels.” Never permit short-cuts to be taken in order to expedite decisions." -> "Insist on doing everything through 'short-cuts'. Never permit official channels to be taken in order to expedite decisions"
You're doing this wrong. The list tells you not to "Never permit short-cuts to be taken in order to expedite decisions." Not and Never cancel out, leaving you with "permit short-cuts to be taken in order to expedite decisions"
Permitting shortcuts is not an insistence on always taking shortcuts. Your other "restatements" aren't any better.
I think I agree with you —- phrases like “irrelevant issues” and “more critical work” are so subjective, that everyone can read along with this and agree with it, but it’s not actually saying much, since the agreeing on WHAT is relevant or critical has always been the hard part
The point is the sabotager probably has a pretty good idea of whats irrelevant and what's critical for the purpose of the organisation they are trying to prevent (or at least the former, which is all that's strictly necessary to do this).
"Irrelevant" and "critical" are far from subjective in a business organization. The goal is clear: make more money. Everything either contributes or detracts from that goal.
Far from subjective, but when they are based on speculation about how particular fixes and features will be received by customer and market, and ultimately affect the bottom line, "irrelevant" and "critical" can be uncalculable.
The most effective methodology is to implement one of the loosely agile based methodologies like SAFe Agile. Then hire consultants, none of whom have ever actually managed a software team, to make sure everyone follows the process down to the last letter. This decreases efficiency to the point that the organisation is no long able to do productive work, there is no ROI and the staff are all burned out from spending 20 hours a week in zoom meetings and filling in JIRA tickets.
I’ve definitely seen most of this going on in management teams. Especially the forming of committees as a way of bike shedding. ‘We are clueless about the problem but we do know how to make a list of other clueless people.’
Forming committees is mostly useful for avoiding responsibility. If I make a bad technical decision then I get flak. If I organize a committee to justify that decision then I might even get points for "leadership". Also, if the decision is bad then I'm not personally responsible.
To paraphrase: "Don't attribute to malice that which can be adequately explained by covering one's ass".
Although there could be legitimate hope, that one of the other people is not clueless and will bring up important points. Not necessarily only "covering ones ass", but probably also a responsible thing to do, when making an important decision. At least, if the list of people actually includes technical people who have experience with the matter.
Just yesterday, someone quoted Paul Hamming on the fact that scientists who have "open doors policy" are more successful long-term.
I have never formally formed a committee, but I often organized small one-off or semiregular circles to get differing opinions on some matter and/or to understand how to align interests. And I believe it paid off for me, usually in form of a better design or a useful shortcut around an otherwise long and dark path.
Committees can be a good fit for issues where the exact shape of the solution does not really matter as long as it aligns with constrains set up ahead of time. It frees up leadership from bikeshedding to focus on more critical issues and can smooth over company politics by ensuring that all relevant parties' opinion is taken into account.
Each of the items on the list are things you or someone else in an organisation does in good faith.
That is why these work.
When you do them in bad faith, you can stretch the timelines for things significantly while the responsibility for such a delay ends up so diffused among the bureaucracy that no one takes the blame.
“It’s just harder to get things done in a big organisation” as they say.
If you keep a lookout for these, particularly when they may be not in good faith you can head them off.
Also, I feel like they are saying maybe you can/should look into some of these things, even done in good faith, to see if they are actually helping or hurting. “Haggle over precise wordings of communications, minutes, resolutions” This may be done in good faith, but is the situation/task something that needs a ridged , precisely detailed, process and it is helping to insist on precision? Or is it something that could be done just as effectively without ridged precision? Or does it end up conflicting with other requirements?
If a report has to have days of the week spelled out (“Monday” rather than “MON”, “percent” rather than “%”) but you also have a strict limit on character count due to space constraints, you end up with less precise wording in the report. Taking a step back and looking at it from the “if I wanted to actively sabotage this process, what would I do” might allow you to see good faith efforts that end up in bad outcomes.
A lot of the comments here seem to be about discussing legitimate sabotage of a company. Meanwhile the article seems to mostly be about using common sense to be efficient and how a lot of "best practices" are actually horrible for that. So some satire.
The real issue here imo is, power structures. That's societal, and cultural. I sincerely doubt people use these to sabotage anything, infact the people who have control over such things are at the tippy top of an organization or place of governance (laws begat norms). So if that were the case um, you were screwed before you even started by who you listened to and who you worked most closely with. Not by some threat actor... IE we're doing it to ourselves by who and what we reward and it's only an evil plot if it really is being done by government agents or something, in which case we'll, see point #1.
> Don’t order new working materials until your current stocks have been virtually exhausted, so that the slightest delay in filling your order will mean a shutdown.
Did they also employ these sabotage techniques in Japan?
They did everywhere which is why the last 3 years have included massive ongoing cascading supply chain shortages across the world. It's very efficient as long as nothing ever changes too much too quickly which tends to be the case in manufacturing outside a pandemic but is much more rare in software.
The Lean/Deming approach is incredibly different, and I strongly suggest if you'd like to know more to read "Out of the Crisis".
Hilariously enough, lots of the things he says about production workers in factories is almost identical to stuff I see software people say about their jobs, so it's well worth a read.
I did a lightning talk back at devopsdays Minneapolis in 2016 titled "Updating Classic Workplace Sabotage Techniques" based on the book published on the topic. 5 min video goes through all the techniques:
The lack of sources and case studies leaves an interesting possibility open. This document might actually be fiction the opinions of someone who didn't like meetings as opposed to an effective guide.
Given that these are all common behaviours in real organisations they probably don't do that much overall damage. You'd do much worse by being effective, getting promoted and then making some really terrible but plausible decision that does decades of damage (like hiring some great marketers and going all-in on a risky venture that sounds good, but with little prospect of success). It doesn't take much effort, but once people are organised around a stupid goal it can take years to unpick.
> Sabotage varies from highly technical "coup de main" acts that require detailed planning and the use of specially trained operative...
Interesting that the meaning of "coup de main" here is the complete opposite of how it is actually used in French, where it means "helping hand". Used for informal and occasional situations. An example of a "coup de main" is when a friend gives you a few minutes of his time to help you move a heavy piece of furniture.
A lot of theses tactics appear to be used here in the UK with regards to installing cycle infrastructure, low emission zones and liveable neighbourhoods.
Just dug out a physical copy that I've got of this - a friend bought it for me a while back.
On a more serious note, this is a must read for developers and managers. It clearly identifies the paths that lead to disaster. You can see it as a list of organizational anti-patterns :)
> Amongst its responsibilities was frustrating the German war effort, and to that end, it wrote a short set of “best practices” - the Simple Sabotage Field Manual.
I read anything that's referring to Germany or Austria as a group of people close to or on the spectrum. Perhaps this is why the saying exists "it takes one to know one" when thinking of Hans Asperger!
And you have to question, are govt budgets a representation of the characteristics of society, ergo are large military budgets reflecting the violent nature of a country?
Sure it’s a fine list if your job is to churn out knockoff mobile apps or spam ads everywhere.
I myself do not write this kind of software but I work regularly with people who write safety-critical components in things like airplanes, industrial manufacturing systems, and so on. If they decided, for example, they were too good to go through official channels, some very bad things could happen.
Unironically know someone who deployed these tactics to spin the client in circles and do damage control on a gov project that was extremely doomed to fail. Can’t fail to meet the specified implementation if the client themselves can’t define what the requirements are.
It is more effective to change people, not processes. This way organization stays dysfunctional long after you leave.
So spread dissent. Destroy fairness, no paid overtimes, everyone gets the same pay. Promote one group over other without merit. Hire most annoying extremists you find. Give leadership to vapid narcisits. One film company is great recent example of this.
This is from KGB and CIA manual. They would sponsor and train extremists. Still works long after soviet union is gone.
Depends on your goals. If your goal is to effect a long-term attack on an organization, then yes, you want to introduce systemic issues that will fester.
But the Simple Sabotage Field Manual was developed in and for wartime. It was meant to provide information to dissenters and occupied peoples on how to surreptitiously affect the war effort. The time scale is far different. You needed the factories and bureaucracies to slow down as soon as possible, not have a slow decline over the years.
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.