Why Scaled Scrum Projects Fail: 10 Mistakes to Avoid

  

There are many Scaled Scrum Projects, which have been failures. Though Scrum, an Agile approach, is widely used at a team level, when it comes to scaling, it's a different ball-game altogether. 

Other than the CIPSA Scrum Framework, there are many frameworks available in the world such as SAFe, Scrum@Scale, DA, LeSS among others. Some of these are scaled frameworks, but not exactly Agile. They hold value, but may not succeed in the real-world. 

This article explains some of the reasons for failures and the mistakes that you can avoid.

Mistake # 1: You're at Scale in size. But are you really Agile (Scrum) at Scale?

At Scale, you'll have a number of teams and team members. While using the framework, you can do tests with respect to values and principles of Agile Manifesto. 

The values of Agile manifesto such as prioritizing individuals and interactions, working software, customer collaboration and responding to change. 

Are they being followed, with the 12 principles? If not, you are not at scale. Not all can scale, but they need right customization.

Mistake # 2: Lack of practical, hands-on applicability. 

This is another key factor. The frameworks available are theory and more theory. While theory is needed, it's practical implementation that actually matters. Other than CIPSA, not a single scaled framework is practical, hands-on. 

In large teams, you can't have physical white boards or physical Scrum boards. You've to use software tools, which can manage multiple teams at Scale.

It can be any software tool, but the framework should be such that it can be supported by any software tool. If you need 10 software tools to manage, that is another problem.

Mistake # 3: Communication paths (channels) go exponential and unmanaged. 

As any management professional would know, with an increase in the number of people, the number of communication paths increases. With 3 people there are 6 communication paths or channels, with 30 people you have 435! In other words, it goes exponential with many team members.

With such an increase in the number of communication channels, communication can break down or may not happen at all. This is where again the role of a right Framework comes in.

Continuous communication should be there among the team members. The right kind of roles and ceremonies, at a minimum, are needed. 

Mistake # 4: Too many roles spread across layers of Scaling, introducing bureaucracy. 

If the framework has too many roles prescribed, then it's no longer a framework, but a bureaucracy jamboree. 

With too many roles, bureaucracy is inevitable. As we all know, high bureaucracy means failure.

In fact, I've seen terms being used in some Scaled Agile Framework such as Waterfall with red-tapes and two-week iterations!

Mistake # 5: There is no goal alignment for Scrum at Scale.

I've seen teams running in Sprints without any goals. I ask them: what exactly are you running towards as you are Sprinting? There is no answer. 

It's a clear case of goal mismanagement and sometimes, no goals at all. 

All the goals at the team-level and also at scale should be aligned.

Mistake # 6: Too many artifacts considered or used, e.g., the backlogs. 

Backlog management is the first and crucial step in Agile. 

The Product Backlog should be one and continuously evolve, where the other backlogs should be minimal. And when done, those backlogs (other than the Product Backlog) should be discarded. 

In some frameworks, there are backlogs after backlogs within a backlog. It not adds more artifacts, but also becomes difficult to manage.

Mistake # 7: The framework followed is complex. Complexities don’t scale. 

Simple things always scale very well, not the complex ones. When the framework is too complex with layers and layers of roles and artifacts, then it's too complex to manage first. Scaling comes later. High complexity means big nightmares. 

The framework should be very simple and easy to follow. 

Mistake # 8: A lack of integration for increments among individual Scrum teams.  

Individual Scrum teams have increments, but often they don't get integrated. At Scale, it's only the integrated increment that matters. If integrated increments are not given, Scrum at Scale has no value. 

Mistake # 9: Not having integration specialists in the Scaled Scrum team. 

Scrum (and also other Agile approaches) talks of neither generalists nor specialists, but generalizing specialists. For integrations, one needs the role of specialist integrators, who are also generalists.

Mistake # 10: Burnout of Software Engineers in a Large-Scale team. 

While Agile talks about sustainable pace, the reality is quite different on the ground. Sustainable pace is also one of 12 principles in the Agile Manifesto. But engineers are asked to work on multiple projects and work more than 12 to 14 hours a day. 

At Scale, such problems get magnified. At Scale, dependencies are minimized by the Chief Scrum Master, but dependencies do remain. With cross-team dependencies, imagine a few engineers across teams falling sick or leaving the teams. 

Get CIPSA certified – Not only Practical, but also Economical

If the framework is complex and is not really implementable in a practical, hands-on manner, then it should be avoided. 

The CIPSA framework is the simplest possible framework in the world. It's also practical, hands-on and in-depth explanations of the artifacts, roles, goals and other areas needed. 

Many times, the certification cost for using a Scaled Agile framework for your team members is quite high. It can run into thousands of dollars.

The CIPSA certification, on the other hand, is also very economical.

--

To find out more about the CIPSA Framework, you can download the CIPSA Framework Guide. It’s free to download. For in-depth understanding, be a CIPSA certified professional.

Certified In Practical Scaled Agile

• Certified In Practical Scaled Agile (CIPSA) Course - Practical and Economical