Table of Contents
While training colleagues and customers as Scrum Masters, I realize that people are often confused under which conditions Scrum should be applied. Applying Scrum everywhere – even when it is not required – simply results in waste and loss of efficiency.
Here are two important factors that you should consider before deciding to apply (or not) Scrum:
1- Nature of the work.
Scrum is – by definition – an Agile framework which helps to generate value through adaptive solutions for complex problems.
This means that if your work is not complex in nature and/or cannot be broken down and planned in short iterations, Scrum is probably not for you (think PDCA cycle, Deming/Shewhart).
If your work consists of a lot of unplanned events and support requests, Scrum is also not the best fit – there is planning and a certainty element in Scrum!
Referencing here a Stacey Matrix chart from the PMI Agile Practice Guide. Agile falls under the adaptive approaches category. Scrum thrives on complex work
2- Organizational set up
The organizational set up of your team is paramount for you to get the most benefits out of Scrum. In a nutshell, you need fully allocated people to your team (or close to it) and it should be cross functional, meaning a team being able to produce increment of value without depending on others (or not much, given the size of our organization).
If your team members are not allocated full time or close to it, you will fail to reap most of Scrum benefits – people will complain (rightly) about being part of too many meetings and having no time to do work. Motivation will fall and shortcuts will start to be taken, affecting the product quality and deliverables.
If your team is not cross functional, you will be dependent on others to complete your work which will result in delays and frustrations. Dependencies are what kills Scrum – try to avoid them at all cost.
Not having the proper organizational set up will impact tremendously your Scrum team efficiency. It is – sometimes- better not to start with Scrum when those conditions are actually not met.
What to do if above Scrum conditions are not met?
See below for a few tips:
- In case your work is simple in nature, a list of tasks or a project schedule in the form of Gantt chart works very well – no need to Scrum.
- In case your work is erratic in nature with constant change of priorities e.g. support team, consider using a Kanban board to create visibility, handle constant reprioritization and set up ad-hoc retrospectives to improve.
- In case your team is not cross functional, check how to bring the necessary skills in your team (hiring/recruiting new members) or develop them (training team members).
- In case your team is not fully allocated, this is a matter of prioritization of individuals in the team and respective managers. Talk to both to check what is possible and weigh in your options. It is sometimes – if not always – better to have less people in the team but fully allocated rather than many people partially allocated.
- Continuing on point 4, you can also go ahead with Scrum with a partially allocated team. It will in general lead to a make or break situation. Either team members will realize over time that more allocation is required and they will increase their allocation or they will withdraw from the team. Worst case, the project/product approach will have to change.
- You can also decide to use some elements of Scrum such as daily Scrum, retrospectives to spice up and improve your teamwork. This is perfectly fine and in line with Agile principles. This is just not Scrum 🙂
Conclusion – when to NOT use Scrum
Those were just a few thoughts and tips, I hope that they can help you.
There are of course other important considerations to take into account before adopting Scrum. Some key ones coming to mind are team willingness to adopt Scrum and management buy in and support. Those will probably warrant for another post 😉
Meanwhile, should you you have any question and/or comment, do not hesitate to reach out!
