This is why we also use agile approaches in many customer projects, of which Scrum is one of the most popular and widely used methods.
However, reality shows that the overwhelming majority of projects are carried out by a deviate from a consistently agile approach.
Reason enough for us to Textbook definition of Scrum under the microscope and compare it with our project experience.
Product backlog entries may be rudimentary
Scrum describes the possibility of prioritizing lower Entries in the product backlog also in a lower level of detail to describe. This means that a complete specification of the future end product does not have to exist at the start of the project. The details are therefore only specified as implementation approaches.
In practice, there is a risk that certain approaches and ideas may not be fully thought through. As a result, the Total costs in the further course of the project increase massively. On the one hand, because the scope, i.e. the effort required to implement the requirements, increases and the original estimate to the total expenditure on a other assumption made became. On the other hand, because Functionalities already implemented have to be converted again. So instead of taking the shortest route to your destination, you have to make numerous extra turns. This can lead to further, unplanned additional expenses lead.
The Product Owner is a single person
According to Scrum, exactly one person is responsible for the Clear specification and prioritization of backlog entries responsible. This is intended to prevent an entire committee from working on the backlog and, if necessary, conflicting requirements from being introduced.
However, customers often underestimate the The effort involved in a Product Owner role. As a result, you may end up with requirements that are barely understood or misunderstood by the developers. Or they may be of such poor quality that they have to be rejected by the development team. The latter in particular harbors a certain potential for conflict, as the Product Owner usually also our customer at the same time is.
The use of user stories and story points is not mandatory
When you hear Scrum, you automatically think of user stories and story points. In practice, these two techniques have proven to be a De facto standard in the Scrum environment established. However, Scrum does not prescribe which type of Specification or which estimation method should be used.
User stories and the associated Acceptance criteria are an excellent way of specifying when you need a Easy to use software product (e.g. with a user interface). However, there are also projects in which predominantly implement algorithms must. Here you may be dependent on extensive documentsthat describe exactly what needs to be implemented and how. In this environment, user stories as the only form of specification reach their limits.
Some developers also find it difficult - especially with new development projects and at the start of development - to Complexity[2] of requirementsbecause there is simply no suitable reference. In addition, in many projects you end up back at the end of the day with a Conversion to person daysas either a forecast or an accounting based on the estimated story points must be created.
It is not explicitly excluded that the sprint backlog may be changed in the sprint
The original Scrum Guide[3] defined that during the sprint
- no changes may be made that jeopardize the sprint target,
- the quality standard must not be diminished, and
- the scope of requirements can be clarified and renegotiated between the product owner and the development team if new findings emerge.
Depending on the customer and project phase, sometimes more, sometimes less adjustments to the sprint scope are also necessary in our customer projects. The biggest challenge for us is Requirements that come from the customer really once to consistently block. The next go-live is often on the agenda or the management has certain expectations of the sprint result. There a a healthy compromise between our own quality standards and the customer's requirements can be quite a challenge.
Lots of appointments: Dailies, Sprint Review, Sprint Planning, Sprint Retro, Backlog Refinement
The Scrum Bible recommends a maximum sprint length of 4 weeks and provides the following dates for this period[4] :
- 15 minutes Daily
- 8 hours Sprint Planning
- 4 hours Sprint Review
- 3 hours retro
- 10 percent of developer capacity for backlog refinement
With a simple milkmaid calculation (0.25h x 20 working days + 8h + 4h + 3h + 20 working days*8*10%) you get up to 36 hours that a developer spends per month on the various Scrum meetings can spend. With 20 working days, this corresponds to 23 percent of his available working time.
Experience has shown that the more complex the project environment and the larger the development team, the closer you get to the times mentioned above, i.e. the longer the meetings take.
Conclusion of our Scrum Reality Check
The textbook definition of Scrum describes an ideal situation. In reality, however, it is often difficult to achieve this 1:1 mapping of the target image in the respective customer project[5]. Our experience is that it is often necessary to then turn to the Adapt to the conditions in the project or at the customer.
The agile world has many advantages and is often the much better choice for the success of a project. Nevertheless, switching from traditional project management to an agile approach, for example, does not eliminate all the problems that can arise on the way from an idea to a product. Because even then, the following still applies: "It's a people's business".
Glossary:
[2] Story points are generally used to evaluate the complexity of a requirement
[4] The times indicate a maximum limit in each case
[5] At this point, it would be interesting to see a study that examines how many projects really (can) implement Scrum according to the textbook at 100%. Unfortunately, I have not found a suitable reference in the context of this blog post
Sources:
[1] Study on the spread and benefits of agile methods
[3] http://www.scrumguides.org/index.html
