This week, Sarah Stewart has been unfortunately…tied up. Instead, we have a guest blogger this week: The Evil Agile Coach.
--
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.
You Underestimate Me
It is widely known that human beings are really bad at estimating things. This creates another opportunity for you to spread confusion and misery. Each of your many tasks needs an estimate. Normally the person doing that work would provide one, as they know what’s involved—but of course as a villainous Scrum Master, you write those estimates instead.
There are down sides to this, of course. First, if your tasks and estimates are wrong, you’ll look bad. Your burn down charts won’t be nice glide lines like they’re supposed to be. One tempting option is to give your team very generic tasks that turn their burndowns into more of a timecard: eight hours of work done each day, no matter what. This gives you a perfect burn down every week and encourages dishonesty in the team, which helps to corrode relationships, but it’s also an easy way to get caught.
Alternatively, you could just track tasks for 4-5 hours per day, per person, instead of 8, and go back to only writing the tasks for fulfilling User Stories. And you could require that the team write their own tasks, instead of doing it for them. That sounds like a lot less work. As villainous Scrum Master we want less work, not more work, right? But ultimately, the decision is yours: is the extra work for you worth the suffering you’re able to inflict?
Wrecking Ball
Let’s try a different tactic for implementing villainous Agility. I’ve heard it said many times that a good Scrum Master is a bulldozer and a shield. That means they push away the things that prevent the team from getting their work done (bulldozer) and protect them from outside interference (shield). This helps the team get their work done efficiently. But you’re a villainous Scrum Master, so bulldozers and shields are for chumps.
If you want to make the lives of your team miserable, while strictly following the rules of Agile Scrum, here are a few ways you can maximize the damage from every blocker or outside distraction:
“Tracking” Impediments
By definition, part of the Scrum Master’s job is tracking and removing impediments. As a villainous Scrum Master, you should definitely write down all of the impediments mentioned during the daily standup meetings (which are, of course, scheduled at a super-inconvenient time, so at least half the team can’t attend, and always start randomly and run as long as possible). But you can’t possibly be expected to solve them. You don’t have enough information, and a villainous Scrum Master doesn’t ask for more information, or details, or help. A villainous Scrum Master ignores the problem. After all, ignore a problem long enough and it goes away on its own. No worries!
Inflating Team Velocity
Be sure to compare your team’s velocity against other teams in front of management. Brag about how great your team’s numbers are. Each sprint be sure to inflate your team’s point values, so the number gets visibly larger. This not only focuses your team on metrics instead of actual quality, it also encourages them to cover up areas where they’re struggling instead of seeking help or support from team members.
Pointless Sprint Demos
Don’t invite anyone outside of your team to your sprint demos. Definitely not stakeholders, other teams, managers, or even your Product Owners. Villainous Scrum Masters do not voluntarily share information. Villainous Scrum Masters don’t celebrate their team’s successes—hide any great work your team has done from others. And they don’t look for feedback to verify the work is heading in the right direction. Villainous Scrum Masters understand that sprint demos are just busy work – another valueless activity to distract the team.
Painful and Pointless Retrospectives
Retrospectives are an excellent time for villainy. Be sure to point fingers and blame anyone and everyone else for your team’s problems. Invite lots of people from outside the team: managers, stakeholders, even people from other teams. Shame should be public! Make things as uncomfortable as possible for everyone involved.
At the end of each retrospective, select as many action items as possible to implement the next sprint. That guarantees your team won’t finish any of them. Villainous Scrum Masters aren’t about making improvements.
Alternatively, take the concept of “relentless improvement” to an absurd degree. Complain loudly whenever your team isn’t improving. Make your expectations so high that they can never possibly reach them.
If you do all these things your team will likely consider you the worst Scrum Master ever. And that is your goal, right? To make people miserable while you gather the funds for your death ray?
Agile for Evil and Profit
Or is Scrum Mastery a route to something greater? Micromanaging a Scrum team is, after all, lots of work, leaving you with less time for your pet projects. And Agile is surprisingly good for innovative, one-of-a-kind projects like death rays or globe-spanning computer viruses. Consider this: you could instead use Agile principles to help build your death ray.
Agile’s values and principles, warm and fluffy and soft-hearted as they look, might be just the thing to help your team get their work done faster. Happy hench-people are loyal and motivated hench-people, and they usually do a lot better at getting the job done. Plus, they’re less likely to testify against you in court!