Using Agile for Evil…part one

So, you’ve bought your purple and green suit. You’ve constructed your secret lair. You’ve designed your doomsday device and acquired your hench-people. What’s next on your road to supervillainy? Villainous Agile! Yes, here is how you, as a supervillain, can use Agile for evil while following all* the rules (after all, you don’t want to get caught)!

*Note: using Agile for evil does require “innocently” ignoring or misreading the Agile Manifesto, and the principles and values of Agile, Scrum, SAFe, and all the various other Agile frameworks and methodologies.

If your villainous goal is to make your engineering team miserable, then the Scrum Master role is the ideal position for you to do it from. After all, it already has the word “Master” in the title—how appropriate! As the Scrum Master your role is enforcing the rules of Scrum. As a villainous Scrum Master, you should enforce them strictly. Remember: as a villainous Scrum Master, you know best!

Let’s start with tasks.

Taskmaster

Tasks and scheduling are essential to ruining a team’s morale. It’s well established that teams rarely manage more than four hours’ work in a given day (perhaps five during brief periods where they have no outside interruptions). After all, teams must also contend with:

  • Reading and responding to emails
  • Discussing and solving issues and impediments
  • Tracking dependencies
  • Assisting, coaching, and mentoring other team members
  • Social interactions, particularly with the boss (unavoidable, especially if you are also the boss)
  • Randomizations and “shoulder taps” from non-team members
  • Updating progress on tasks and other record keeping each day

Plus, people lose time when making “context switches” between activities, so distractions like these eat up even more time from the schedule than we’d think they would. If you give your team buffer time to handle this extra work, you’ll never break their wills.

Thus, when you determine your team’s sprint project hours, it’s vitally important to overload them. Overload is the first step to failure. I recommend starting with at least six hours of expected work a day. It’s almost credible that a very hard worker could get that much done, so team members will feel guilty when they can’t manage it, encouraging punishing overtime, exhaustion, and costly mistakes. The ideal is still to assume members will manage eight hours of uninterrupted project work a day, but being that blatant may get you caught.

People Under Process

Tasks are also useful because they, themselves, are extra work that contributes nothing to your project. The more things you can turn into tasks, the less work your team can actually do. There are things your team does that aren’t code, so make those are tasks too. And you, of course, should create all the tasks for your team, as being a villainous Scrum Master, you know best. Remember, in addition to creating tasks that will implement User Stories (designing, coding, building, automating, testing, documenting, deploying, etc.), you can also burden your team with tasks for:

  • Attending daily standup (20 minutes per day, per team member, plus appropriate travel time)
  • Attending meetings (Sprint Planning, Grooming, Review, and Retrospective, plus team meetings, one-on-ones, etc., including travel time to and from meeting locations)
  • Performing code reviews
  • Preparing for the sprint demo
  • Supporting production issues
  • Investigating and fixing bugs
  • Implementing retrospective action items
  • Legally-mandated rest and bio breaks. Yes, as a villainous Scrum Master it’s very tempting to skip these, but in most places paid breaks are mandated (for example, hourly employees are legally guaranteed a paid 15-minute break for every four hours they work). Since you’re being villainous while obeying the rules you will need to include these.

Wow, that’s a lot of tasks to write and track! But you can always have your team members enter and update these themselves using your list. It’s less work for you that way. Provide a template for them! Templates can help you discourage independent thinking.

Part two is already posted.


ABOUT THE AUTHOR:

Sarah Stewart, SPC5, CSP-SM, CSP-PO, CSM, CSPO

Sarah is a Senior Technical PM, Agile Coach, and consultant. She helps organizations, from individual teams all the way up to the enterprise level, adopt Agile/Lean practices and frameworks. She works as a coach, trainer, mentor, and writer. Read more of Sarah’s work on LinkedIn.


Leave a Comment

Your email address will not be published. Required fields are marked *