The problem with Scrum is that it usually works. In tech, we hate that. What we like is to give talks, prepare slide decks, and, most importantly, to invent things ourselves.

Just like creating your own front-end framework is a rite of passage for web developers, creating your own version of Scrum is a rite of passage for engineering managers. Both cases usually result in catastrophic failure, followed by tears and despair.

These endeavors lead their creators to realize how difficult it is to create a functional framework or methodology, especially when you don’t understand the dynamics which make each of them work. Only once enough tears have been shed, and they’ve hit their heads against a wall enough times, these people turn back to where they should’ve never left: React or Vue and Scrum or Kanban (my favorite).

In this blog post, I’ll teach you how to reinvent Scrum so that you can give it your own name and present it in Agile conferences — just don’t tell people it’s not working.

Besides boosting brand awareness, this guide will also help you achieve catastrophic failure more quickly so that you have an excuse to go back and adopt a process that actually works.

At that point, you can then deliver another talk, explaining why you don’t use your own methodology anymore.

This post’s structure is simple. First, I’ll show you how to distort all the good parts of Scrum to the point they no longer work. Then, I’ll tell you which pointless practices to keep and how to make them even worse.


Good principles to obliterate

Before we get to maximizing its awful parts, let’s start by putting a spoke in Scrum’s wheels and eradicating all the positive aspects it adopted from Kanban.


Two-week sprints

There are two ways of ruining sprints.

The first is to make a year-long plan and break it down into sprints. That way, you’ll be effectively doing waterfall, which allows you to completely ignore customer feedback and blindly follow whatever imaginative roadmap you and other executives have created.

Instead of adjusting your goals sprint-by-sprint depending on the market’s needs, this “sprintified-waterfall” flavor of Scrum will help you build something you want, regardless of whether it’s useful.

This methodology makes you fast because you won’t stop to listen to the market. That way, you can hit the wall of failure at full speed, ensuring maximal destruction.

The second way to wreck sprints is to make them extremely short or unnecessarily long.

With one-week sprints, you’ll be able to ensure your developers will spend half of their time in useless meetings in which they fiercely debate whether a story is worth two or three story points. Furthermore, your team will have more opportunities to play planning poker, an exciting and scientific game all engineers love.

In addition to more finger-in-the-air estimations, your team will also have more sprint planning meetings in which they can add more work to the pipeline without having finished anything from the previous sprint, making everything slower and unpredictable.

Finally, week-long sprints are also great to prevent teams from improving the way they work because they’ll have no time to actually work, given they’ve been too busy following the process — amen.

That’s not to mention all these meetings will take up so much time that teams will not have any time to listen to customers, thus preventing them from hurting their egos by discovering no one is using any of the few features they’ve been shipping.

Conversely, three-month-long sprints can be almost as damaging. Although they produce less waste, they require you to make more assumptions on behalf of your users, thus guaranteeing you’ll be heading in the wrong direction for longer.


Daily Standups

Ruining daily standups requires a bit more work. For that, you must create a culture of fear in which it’s more important to show others you’ve been productive than to help the team achieve its goals.

That way, people will treat standups as an opportunity to tell others about how busy they’ve been, regardless of whether that information is helpful.

You’ll know you have successfully ruined your standups when they’re taking thirty or more minutes, and your whole team hates them to the point they won’t do it if you’re not present.

After reaching that point, all the benefits of standups will be void because no one will pay attention to each other. Therefore, no blockers will arise, and there will be no time to correct course in case a feature turns out to be problematic.

I know ruining standups may require effort, but I promise it will be worth it. Wasting only 30-minutes a day might not seem like a lot, but they add up quickly and help make your team grumpier.


Retrospectives

Retrospectives are a cornerstone of successful teams. Consequently, if you want to achieve cataclysmic failure, you must completely obliterate this helpful practice.

One great way to start is to show your team a burndown chart and focus on useless metrics like velocity. Doing that will ensure no one will come up with any meaningful insight because velocity has no relationship to other actionable metrics like throughput, arrival rate, or the amount of work in progress.

By shutting down any opportunities to generate meaningful insight, everyone will be forced to come up with subjective recommendations, like “working harder” or “having a greater sense of urgency.” These recommendations are splendid because they have absolutely no impact on your engineering system, thus ensuring it will remain painfully unproductive.

It’s also critical for the person with the highest hierarchical role to start the retrospective. That way, they give hints to others as to what they want to hear, which is more important than actually figuring out what the problems are.

TIP: This technique will be more impactful if you can successfully create an environment of psychological danger. If you do that, people will constantly be in fear and will feel discouraged from sharing their ideas unless they’re sure their managers will agree with them.

Finally, you must be adamant about committing to an unbelievable amount of action points in every single retrospective. That way, you can ensure that nothing will change because you’ll simultaneously divide time, effort, and attention into too many tasks.


Backlog Management

