Scrum Risks and Challenges

The implementation of Scrum comes with changes. These changes are not only related to the software development department, but are effecting everybody in the company including the management. Job descriptions will change as well as the company cultur and structure.

Changes and Challenges when adopting Scrum (Ken Schwaber, The Enterprise and Scrum, 2007)

• Staff turnover will occur
• Conflict will occur
• Product management’s job will change and will be harder
• Engineering is accountable for quality
• Compensation policies need to change
• Job will change
• Management’s primary responsibility will shift from command to servant leadership
• Management turnover will occur

Scrum makes employees leave the company

At first sight that sounds very dramatic, but it actually is not. Scrum creates transparency and through that someone can not hide behind the supposedly mistakes of others. Through the observance of the “Time Box”, the tasks within the team and the transparency in respect of when something needs to be delivered, statements as “…I’ve been waiting for this or for that…, or … I had to do so many other things for the customer that I simply didn’t get to it…” loose their foundation. Yes, the introduction and observance of Scrum may lead to the fact that some employees and manager don’t feel comfortable in their company and leave because not everyone comes along with the changes of Scrum. But if we are honest it’s good that way because the reasons to avoid transparency affect a company with and also without Scrum – Scrum only makes it visible.

Scrum leads to conflicts

Yes, because Scrum emblazes problems of the company, the Teams and the Management. The simple rules of Scrum arrange that every reason that leads to difficulties at the Software and/or Product development in a company will be recognized. In some companies they unfortunately try not to expose the problems and therefore also not to remove them. That Scrum cannot function that way should be quite clear. This wrong utilization is the reason for statements as “Scrum is chaotic”, or “Scrum doesn’t work for us”.

The spectrum of possible conflicts that can appear through the introduction of Scrum is versatile. It starts with managers who like transparency in the development, but who don’t want to share their visions or who think that the rules are only for the others. The classical project leaders first need to apprehend which role they have to take at Scrum. Furthermore a company needs to claim the customers’ collaboration.

The number of examples who succeeded to use Scrum properly increases. Mostly there is professional advice needed, because the experience of experts shows solutions which would not be possible with only internal efforts. (At this point I’d like to express my gratitude and plaudit to all counselor colleagues, “Scrumtisch”, “Scrum Breakfasts” and other initiatives that make Scrum successful, that are amenable for questions and that offer support at anytime.)

Scrum changes the role perception

Just yesterday I’ve done a presentation for project leaders and developers, and I had to realize that the most important question of the audience is: How does Scrum fit to our established structures and roles?

As already said, Scrum defines three different roles, the Product Owner, the Scrum Master and the Team. The matching equivalent can be found in the classical projects – the meaning and the status of Scrum roles though is entirely different.

• Product Owner instead of Product Manager
• Scrum Master instead of Team- or Project leader
• The Team becomes the management role