DEV Community

Cover image for Introducing Scrum — Common mistakes when introducing Scrum
jakobhofmann for devlix Blog

Posted on

Introducing Scrum — Common mistakes when introducing Scrum

“And how do you work in software development?” an engineer asks his former fellow student over dinner. “We do Scrum now,” he answers proudly. Have you ever heard a conversation like this before? If so, you will certainly have listened carefully to how the conversation went on. But what does “We’re doing Scrum now” actually mean for a company, and why does the introduction of Scrum so often not lead to good results?

Processes and especially agile processes are certainly different in many companies — and they have to be because companies have very different characteristics, both in their goal and in their (historical) development. As a framework, Scrum therefore sets certain boundary conditions that can then be adapted to the respective company and embedded in existing processes.

But when is it no longer Scrum? What mistakes and experiences do many companies make in the process, especially when introducing Scrum in the company?

Introducing Scrum — common mistakes

Introducing Scrum without employees

Companies regularly review themselves and their procedures. This is because both the company representatives and the employees want to be the best company on the market in their segment. If other companies are more successful in the same segment, they quickly and intensively work out what the reasons are and how they can catch up. A transformation is needed! “The other company does Scrum — I want that too”. This realisation may be purposeful, but it brings significant changes with it. Unfortunately, employees are often not involved strongly enough in the process. This reveals a lack of role definition for them in the future and, above all, a failure to rethink and adapt existing internal processes. A break between the classical and agile worlds is regularly the result. This is exactly the point where an experienced Scrum Master (or better an Agile Coach) has to be involved (see article: Why a Scrum Master has to demand processes). Employees must be involved from the beginning when the company is undergoing such a major change.

The missing of a Scrum Master

Another consequential error in this context is that individual roles are saved during the introduction. “A Scrum Master costs money and can also be taken over simultaneously by the Product Owner” is then the common opinion. However, any person who has had first-hand experience with this scenario will agree that this does not work. Even if a product owner has the ability to take on the role of Scrum Master, this person has neither the time nor the awareness in the team to do so. To make it more clear: Scrum without a Scrum Master is simply not Scrum. What effects the missing of a Scrum Master can lead to the success of the company can be read in the blog post “Why a Scrum Master has to demand processes”.

Agile vs. waterfall

Many conventionally organised companies have difficulties introducing agile ways of working and adapting the processes. The approach in the organisation plays a major role in this. People who do not know or understand agile process models often fall back into familiar patterns even though they are coached by a Scrum Master. This often concerns the way decisions are made. In classic product management, schedules are typically given that depend on a target date. After the introduction of Scrum, an attempt is then made to take the developers’ estimates as the basis for a timetable for the project. Milestones, project plans and entire business decisions are made dependent on them. However, the estimates of the development team then represent at most a rough scope or only consider the complexity of the implementation. The time schedules based on this and the classic procedure of first making a detailed plan for the implementation often present management with great challenges. This is almost a classic mistake for approaching and planning in an agile approach, and it is quite easy to avoid it. How exactly this can be avoided is explained in detail in our blog article: “Estimates in everyday project life”.

Meetings are too expensive

Let’s face it: meetings can be very time-consuming, aimless, and above all expensive for companies. In Scrum, there is a fixed timetable for when which events take place. The time frame is therefore clear to the participants from the beginning and with a little practice and friendly reminders from a Scrum Master or timekeeper, it usually works out. But is all the meeting time really necessary? You can guess the answer: Yes! Because people can only work together successfully if the goal, the derived tasks and emerging problems are solved communicatively. So, should the thought arise at the next review that it is a waste of time, the follow-up thought must be: “How can I contribute so that the meeting is more successful for everyone”. Omitting Scrum events or staying away from them is not a solution to the issues that have arisen.

Consider Scrum as a fixed process

Scrum newcomers would certainly expect that Scrum already defines everything necessary for joint teamwork. Far from it! As already described in the introduction to this article, every company has established different procedures, partly for historical reasons. Scrum must be integrated into these processes and should serve as methodological support. In doing so, it is important to adapt the existing processes so that the attractive advantages of this approach can be used.

Apply Scrum hands-on only

“We introduced Scrum and we also defined the roles of Scrum Master and Product Owner ourselves. Previously, the two employees were part of the team, but they wanted to try something new.” Wonderful! Because the employees start their mission full of curiosity and joy. In the best cases, this will also be able to lead to success. However, there is also the danger that critical components of Scrum will not be applied completely or incorrectly. The reason for this is, for example, a lack of knowledge or experience with Scrum. Recommendation: Get external support through coaching or at least temporary parallel cooperation by experts who have already gained enough experience. If you need support in this area for your company, you are of course welcome to contact us.

Conclusion

The introduction of Scrum in a company is a big challenge that has to be considered individually for employees and the company processes. Only when the advantages of the agile way of working are in focus and have been understood it is possible to make all the necessary adaptations for the company. Such a cultural change is preferably facilitated by experienced experts. In this way, some challenges described can either be solved directly or may not even arise in the first place. Ultimately, this transformation can only succeed if the processes are successively adapted to the needs of the company by trial and error.


Jakob Hofmann is writing for the devlix Blog at https://www.devlix.de/blog
This article was published first here (german): https://www.devlix.de/scrum-einfuhren-haeufige-fehler-bei-der-einfuhrung-von-scrum/

devlix logo

devlix GmbH: quality, consulting, development

Feature image: Photo by ThisisEngineering RAEng on Unsplash

Top comments (0)