Scrum from a management point of view

I recently had a discussion with a friend of mine regarding the usefulness of Scrum. I’ve taken some helpful hints from the discussion on how a developer can feel used and misused by Scrum. Let’s talk about a few of them, but let’s start with some naked rules of Scrum first:

  1. The daily work of a developer is bound to the user stories of a sprint.
  2. Due to the nature of time only a limited amount of this resource can be spent during a sprint.
  3. The customer is expecting a result according to his wishes in the shortest time possible.

Theory: Scrum stops creativity

I can agree with this only partially. The truth is: The customer is setting the requirements and, most important, he pays for reaching them. That means: he is setting the direction where the project is heading, no matter how strange some requirements might appear to the developer. But of course that does not mean everyone should blindly follow a wrong direction. So what happens if a developer has a really good idea on how to improve the product? It’s really simple: Take the input from your developers and take it to the customer. If the idea is really that good, he will agree on implementing it. From my point of view the creativity is not harmed by Scrum in any way. Everyone can still suggest ideas, but you should not go ahead an implement them without permission of the customer. Next to that: It’s hard to plan when a developer might have that one brilliant idea.

Theory: There is no time to do things right

I can not agree with this at all. First of all it is really to find a proper definition of right. What is the right way to implement a search functionality? Performing a LIKE-search on a database column? Or use weighted search on a lucene index using a solr cluster? Both attempts have obvious advantages and disadvantages. A search using an index is likely to be more natural to the end user, but it might not even make a difference. And searching a small table with a couple of lines can perform really well, but what about millions of lines?

To me this boils down to one question: How good are my user stories? When a story is well defined (specifying the use cases, the amount of data and the likelihood of usage) it is easy to find the right solution. If it’s not a developer might go for a technically interesting but expensive solution. If a story is well defined, the estimated development time will be large enough give the developer enough room to implement a solution properly. If it’s not be prepared for bad code.

Theory: Implementations must be shortsighted

I partially agree with this. One of Scrums basic ideas is: „only implement what you really need“. In most cases a developer will have to focus on a single feature/problem without having the complete spectrum of future requirements in mind. In most cases this results in solutions very specific to the given problem.

Theory: No time to undo mistakes of the past

I largely agree with this. When a developer is working on a new feature it commonly happens that he will go through a lot of existing code. And every code base has established concepts of doing things and these are accepted by the developers. But from time to time some concepts have proven to be bad and need to be reworked. But the customer will not be very happy when, after months and years of work, being presented a product that looks exactly the same as before. It’s almost impossible to find a customer paying for this! So if your developers are completely used by the Scrum there is no time to fix the so called technical debt. In my experience it is good to stop the Scrum process from time to time to allow the developers to perform larger cleanups. Alternatively it also works to have a sprint without enough user stories to consume the whole time available.


I agree that a developer might feel controlled by the customer/product owner/scrum master and being less able to establish his own ideas. But in my experience that often boils down to improper usage of Scrum. Having good user stories and a bidirectional communication with all involved parties not only leads to better products, but most important to happier developers. When everyone involved in the Scrum process is fulfilling the required role, it can be an enjoyable development experience for all sides.

Copyright ©, 2002-2020.