6 tips for managing scrum broken

1. Count individual scrum team members on story points

Story points are a measure of the amount of work the team must do to finish a user story. A well-run team is motivated to process more story points each subsequent sprint. So a story point is a team effort, depending on how well the members interact. The best way to beat the motivation out of this is to simply treat team members as redeemable resources.

You can do this by tracing story points back to hours of individuals. That way you can plot the hours worked on the time clock against the number of user story processed and bill employees individually on it. You then swap the weakest link out of the team every month. Moreover, you can make beautiful graphs out of all the numerical data to predict the delivery of the project. Of course, that delivery will not be achieved because you skillfully demotivate the team. You can then nicely shift the blame for that to the team and the scrum method. Voila!

“Count individual scrum team members on story points”

2. Force the team to keep accurate records.

Scrum is focused on productivity. But productivity – making things that are useful – is not what we want. So we need to distract the team from its task. Fortunately, there are lots of lists to keep track of: lots of administration that you can use to reduce productivity considerably. Moreover, as a manager, you can report very well with all this data. And you can hold the team accountable for sloppiness in administration. That is much easier to judge than the quality of their work. Some concrete tips: expand the Definition of Done with enough paperwork. No story is finished without a functional design. And extensive documentation. Approved by at least three external experts. No story can be on the backlog without accurate estimation by the entire team, epic title, scope, unique number, component name, description, business value, rank, type, key stakeholder and workflow status. A Definition of Ready with many checkpoints also helps.

3. Engage in extensive discussion about the formulation of user stories

User stories are simply work packages, parts of the total work for the entire project. An experienced scrummer knows this and enters into a healthy discussion with the product owner about a smart and concrete solution.

Fortunately, not all scrum teams are so experienced. You can often lead them astray by spending as long as you can to formulate a user story. Demand nothing less than perfection! Question the “so that…” of each user story every time. With any luck, the entire sprint won’t even start because the backlog will never get finished.

4. Get the team working on as many user stories as possible at once

The less focus in the team, the less likely work will be finished before the demo. Moreover, you then get a burndown chart that just won’t go down. Nice and demotivating. Getting the focus out of the team is simple: at every stand-up, ask questions about user stories that no one has started yet. With any luck, someone will pick that up already. It is also useful to secretly make the first few user stories a little bigger every day. Always stretch the scope a little bit. Then they won’t get finished, and the team will automatically pick up subsequent user stories. Voila: gone focus!

5. Change the sprint backlog at least once per sprint

We learned in the previous tip: as much half-finished work as possible is the best way to tire out the team quickly. After all, the more often you change jobs in a day, the more tiring. Suppose you don’t succeed in taking the focus out of the team by having the team work on as many things as possible at the same time, you can still flip the entire sprint backlog in the middle of the sprint. Make up an excuse about new priorities from upper management, and you can clear the entire scrum board after a week and do a new sprint planning. You just leave the demo in place of course so there’s no time left to really create something great.

6. Create a team with more controlling functions than productive functions

As long as there are more people checking than productive you are guaranteed low productivity. No one gets up to speed that well. The best way to do this is through team composition. Look for enough architects, final editors, lawyers, consultants, experts, portfolio managers, etc. for your team. Instead, try to keep out designers or developers. The advantage of controlling functions is not only that they are not very productive in a team, they also have busy schedules. So your scrum room becomes a very restless dovecote, with people constantly moving in and out. No one on the team knows what they have to do with each other anymore.

Easy!

As you can see, it is not very complicated to subtly undercut scrum. You can also easily stay out of harm’s way yourself while doing it. With any luck, the organization will quickly heal from the scrum virus and you can get back to your old ways.