Scrum guide hasn’t changed much since it was introduced, which itself is a very honourable achievement especially in rapidly changing software industry. But there's also a bit of irony in it because as in any agile approaches we should always learn and adapt.
Many Scrum teams adapt by shifting a step by step away from the core principles of Scrum, hoping to find other agile ways of driving the projects. Actually, while Scrum might be the most widely implemented agile framework, most of those teams are really not 100% Scrum applicable. Also according to Jeff Sutherland “over 50% of the teams that claim to be Agile do not have working software at the end of short intervals and that is definitely not Agile". According to my experience, this problem exists often especially within Scrum teams.
It’s not because Scrum wouldn’t be an excellent framework. It’s just that it’s not equally as good for every team. Scrum fits perfectly to long-term product development, lean startup development and agile enterprise software project management. In these cases work is more iterative problem solving than fixed deadline deliveries having unpredictable dependencies.
After helping dozens of Scrum teams in their process improvements, I’ve identified these three challenges as the most common reasons why so many Scrum teams have moved on to find other solutions into their teamwork:
Fixed length sprint is often too strict
It would be too easy to say that just adapt your customer projects and deadlines to match the sprint schedule. Unfortunately we cannot control the world so much. Many projects are depending on other projects - from their outcomes but also their deadlines. It might be that our team receives critical information or a new component just in a middle of the sprint. Starting a sprint before this kind of bomb doesn’t make sense and waiting even few days to start the next sprint would also be just too long delay.
If such a work is started in a middle of the sprint, it typically means that a new story is just moved from one sprint to another, making sprint review less meaningful. Or perhaps a story is split into two - but that’s typically an artificial way to do it and doesn’t solve the core problem, which is rooted into project schedule. Demo event and sprint planning in a middle of the deadline doesn’t make much sense if there’s not even a possibility to deliver a fully functioning software within given time box.
This challenge is typically not seen in product development teams, but rather in rapidly progressing customer projects that have a sharp beginning, milestones with dependencies and a shared ending. Scaled Scrum does not solve this either, because dependencies can spread across organisations that are not sharing the same approach.
Review processes can be difficult to schedule
Especially in larger corporations, for example in data warehouse development, customers of the project might be teams or business managers from different departments. It’s difficult to demand them to review the end results within a sprint. Product owner can only make the best guess during review but without a proper customer validation or user testing.
Making acceptance criteria more perfect for reviews would cost too much time and effort - and besides in iterative development the experimental approach has its' benefits. In this kind of cases outcome of the sprint is simply not a fully functioning software. It might be a set of features that are deployed to an integration test environment where they might wait several weeks before proper reviews.
Startup guys would now say that this sounds like a slow-motion movie. That is totally true. On the other hand to change this we would need to change the whole organisational structure and behaviour. The problem is that in large corporations we probably cannot even change the structure of our own team because of the regulations and legacy. Typically it’s more reasonable to ask a team's process to adapt instead of changing the world around it.
In large corporations it’s often commonly accepted that iterations leave a long tail of unreviewed software. This requires processes that are not easy to fit into Scrum approach. It might even violate the basic principle of agile development: Delivering a fully functioning software at the end of the each iteration. A Scrum team in this kind of environment simply fights against the windmills.
Not all developers are equal
This issue is visible also in smaller teams. For example in 3D game production there might be a game designer, visual designer, technical modeller, behaviour programmer, 3D developer and backend developer forming a single team. In Scrum there’s only one developer role and those developers should share and implement the items more or less democratically. In reality at the beginning of the sprint all tasks are assigned directly to named developers and team’s decision making is getting significantly narrower. The whole sprint might look more like a process instead of a list of items with workflows.
A user story might have three or four different people working on it - which makes the sprint development unpredictable and difficult. If one developer has a delay, rest of the chain suffers and sprint deadline is easily missed. In Scrum this means that Item goes back to product backlog and is continued during the next sprint. Splitting items into stages would lead to a waterfall process where designers work during first sprint and developers during second. We all know how waterfall process fits into software development - it’s a total no-go.
Fortunately there are plenty of solutions to overcome these challenges and still keep the work agile. All of these issues could be solved also with the Scrum, but the ultimate question remains. Which approach is more cost effective: Forcing the team or organisation to work with Scrum discipline just because it’s possible, or moving on to another agile approach by learning and adapting. Majority of the teams select the latter.