«

»

Nov 19

How to uninstall scrum

There are companies that somehow don’t seem to get scrum to work and attempt to get it undone, to uninstall it so to say. Sometimes the reason is that they feel they don’t get the expected results or they have the feeling that control is no longer there. In most cases it is not installed correctly with all the necessary parts. And sometimes because the old version of working was not completely deleted and was still used by some people within the company. Maybe the manual wasn’t fully read or there was no commitment to get it to work. I know even of cases where companies try to use both on the same project and that simply does not work. But once Scrum is installed it is very hard to get rid of. To assist in this I devices ten simple steps to remove Scrum and return back to the former working version.

  1. First of all stop holding on to 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 sub optimize so stop them all together. You still can find out if everything wend according to plan at the end of the project. And you have those wonderful Gannt chards that worked for more then a hundred years to keep track.
  2. Reduce the daily stand-ups. You can probably suffice with once a week 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 to do 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 longer need the standup all together.
  3. Once there are no stand-ups anymore you can get the stickies of the wall end delete the sprint backlogs. As there is no need anymore for an information radiator to indicate to everyone the current state of the project. In stead you can use the reports for this and because the team no longer needs to update the sprint backlog, someone who is not really working in the team can update the report. A project manager for example. It is important that it contains only how much money is spent not what is 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 to six weeks and then steadily move to eight or more, people can get used to the even longer production periods. It is a good idea to install deadlines to keep focus. Make sure the deadlines are fixed to keep pressure on the teams and to make them work continuously on the product. By then it is no problem to bring in more projects.
  5. To be sure that you can fill the entire period with work it is best to be sure that everything is in place. Make an extensive plan. This plan has to contain everything. Design as detailed 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 want to have a say in things. Make sure that the plans are made by a few key figures. Architects, interaction designers and art directors. Make sure that management or the customer has the final say in things and signs it. After all, it would be wise to have an autograph on this plan to be safe if anything goes wrong. It is no problem to keep changing the plan as no one really reads it.
  6. Now we know that a planning that works with complexity and poker cards is nonsense. People work eight hours a day so it is very easy to spread the work in forty-hour workweeks multiplied by the number of working people. You know how much time is needed towards the set deadline. So it is a simple case of adding things up. And if the work does not fit, it is very wise to apply overtime. People have a lot of spare time and weekends; in the end of the project you can use this to save the project. But the chance that this is needed is minimal if you planned everything in detail. And when some things do go wrong, you can have a risk plan that you can activate at a moments 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 is now time to remove the scrum master and the product owners. Because you no longer need the product backlog or have sprints and stuff. Just fire them. You will need to replace them a bit but I’m sure there are a lot of redundant people within the company who have great ideas about what is needed. It’s even a good idea to setup small project groups that think up stuff that is needed. Don’t make these groups to big. It is best to make more then one and provide them with their own deadlines and budgets. To keep them involved make sure they have some sort of KPI that you can stick them to. It is no problem that there is more then one group with personal deadlines as it is possible to change the project anytime or to bring in extra stuff.
  8. You don’t need multifunctional teams anymore. Just plan 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 is 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 and has the overview. You can rely on him or her to have elaborate project documentation. If anything is not up to standard you can always fix after the software has been released. If you have a costumer that does not like that, you can sell some extra stuff like service or so. You can make a lot of money out of those SLA’s. Most customers will leave but at least you have their money.
  10. Now the hardest part to uninstall is agile. As it was in everything that you did when installing Scrum, you have to get it out. Because it is in everything you need a lot of extra roles like managers and so. Keep in mind that agile is like a virus. It spreads when you get people together. To reduce this risk, spread 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 information. And 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 very simple steps to delete Scrum and Agile. I can assure you that this will bring you more success. Your projects have control again and are build they way you want it. You can have as many safeguards in it if 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. Right. So all that is left is a lot of micro management and control. Fear is an option but only use it when people want to go back to agile. The chance that this happens is very small because I’m sure that nobody wants to think for him- or herself.

If you like my uninstall methods I have more. But these are just small add-ons like failure, de-motivation, low-quality and lack of commitment. I can provide but I’m sure most people within your company will have these available for you after you have deleted Agile. And the good news is that it comes at no extra charge.

Permanent link to this article: http://agilethings.nl/how-to-uninstall-scrum/

  • Guest

    This is a really good uninstall manual! I especially appreciate that it plans every stap ahead. However, at step 7, I think that it would be better to tell all the groups to be ready to start when (and if) the running project ends. And set up a good format to change the scope of the current project, with a good insight on the delivery time and extra costs. That way they all have the feeling that they can contribute value – as long as it is thought through welll enough – without the risk of destroying the plan you are following.

    • You do realize that this article is meant to be a little sarcastic as it is very unwise to uninstall scrum or any other agile model.

      • Milo Faris

        lol what a dumbass

  • Pingback: Agile does damage - Agile Things()