“There is nothing more difficult and dangerous, or more doubtful of success, than an attempt to introduce a new order of things.”
Disadvantages of using Scrum
How many technologies have quickly popped up and then vanished even quicker? They all promised to be revolutionary, the new silver bullet that will end every problem in the software industry. When we get as much hype as has been lavished on Scrum and Agile, our first reaction is to raise a critical brow.
If you are adopting Scrum in your project or company, it is best for you to be informed beforehand about its drawbacks:
The team might be tempted to follow the shortest route
When we have things to deliver every two weeks, and in the latest deliveries the projected functionality wasn’t ready and the speed of the team does not indicate that we will finish the next one on time, we have a problem. We can succumb to the temptation of finishing the pending tasks in any way we can and leave a “technical debt” behind us. Everything has the appearance of going well, we create more features, we start new things, and the client is happy because deadlines are being met.
But every time you leave a small hole of a deficit behind you, I can guarantee that you will stumble on it again and make it bigger. If new things keep caving in this way, the “debt” will become a pit. Sooner or later you’ll have to stop everything and fill in the pit—pay back that loan and with extra interest because of that late payment. The project doesn’t finish when we were so close to the end, and the burndown chart appears to have a horizontal asymptote at 0 (sorry, Calculus I).
Do you need to have delivery deadlines way in advance?
This is one of the main criticisms that Scrum normally receives. In a way, it is logical that Scrum cannot give you those deadlines. At the beginning of the project, you cannot predict when you’re going to finish, if you’re making it easy to change the thing being built as time goes by. But, do you prefer a product that you know “for certain” will be finished in 12 months, but is built over the ideas and opinions you had a year earlier? Maybe you prefer a product that could be finished in a similar period of time, but that you have been able to steer towards your real needs, and you’ve been able to use and test before the final delivery deadline.
We cannot sprint for our whole lives. We deliver something and the next deadline is just two weeks away. Then another one, and another one. If we have to run like this for many miles, we will sprint really hard for the first deadline, but we will walk for the last one —and that, with luck. It is something we should bear in mind during planning, from the start.
Is your team able to self-organize?
One of Scrum’s principles is that the team members must make their own decisions and self-organize. Also, one of the requirements is to avoid having teams that focus just on specific tasks, like analysis, testing, design, documentation, development etc., but rather to make sure that every member of the same team can carry out all of these tasks without depending on external teams or members. Can we always have a team like this? What happens if we don’t have one, or if we lack a key component?
You can find texts like this and many other about how to manage agile projects in my book Agile 101: Practical Project Management (available on Amazon).