The sprint.

25 Jul

This post is part of the series How SCRUM has became so much of an impediment.

Other posts in this series:

  1. How SCRUM has became so much of an impediment.
  2. The sprint. (Current)

A sprint represent a short period of time during which the scope of work is fixed and defined in advance. At the end of each sprint the team evaluate how they have perfomed. Generally a sprint lasts 2 or 3 weeks. This iterative approach should allow developers to focus quickly on the most important features. Business analyst doesn’t have to work on the whole application specification but only on the features that will be part of the next sprint. It allows to have an early start in the development process and also to improve the project by getting an early feedback.

Even if the iterative aspect is respected when SCRUM is implemented, the main goal of this approach became quickly a way to not plan or to not specify requests. Requests arrives during the sprint and priorities are changing every days. At this point, SCRUM experts will answer me that the product owner (PO) or the SCRUM master (SM) are not doing their job correctly. The PO should care more about the scope of the sprint and the SM should protect more the team of any violation in the process. The reality is quite far from it, mainly because these titles (PM &SM) doesn’t have enought hierarchical power : they still have to answer to theirs own bosses.

As it were not enough, engineering department is always considered as a cost center in opposition to the sale department which is “generating” incomes. And as in any company, the money speak for itself, so if sales department request something it has to be done to satisfy them, doesn’t matter the consequences. This lead to a chaotic situation where code quality and maintainability is dropping quickly while costs of developments are increasing proportionally. Added to this the rush to feature implementation lead to an undocumented application full of features not really adapted to customer needs. This last behaviour is reinforced by the fact that iterative development is interpreted as : try till it’s good. But developing a software without business analysis is never a good idea. Developers don’t know precisely customer needs, quality department has no reference documents to assess the product and request will became conflicting because no one will really understand what the application is doing and/or should do.

Leave a Reply

Your email address will not be published. Required fields are marked *