Is Scrum actually suitable for all kinds of projects?



  • The project that I am working on is purely non functional and deeply technical in nature, focused on improving the performance of the product as a whole. I have trouble seeing how Scrum is an appropriate methodology for this kind of project:

    • The business person, aka the PO, has no idea what we are talking about during our plannings since all the work is deeply technical and has no user facing consequences.
    • As a result of the previous, he cannot manage the backlog and we have to create all the user stories and manage them.
    • The concept of a user story also does not seem to make any sense. In our project there is no user. All the interactions happen between different system components.
    • Estimations are quite hard to do since almost all of the work implies doing stuff that we did not do before, so assigning points to stories seems almost a useless exercise.
    • Delivery times of working software are usually in terms of months not weeks for most of the stuff we have to do since they involve a lot of investigation before even starting on doing something. So usually sprints mean not that much for us.
    • There is no customer with whom to check on progress, to give feedback on our work and adjust accordingly since it is purely performance related and for that we do our performance tests to see the progress.

    So with all these points said, either I am missing some part of Scrum or is it true that it is not suited for this kind of project? And in general if true, what kind of projects are not suited for Scrum?



  • To your overall question, while Scrum can be applied in most projects, it is not necessarily the best approach for some projects. That said, it is well suited to complex problems that require discovery of the solution and adaptation to new information. Your project sounds like exactly the kind of project Scrum was designed to tackle. However, you raise some important points and I'll try to address them:

    1) A product owner needs to understand the domain they are working in at a level that they can intelligently identify and discuss the key problems that need to be solved in order to create value. For example, the PO for the large hadron collider better know their quantum physics. It is completely possible that you have the wrong PO for your work. It is worth noting, however, that they do not need to understand how to solve the problem to be effective - that's the team's job. In fact, sometimes it's better if they don't so they can get out of the team's way.

    2) While product backlog items can come from anyone, the PO must understand them enough to speak to their value and be able to prioritize. Are your backlog items expressions of problems to be solved or tasks in the solution. If the former, then again you may want to look at a different PO. If the latter, you might have the wrong items in your backlog.

    3) First, you don't need to use user stories. However, you do have some person or group of people who benefit from your work. Your backlog items should each provide value to them. If a product provides no value to anyone, you should cancel it. (I am, of course, being hyperbolic. I've never actually encountered a project that provided no value to anyone)

    4) Relative estimation is designed to be able to handle uncertainty or unknowns and helps in most projects. However, some projects have so much uncertainty as to make estimations useless. Luckily, Scrum does not require them. A recommendation I would make is that if you don't use estimations, use time boxes. A time box sets the amount of time to work on something before coming back to the group to see if it is worth continuing to pour time into or if something else is more important.

    5) This is a common challenge. The solution is simple, but takes practice to get good at. The solution is to either a) break down the problem into smaller problems or b) run an experiment to gain validated learning rather than long investigative learning processes. The first is used in cases where the investigation cycle is long due to simply trying to investigate a lot of things. The second is used when the investigation cycle is long due to many complicating factors needing to be accounted for in complex problems. Of course, it is way easier to type this paragraph than to do it, so don't feel bad if you run into some problems you don't know how to tackle in a sprint.

    6) Who wants higher performance, how much do they want and how will it impact them? That is who you have in your review. Your problem space sounds very narrow, so I would not be surprised to find out that your reviews are very straight-forward.



Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2