One of the clichés about Scrum is that it is “easy to understand but difficult to master”.
The first part of that is obvious with the Scrum Guide is only eleven pages (if you don’t count the title page, purpose and table of contents). There are three roles, three outputs and four events (five if you include sprints as an event but I prefer not to as the whole idea of events within events makes me nauseous).
The second part becomes apparent once you try to implement Scrum within an existing system. Only in very rare cases is it possible to introduce Scrum without radically affecting the team’s way of working. This, by itself, is not a bad thing as improving delivery outcomes involves a certain amount of change.
However, the immutable design of Scrum is where challenges occur. On the surface, introducing a new set of events or outputs wouldn’t appear to be too drastic, but when it comes to replacing existing roles, outputs and events with the Scrum ones, and implementing them as they are intended to be used is where challenges emerge.
Given my personal observations with Scrum adoption issues, I thought it would be useful to poll a larger audience on which aspect of the framework generated the most challenges. A total of 35 members of the LinkedIn PMI Project, Program and Portfolio Management community answered the poll with the following breakdown of votes:
- The events: 31%
- The roles: 31%
- The outputs/artifacts: 17%
- The 1-4 week time box: 20%
This is consistent with what I have observed.
While there might be some quality issues with sprint and product backlogs, and immature teams might not always produce an increment, it usually does not take too long for most teams to get comfortable working with these artifacts. Similarly, while there might be a need to increase sprint duration when dealing with the “real world” constraints of non-software projects, over time, teams do get better at slicing work items such that “something” of value can be produced within a short amount of time.
The biggest challenges I’ve seen are with the proper adoption of the Scrum events and roles.
Whether it is Daily Scrums which turn into status meetings, psychologically un-safe Sprint Retrospectives, Sprint Reviews where no external stakeholder attends or Sprint Planning which takes days to complete, the purpose behind and prerequisites for successful events get lost in implementation.
While we all want C.R.A.C.K. Product Owners, and cross-functional “whole” teams, we end up with PO’s who have no decision making authority or no time, and unpredictable team member allocation from one sprint to the next.
So when we consider the large number of conditions which are required to enable Scrum to be implemented as designed, the probability that they will all be met within a typical organization is quite low.
And this is why “Scrum-but” is the default, not the exception.
(If you liked this article, why not read my book Easy in Theory, Difficult in Practice which contains 100 other lessons on project leadership? It’s available on Amazon.com and on Amazon.ca as well as a number of other online book stores)
Easy in theory, difficult in practice 