Since 2001 when the Manifesto for agile software development was introduced, Agile has been gaining an ever-growing group of enthusiasts. Especially in the IT industry, which is focused on the fast delivery of quality solutions. There are many guides to the Agile world and lists of good practices, such as the Scrum Guide translated into dozens of languages. Today, in the text written with a grain of salt, we suggest how certainly NOT to be Agile if your team works in Scrum.
First, fire a Scrum Master
Scrum Master significantly contributes to the fact that the Scrum principles are known and respected. He talks to everyone and is often held in high regard. His personal qualities make him talkative and sympathetic. So, if you have a different vision of Scrum, first, consider whether you need him. Think about it: he doesn’t program, he asks a lot of questions (Does everyone know what to do? What are our difficulties? Are there any risks for Sprint goal?) and still refers to the Scrum Guide. If you want to achieve a state of Scrumfall and gain more power, start by firing Scrum Master.
Do not hold meetings
After removing the Scrum Master, this point should be easy to implement. First, cancel Sprint Planning and resign from the Daily, then no one will know what to do. In this way, the Retrospective and Sprint Reviews will naturally become redundant, and your developers will have more time for coding. Instead, schedule meetings at any time, when you are most comfortable – you will be able to keep track of the tasks at the right time, and not at the agreed hours of the week.
Add new tasks during the Sprint
Flexibility is at the heart of Agile, isn’t it? From now on, the team will be flexible then, and will learn how to respond to change instead of following the plan. That’s what Extreme Programming (popular Agile project management framework) emphasizes, so that’s Agile approach, right? Are there too many tasks to be completed in Sprint? No worries! You can always put a task back in the Backlog and deliver it as part of the next Sprint. There is no planning, so maybe no one will notice, and the client will be pleased that some important functionality has been prioritized.
Control the team all the time
Self-management doesn’t go well since Scrum Master is gone, so you better control what people do. Write to developers on Teams every few hours to make sure they are working on a solution. If you work in an office, it is even better as you can sit behind the back of a programmer and look at the code thoughtfully. Even if you don’t fully understand its complexity, it doesn’t matter – let the programmer feel that someone is watching. You will gain respect, and the task will certainly be completed on time. And remember, don’t trust the task management software! Have the team report their results in Excel. Agile does not exclude this: it puts working software ‘over’ documentation, and not ‘instead’ of documentation.
Divide the Scrum Team into micro-groups
By dividing the team into smaller groups, it will be easier for you to maintain full control. For example, you can create a team of testers and developers, or a maintenance team and development team. It is up to you. All people should work with one Backlog and one Sprint. Choose a manager in each team who will report directly to you (in Excel).
If Scrumfall is your goal: summary
Scrum is eagerly used in IT projects due to its simplicity, transparent rules and fast effects. Although it is thoroughly described and willingly used around the world (in 2022 it is the most widely used agile framework for software development according to the State of Agile Report), its ideas are often freely interpreted. The above anti-guide should allow some people to achieve so-called Scrumfall if that is their goal. However, if you are interested only in good practices and real Scrum, remember to read our guide to Agile Software Development Methods.