Backlogs are the best way to avoid difficult conversations. Whenever someone wants developers to implement a new feature, you can tell them you’re going to “add it to the backlog” and forget about it. Then, when they ask you about that feature again, you can tell them it’s still in the backlog and that you just haven’t had the time to get to it.

If you repeat this process enough times, they’ll forget about that feature, and you’ll never have to discuss whether it would be valuable. Consequently, you’ll be free to do whatever you want to do. Remember: it’s your product development dictatorship.

This strategy also guarantees your backlog will be filled with enough garbage to show the higher-ups you’ve been busy “managing the product,” which is precisely what your job title implies you should be doing.

Besides helping prove you’re busy and avoiding difficult conversations, a colossal backlog also prevents you from doing any actual prioritization and hard work. Instead, you can ask developers to keep “refining” the backlog’s tasks they’ll never get to so that you can prevent them from writing any code, bringing everything to a halt.


Pointless practices to keep and how to make them even worse

Now let’s get on with the greatest parts of Scrum: the ones which produce the most frustration and waste of time.


Estimations

I love estimations. They’re an excellent way of fooling everyone into thinking they know how long things will take. Once you have convinced your team to estimate tasks, you can pressure people to work longer hours to prove they’re not bad at estimations.

The best part about estimations is that no one will even be able to argue with you because you’ll be simply “holding them accountable” to their imaginary numbers.

Even if you fail at pressuring developers to give low estimations, any buffers they add to their estimates can also benefit you. That’s because you’ll be able to use these inflated estimations to prove to the higher-ups that you’ve been working on difficult things.

It’s also crucial that you pick an arbitrary scale for your estimations. Fibonacci is good, but if you can develop a more esoteric system, that’s even better. I’m yet to try using tarot cards to replace planning poker so that I can infuse meetings with a more mystical aura and spend more time debating useless aspects of task estimation.

Regardless of which arbitrary scale you pick, make sure it doesn’t have any direct relationship with time. That way, no one will ever be able to complain that you’ve been taking too long to deliver something, as you inevitably will be given how much time you’ve spent in estimation meetings.

Finally, do not, by any means, calculate the correlation between your story points and the time tasks take to be done. If you do that, everyone will see that there’s absolutely no correlation between estimations and actual time. If you do that, your tactic will fall to the ground.


Refinement Sessions

Refine, refine, refine. Don’t ever allow anyone to write a single line of code without forcing them to write a detailed specification document, send it over via email for others to comment, and ensure that every single comment gets responded to. Remember: the best way to ensure nothing gets done is to design by committee.

Doing a lot of refinement is a great way to waste time because it will cause people to think about how to handle every single edge case that comes to mind, including the ones that will probably never happen and don’t impact the overall goal.

If that sounds too productive, don’t worry. Even then, people will not think about the edge cases that truly matter: the ones that will come up as developers write code. That way, you can maximize the time developers waste, thus increasing costs.

Another reason refinement helps people build dysfunctional products is that they incentivize your team to make as many assumptions on behalf of users as possible. That way, you’ll have more things to change and undo once you receive feedback.

In any case, I wouldn’t recommend you spend time acting on that feedback. That would make your product actually successful.


Velocity and burndown charts

I won’t spend too much time on this item because I’ve already discussed it in the “retrospectives” section above.

In any case, here are a few extra tips for weaponizing useless metrics like velocity:

  1. Make sure you complain about it frequently — that way, you’ll guarantee maximum pressure.
  2. Show burndown charts to the budget people, especially if they remain flat or show bad results — these charts are a great way to justify any decisions you already want to make. That’s because burndown charts are not anchored to any other metrics.
  3. Don’t ever perform qualitative assessments — if you talk to your team, you may realize you’re doing everything wrong, preventing you from being creative and fulfilled in your product dictatorship role.


Roles and information silos

Make sure everyone knows their role’s name, no matter how fuzzy the role definition is. Whenever an opportunity appears, use the words “scrum master” and “product owner” to refer to people.

Sharing too much context with developers may cause them to make good product decisions without having to talk to a thousand other people.

The more you segregate responsibilities, the better.

Information silos help make developers’ lives worse by increasing the time it takes for them to make decisions and making them feel removed from the impact of their work. Therefore, they’ll take longer to ship software, care less about code quality, produce more bugs, and burn out more quickly.

Furthermore, it will eradicate any bit of ownership that’s left in the team. Consequently, it will be easier for you to push your product development agenda, regardless of whether it’s good for users.

In case you want to make information silos even more wasteful, you may also want to create new roles and ensure that no one from any other team talks to developers. If you do that, you can ensure that developers can’t understand the problem and that everyone else can’t understand the solutions.


Wanna talk?

I currently offer mentorship and consulting packages for individuals and startups wishing to ship more software in less time and with less stress. If you’re interested in improving your processes and pipelines, book a free introduction call here. I’d love to help you solve any problems you might be facing or answer any questions you might have.

Alternatively, you can send me a tweet or DM @thewizardlucas or an email at lucas@lucasfcosta.com.