There are companies that somehow don't seem to get Scrum to work, and they attempt to get it undone — to uninstall it, so to speak. Sometimes the reason is that they feel they don't get the expected results, or that control is no longer there. In most cases it wasn't installed correctly, with all the necessary parts. Sometimes the old version of working wasn't completely deleted and is still in use by some people within the company. Maybe the manual wasn't fully read, or there was no commitment to get it to run properly. I even know of cases where companies try to use both Scrum and the old ways on the same project — and that simply does not work.
But once Scrum is installed, it's very hard to get rid of. To assist in this, I've devised ten simple steps to remove Scrum and return to the former version of working.
1. First of all, stop holding the retrospectives. These retrospectives are for feedback that you get directly from the teams, and you don't need this anymore. You don't need to suboptimize, so stop them altogether. You still can find out if everything went according to plan at the end of the project. And you have those wonderful Gantt charts that worked for more than a hundred years to keep track of things.
2. Reduce the daily stand-ups. Once a week will probably suffice, and to speed things up let one person, for example someone who manages the project and has an outside view, give an update. The best thing is to do this in a report so everybody can read it. Any feedback can be provided in meetings or by email. Once you have these, you don't need the stand-up any longer.
3. Once there are no more stand-ups, you can get the stickies off the wall and delete the sprint backlogs. There's no further need for an information radiator to indicate to everyone the current state of the project. Instead, you can use the reports for this too, and because the team no longer needs to update the sprint backlog, someone who isn't really working on the team can update the report. A project manager, for example. It's important that it contain only how much money is being spent, not what is getting done.
4. Sprints are no longer needed, so remove these. The best thing is to first make them longer, so no one will notice. By prolonging them to six weeks and then steadily moving to eight or more, people can get used to the longer production periods. It's a good idea to install deadlines to keep focus. Make sure the deadlines are fixed to keep pressure on the teams and make them work continuously on the product. Then it's no problem to bring in more projects.
5. To be sure that you can fill the entire period with work, it's best to be sure that everything is in place. Make an extensive plan. This plan has to contain everything, with as many details as possible. Functionality design with interaction design and technical details and any other solution you can think of. To be sure that you don't get a chaotic situation where everybody wants to have a say in things, make sure that the plans are made by a few key figures. Architects, interaction designers, and art directors, for example. Make sure management or the customer has the final say on things and signs off on them. After all, it would be wise to have an autograph on this plan in case anything goes wrong. It's no problem to keep changing the plan, as no one really reads it.
6. Now, we know that planning that works with complexity and poker cards is nonsense. People work eight hours a day, so it's easy to spread the work over 40-hour workweeks multiplied by the number of working people. You know how much time is needed before the set deadline. It's a simple case of adding things up. And if the work doesn't fit, it's wise to apply overtime. People have a lot of spare time and weekends; you can use this to save the project at the end. But the chance that this is needed is minimal if you've planned everything in detail. And when some things do go wrong, you can have a risk plan that you can activate at a moment's notice. To get the risk plan to work you have to look into the future, but hey, we can predict the weather, so why not a simple project?
7. It's now time to remove the ScrumMaster and the product owners. You no longer need the product backlog or sprints and stuff, so just fire them. You will need to replace them sometimes, but I'm sure there are a lot of redundant people within the company who have great ideas about what's needed. It's even a good idea to set up small project groups that think up things that are needed. Don't make these groups too big. Just create more than one and provide them with their own deadlines and budgets. To keep them involved, make sure they have some sort of key performance indicator that you can make them stick to. It's no problem that there is more than one group with individual deadlines, since it's possible to change the project at any time or add extras to it.
8. You don't need multifunctional teams anymore; just put people when and where you need them. After all, you want to have several projects running at the same time. The project groups will make sure that you have enough work to keep people occupied. And it's easier to simply switch people between projects. That way you can put focus on the work that needs the most attention or has problems. It keeps things flexible.
9. Test everything at the end of the project. This is best because then you have everything in place and have a bigger overview. Because your project manager is the key figure in everything, you can rely on him or her to have elaborate project documentation. If anything isn't up to standard, you can fix it after the software has been released. If you have a custumer who doesn't like the product, you can sell some extra things, like special services or the like. You can make a lot of money out of those service-level agreements. Most customers will ultimately leave, but at least you'll have their money.
10. The hardest part is to uninstall Agile thinking itself. As it was part of everything you did when installing Scrum, you have to get it out. Keep in mind that Agile is like a virus: It spreads when you get people together. To reduce this risk, disseminate information by holding a lot of meetings where not everyone is present. Use email and a lot of documentation to filter out any personal contact. And make sure that only a few people are in control of distributing that information. If, in the end, some people are still a bit Agile, just tell them how they should do things day by day.
So there you have it: ten simple steps to deinstall Scrum and Agile. I can assure you that this will bring you more success. Your projects will be under control again, built the way you want them. You can have as many safeguards as you like, and that can help you sleep more soundly. In order to make sure it works, you need a lot of money — but that's never been a problem. So all that's left is a lot of micromanagement and control. Fear is an option, but only use it when people want to go back to Agile. The chance that this will happen is small, because I'm sure that nobody wants to think for him- or herself.
If you like my uninstallation methods, I have more. But they're are just small add-ons, like failure, de-motivation, low quality, and lack of commitment. I can provide them, but I'm sure most people within your company will have these available for you after you've deleted Agile. And the good news is that they come at no extra charge.