A Guide to Defeating Scrum: Transparency, Inspection and Adaptation

https://unsplash.com/photos/g5LfGg_30ZI

You’re someone who wants this Scrum thing gone. It threatens your role and it must be defeated. You’ve chosen to target the three pillars of empirical process control in Scrum:

  • Transparency
  • Inspection
  • Adaptation

With these a Scrum team and indeed your whole organization claims to manage risk, reduce waste and increase the value of their work. What a crock. I’m here to provide you with the tools you need to ensure Scrum teams depend on you to know what’s happening, the nature of their work, what needs changing and eventually argue that “Scrum isn’t needed here.” This is the post you’ve been waiting for.

Oversight is Might

Developers, right? Give them an inch and they take a mile. Left alone with the problem domain, some technical excellence and access to the market and theres no telling what they might do. No, that won’t do. Your best bet is to use the stories and anecdotes you’ve collected over the years of rogue developers spending months playing with shiny new tools and producing absolutely nothing of value to anyone. Whatever they produce will be brittle, unusable and riddled with defects, right? Honestly, this is probably the strongest argument you’ve got to persuade your bosses that you controlling their processes, tools, interactions and ultimately the developers themselves is in everyone’s best interest. If you’re really on a roll, just remind your exec buddies how geeky developers are and how much they remind you of the rejects you trolled each day in high school. Neeeeeeerds.

Keep an eye on the outliers who spend extra time to understand the business domain, learn the business model, polish their client interactions or *gulp* maintain active feedback with those clients for whom work is delivered. They could be real trouble. Something I’ve seen work is an appeal to efficiency and specialization of labor. These are highly paid individuals that cost you and your buddies real money. Their skills are best utilized in the typing of computers codes on their terminal…screen…displays. Definitely look into measuring their lines or code and/or function pointers to show how that bothersome client interaction takes away from their main responsibility: programming codes per minute, or whatever.

In short, your opinion is the only transparency your organization needs. You are the only person that “speaks geek” and can possibly do the job of directing these hapless, social outcasts to produce anything of business value.

Happiness is Everything

Ok bear with me here, it’ll be worth your while. Inspecting the true state of things can be hard and may produce frustration and unhappiness for a short while. Developers love to talk about how they make better stuff when they’re happy. You know, like how happy cows make better milk or some hippy bull shit like that. Use that. Since most of your developers really just love to code program app routines, show them how ready you are to handle all that messy inspection overhead for them. Oooh, ooh bonus…call it servant leadership. Oh man that’ll really win you points with the HR department. Plus, take each opportunity to complain about your job and the hassle it is to talk to customers, predict work schedules, justify project spending and other big boy tasks like that. Scare and / or bore the snot out of them until they see what you do as a necessary evil, one you are just saintly enough to do for them.

Autonomy is Overrated

Don’t forget how much the millennials love talking about their “dream job.” Trophies for everyone, affirmation workshops, and safe spaces have laid the foundation you need to hornswoggle those Berkeley graduates in your organization into abject subjugation. Take control of every process and interaction that is remotely annoying to them under the auspices of keeping them happy. Do whatever it takes to make them feel safe. Allow them the activities they like to do and you will guarantee you control the real work that will make you indispensable. Any of the bothersome change that is needed will be your burden to bear.

Clothed in the adoration of specialists you’ll have a powerful position as the fixer and change manager. You’ll ensure a stability and a predictability…of sorts. Occasionally the market or technology may change and throw a monkey wrench into your plans. Not a problem. Bring in a chair masseuse, order some BBQ, set up an xbox or even a pup tent room for those long nights, weekends and even months that are just part of the reality of software development.

Well, not for you of course.

Control Over Trust

You may hear some in your org saying that the foundation of the whole Transparency / Inspection / Adaptation structure is trust. Ok, combatting this trust thing will be a challenge, but I think I can see you through it. Trust sounds good but why open yourself up to the risk? Trust mongers will try to sell you on the benefits of open communication, straightforward relationships and other such ruinous activities that expose you (especially you) and your organization to all manner or vice and debauchery. A combination of contracts, fear and status quo is the way to go IMHO.

Emphasize the need to cautify expectations in contracts or service level agreements. The key here is to establish an unknowable abstraction between the customers and those doing the work with you as the broker.

I’ve also seen great success by hip checking change makers with the phrase, “That’s the ideal, but in reality…” Just keep saying that our clients aren’t ready to be trusted or that departments just aren’t ready to trust each other. Bonus points to you if you can convince developers and product owners that they can’t afford to be straight with the customer because the customer is out to get them with all those spurious feature requests.

Lastly, downplay the pain the Scrum team has identified in their Retrospectives by emphasizing that things aren’t that bad really. The pain of “improving” things isn’t commensurate with pain of just doing what has been working ok for the last few quarters, amiright?

Summary

Do everything you can to remove the motivation and permission the Scrum team has to bring transparency to significant aspects of the process, inspect its progress towards Sprint goals, or adapt one or more aspects of its production that are found to be unacceptable. You alone can translate the true state of things. Your insight is irreplaceable when things are in flux. You see the true way forward. You alone keep the hounds of change chained in their kennels. Use the perception of millennials as narcissistic and entitled children to cement your parental control. Show trust as the pipe dream it is and frighten the crap out of anyone who dares to dream large.

The trifecta of transparency, inspection and adaptation may be the greatest challenge to your control you’ve ever faced. Those enamored practitioners of empiricism could potentially dethrone you as the authoritative source of what is reality in your organization. If that starts happening, it’s time to move on. Find a nice startup with investors that require surety, start by hiring only junior developers, and invest in an Xbox One.

jknight

Jason is a developer, Scrum Master, writer, teacher, coach, husband, father, and community leader out of Tulsa Oklahoma. He's been delivering software since 2007 and absolutely loves the values and principles of agility especially as given form by the Scrum framework.