Today I ran across a highly entertaining post on Volokh which links to a manual on sabotage used during World War II. Most of the stuff in the manual is standard stuff, fires, blowing up machinery, etc. However, the really entertaining stuff begins on page 28, which is the "corporate" section. It details how to cause corporations to drive to a halt.
There are many other blogs that could dissect and twist this into any number of ways. Most of them have noticed how government tends to follow all of the recommendations as standard operation procedure. But since this is a blog which has primarily focused on programming, I'll spin this towards Agile/Lean project methodologies and the old Waterfall standby. And some of this I'll just spin towards IT in general.
So open up the PDF and skip ahead to page 28 of the Simple Sabotage Field Manual (page 32 in the PDF) and lets enjoy the mayhem. Some of these are a bit harder to connect, but they're spinnable, and what's the fun without spin?
Step a-1: Insist on using "channels". No changes to your project to deliver what is actually needed when you notice it. No team authority. Push your request up, get the change orders done, then work like hell to make it happen.
Step a-2: Make speeches. You know the guy who rolls into a project tells you you're doing it all wrong, and your management listens and tells you to do it a different way? That's this step.
Step a-3: Refer matters to committee. Same as a-1.
Step a-4: Bring up irrelevant issues. Attempting to change work in the middle of a development iteration/sprint. Unless you've got a major production outage, the issue can wait until the end of your work cycle.
Step a-5: Haggle over precise wording. This is more of a problem when you cannot get good copy up front. It can delay your work in waterfall and agile, so this one is just bad all around.
Step a-6: Reopen closed issues. Reopening the design of the system without a major problem that you actually need to solve. Creating more work for works sake, not because there's debt to be paid off.
Step a-7: Advocating "caution". Extra concern raised due to the unknown. This is bad for a team since it reduced the confidence to achieve success.
Step a-8: Be worried about authority to make a decision. Being afraid to make a decision since you might not have authority. You should have authority. This is similar to a-1, a-3.
Step b-1: Demand Written Orders. Well, we all need specs, but in Agile/Lean, we're getting those as we need them. We don't require the entire system be specified.
Step b-2: Misunderstand Orders. Quibbling over specs. This seems to occur when the business is not involved and rolls in several months down the line and says this isn't what they needed. Eliminate using Show and Tells.
Step b-3: Don't deliver until completely ready. Big Bang approach to delivery of software. Yep, that's Waterfall.
Step b-4: Don't order new working stocks until completely gone. This is what is known as Kanban isn't it? Pull work into the queues. There is no pull, only the schedule.
Step b-5: Order high quality materials which are hard to get. I'll change this one. Order expensive software/hardware that require expensive maintainence contracts. Especially when there's a well maintained open source project that your company could fund 2 developers to work on full time at a much lower cost.
Step b-6: Don't prioritize properly. When the business does not work with the development team to prioritize features, then the wrong thing gets prioritized by one of the two parties involved.
Step b-7: Insist on being perfect. Misuse of metrics. Insisting on 100% code coverage, zero issues in your quality checks as though it will eliminate Technical Debt. It won't. It will just make you move slower and ignores fixing the most expensive debt.
Step b-8: Mistakes in routing. Sorry I got nothing here.
Step b-9: Give trainees misleading instructions. This is more of a problem of new programmers not given enough time to gel into the new team. Train them through pair programming.
Step b-10: Be pleasant to ineffective workers, give them promotions. Um, Dilbert cornered the market on this one.
Step b-11: Hold conferences when there's important work to be done. Eliminate meetings. Prime Agile/Lean principle.
Step b-12: Multiply paper work. Unnecessary documentation for sure, but also poor technical design which doesn't allow for code reuse.
Step b-13: Multiply procedures. Too many people required to approve change controls, code sign off. Increased bureaucracy. Agile, Lean, ITIL, even Six Sigma applied to software have reduced these issues. And more than likely, unless their a micromanaging jerk, the upper management doesn't want to be that involved.
Step b-14: Apply all regulations to the last letter. Ever have a simple problem in a production install. Say a test property file was installed instead of production and the entire project is backed out rather than let the team fix the problem on the fly? Yeah, me too.
There's more comedy gold in here, but since I like to blog by the seat of my pants without editing, I need to stop. Heck, I've got a 1pm meeting to attend that is, well...let's just say that a-1, a-4, a-5 are to blame for this b-11.
