The list already says more than 54 words. There’s 55. But they imply much more than their measly number. Let’s put a little depth into the 5 critical pitfalls.

Lacking Definition of Done

Scrum is silent on technical practices, simply because it’s a work management framework and agnostic to the context. But that doesn’t mean the the technical level doesn’t matter. Imagine putting Kimi Räikkönen to drive a Lada, will he perform well in a race?

For a Scrum to really take off and work, the team has to at least be able to complete a working version of the product at the end of the Sprint. That’s the absolute minimum. It should be better than that, really. Ideally, at the end of every single small modification. The working increment is a confirmation that whatever the team tried to do is working and enables us to actually eliminate the technical risk associated with that change. The smaller the timeframe, the smaller the risk.

These points of working code are critical for Scrum, too. They are the only points where change is safe. Or even really feasible.

The only way to achieve such fast iteration time is to use proper Agile development techniques, like eXtreme Programming and it’s modern evolutions. Continuous integration and deployment, test automation, trunk-based development, etc. These have been around over 20 years, and yet too few teams are aware of their true power. Too few organisations are putting consistent effort into the infrastructure and skill development required. Those that do, though, tend to kick ass.

Lacking or Poor Retrospectives

A huge part of Scrum is the evolution of the process within the Scrum Team (and even outside it). Without a consistent approach to continually learn about our challenges and seeking improvements, there will be no progress in efficiency and effectiveness. The Scrum Team is stuck at whatever level of productivity they started with. Or, more likely, as the product grows and becomes more complicated, they start losing their speed and quality. This is the opposite of what should happen.

Scrum isn’t really about assuming that it magically makes teams faster. It doesn’t. The magic doesn’t happen when you start – you are where you are, and you aren’t transported to some better place. But Scrum is supposed to get you started on a journey. You create a system that starts refining itself, and over time, you find that things get better. Without good culture of continuous learning, that just doesn’t happen.

Lack of Management Support

You can get a way with the lack of management support for a while. As long as you have an excited team and PO, you can improve your own internal ways of working. But at some point, you will run against the rest of the organisation. At that point, the lack of management support will stop your progress and frustrate you. You will find out that the impediments in your environment will not get removed. You will find that external demands will negatively impact your internal way of working. Frustration will, very likely, ultimately result in the loss of motivation and the Scrum will fail.

Some say that this is the biggest single failure point in using Scrum in organisations. Without such support, the excited people will only create small bubbles of Agility, and when the excited leaders get frustrated and leave, the bubbles collapse. Just last week, I had a friend of mine talk exactly about this – a great manager had created a great workplace within his organisation, but he ultimately grew tired of the continuous opposition from the rest of the organisation, and the bubble collapsed within a week of his departure as non-Agile managers took over.

No Focus on Team Formation

I wrote more about teams and team formation here, here, and here. The bottom line – transforming to and acting like a team is the powerhouse of Scrum, and lack of it creates, well, lacklustre results. Instead of people collaborating over disciplines to create innovative results, people work at their individual tasks and deliver merely what is asked of them.

Traditional management is focused on dividing the work into actions and then tracking their completion through individual effort. While in some environments this can be an efficient strategy, it has a few critical failure points in Scrum. The members of the team are not focused on the whole and may often lack important contextual insight that often results in wrong solutions. They don’t necessarily understand why the product is important and that has a demotivating aspect (as humans, we like to know that our work is worth doing). The learning within the team is reduced.

Finally, the focus on separate tasks creates dependencies within the team and these will delay any work done. It has a serious negative impact on the team’s ability to deliver working software frequently (see Critical Pitfall #1 above).

No Focus on Good Product Owners

You’re taking your loved one to a beautiful dinner, hoping to make them feel special and valued (so that they would appreciate and love you in return). What is more important, quality or quantity? Is it better to have small portions of something really wonderful and delightful, or go for a large quantity of junk food (like french fries).

If what we deliver is not valuable to our customers, it doesn’t matter how much of it we deliver. And if they really love what we do, even less of it is awesome.

The Product Owner role is in a crucial place here. They must be able to crystallise the needs of the users and customers, combine them with the business interests of the organisation, understand the constraints in technology and business environment, and prioritise the Product Backlog in such a way to maximise the total benefit to the organisation in short and long term. Not an easy feat. Luckily, they don’t have to do this alone – the Team and the stakeholders will usually help in many ways.

But, if the person playing the role doesn’t have these insights? Or even if they do, but they lack the authority or resources to act on the insights? The result is obviously a “bad Backlog” – it instructs the Team to build a poor product, or in poorly planned way.

Unfortunately, these “poor PO’s” (usually not because of the person’s fault) are quite common, particularly in larger organisations. They don’t have direct access to customers. Instead, they are fed individual requirements from higher up, and they then pass them to their teams. There’s very little Agile in this setup. At this point, of course, this isn’t the fault of the team level PO’s. They are flies in a web, caught and unable to influence the situation.