Tuesday, March 25, 2025

Why Scaled Scrum Projects Fail: 10 Mistakes to Avoid

  

There are many scaled Scrum projects that have been failures. Although Scrum, an Agile approach, is widely used at the team level, when it comes to scaling, it's a different ball game altogether.

Apart from the CIPSA Framework, there are several frameworks available, such as SAFe, Scrum@Scale, DA, and 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 these failures and the mistakes 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 mostly theory, and more theory. While theory is necessary, it's practical implementation that actually matters. Apart from CIPSA, not a single scaled framework is practical or hands-on.

In large teams, you can't have physical whiteboards or Scrum boards. You need to use software tools that 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 grows exponentially with more 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 the right framework comes in.

Continuous communication should be maintained 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, bringing bureaucracy. 

If the framework prescribes too many roles, 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 frameworks, such as "waterfall with red tape 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 toward 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, with the other backlogs kept minimal. Once done, those backlogs (other than the product backlog) should be discarded.

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

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

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

The framework should be 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 provided, Scrum at scale has no value. 

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

Scrum (and other Agile approaches) emphasizes 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 promotes a sustainable pace, the reality on the ground is quite different. Sustainable pace is one of the 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 still remain. With cross-team dependencies, imagine a few engineers across teams falling sick or leaving the teams. 

Conclusion

As your organization grows, scaling becomes inevitable. When you undertake projects to build products or provide solutions and adopt scaling approaches, using a Scaled Scrum framework is essential. However, it should be a framework that is not complex, but simple.

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

As this article emphasizes, the framework should not have layers of bureaucracy that stifle progress. The roles, goals, and artifacts should be minimal, but the value they provide should be maximal. 

Get CIPSA certified – Not only Practical, but also Economical

The CIPSA Scrum framework is the simplest framework in the world. It’s practical, hands-on, and offers in-depth explanations of the artifacts, roles, goals, and other areas that are critical to its success.

Certification costs for Scaled Agile frameworks can often be prohibitively high, running into thousands of dollars.

However, the CIPSA certification is not only practical but also very economical.

--

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


Certified In Practical Scaled Agile (CIPSA)



Monday, March 17, 2025

Scrum at Scale with CIPSA: Multiple Teams and Synchronized Scaled Sprints with MS Project Agile (Part - 2)


In the previous post, we learned about:

  • Synchronized Sprints in CIPSA
  • Stock-Trading System's Product Backlog (single one)
  • Planning and Addition of Sprints
  • Seggregation of Individual Scrum Teams
In this post, we learn how to combine them and manage Scrum at Scale. It's the concluding part. 

The contents are from ManagementYogi's Certified In Practical Scaled Agile (CIPSA) Course. You can download and read the CIPSA framework guide for free here.


***

Add the Individual Scrum Teams

In this step, we will associate the work items with the respective Scrum teams. This will be decided in the CIPSA Sprint Planning meeting, where the “what” part is decided. Do not confuse this meeting with an individual Team Sprint Planning meeting, which happens later. It’s the CIPSA Sprint Planning, during which the planning is taking place at scale.

To have the work items associated, add a new column into Sprint Planning Sheet view and associate with respective Scrum teams. Next, choose the team from the drop-down list and associate it with respective work items. 

Associate the Sprints the Scrum Teams

Our next step is to associate the planned Sprints with the individual Scrum Teams.

To associate the teams with Sprints, select the Sprint column available in the Sprint Planning Sheet view and select the Sprint number from the drop-down list. This is shown in the below figure. While we have planned for five Sprints, our upcoming Sprint is Sprint 1 and each team will Sprint on its own with this Sprint number – Sprint 1. 

In the above figure, again, did you notice that all teams will be sprinting on the same Sprint, i.e., Sprint 1?

This is a significant point to understand. There are no separate Sprints for separate teams. Rather the Sprint Planning is happening at the Global Level for all the teams and then we are associating the Sprints with the teams.

An alternative and relatively familiar view for many of you will be the Gantt Chart view. This is depicted in the below figure. 

In the above figure, I’ve added three new columns:

  • Built-in field of “Sprint” informing the Sprint number.
  • Built-in field of “Sprint Start” and “Sprint Finish” which shows that the features across the teams are to be completed within the Sprint duration.
  • The custom field of “Team” shows the feature distribution across Scrum teams.

As explained earlier in the first video, the CIPSA Sprint Planning will be succeeded by the individual Team Sprint Planning event and tasks will be further decomposed. When the respective sub-tasks are added, the CIPSA Sprint Backlog will be the sum of all individual Team Sprint Backlogs. This is shown in the below figure. 

The above highlighted areas in the figure is the CIPSA Sprint Backlog, consisting of individual Team Sprint Backlogs. This backlog will get progressively built-up with CIPSA Frameworks’ meta events and other events.

Again, the key points to note here are these:

  • All Scrum Teams are sprinting on the same Sprint – Sprint 1. But they are executing the work items separately.
  • All Scrum Teams are sprinting towards the same CIPSA Sprint Goal, which is in sync with the Product Goal.
  • Individual Scrum Teams will have individual Team Sprint Goals, but these goals must be in sync with the CIPSA Sprint Goal.

Demonstration: Scrum at Scale using CIPSA Framework

Let’s have a demonstration of what we have learned so far with our practical scaled approach using Scrum to deliver a product. The below video [duration: 7m:19s] demonstrates such scaling with MS Project Agile. Again, plug-in your headphones to understand with more clarity.  


Conclusion *** UPDATED ***

Scaling is complex, but the framework need not be complex. Scaling involves complex cross-team dependency management, collaboration, multi-Sprint management, multi-team tracking, board management, integration of individual team increments and above all, delivering value to the customer or end user. However, with the right practical scaled agile framework – in this case CIPSA, right software tool, much of the heavy lifting can be done.

A big misconception in Agile practitioners’ circles is that MS Project is not at all suitable for Agile at Scale, not just Agile! As we just reviewed in this article, MS Project Agile can effectively be used to scale multiple Scrum Teams with multiple synchronized Sprints and deliver complex products.

The series is concluded. 

I welcome your thoughts, comments, and feedback in the comments section below.


--

This article was first published by MPUG.com on September 4, 2024. This is an updated version.


References

Wednesday, March 12, 2025

Scrum at Scale with CIPSA: Multiple Teams and Synchronized Scaled Sprints with MS Project Agile (Part - 1)


Scrum is fundamentally a single team-based Agile framework. In fact, per the latest Scrum guide, it’s suitable for a team of ten or fewer people. But in reality, large and complex products or solutions demand larger teams to achieve quicker delivery times and meet the market’s narrow competitive windows. In other words, Scrum at Scale is a necessity, not a desire.

Now, to consider Scrum at Scale, one must consider all the building blocks of Scrum – the events, artifacts and roles (accountabilities). For example, considering events, Scrum at Scale requires planning, reviews, retrospectives, and daily stand-ups at scale.

While all aspects of Scrum are necessary, this article will focus on scaling for planning, specifically Sprints. While doing so, as our focus is on practical, hands-on applicability, we will first explore Multi-Sprint, Multi-Team management with the CIPSA framework. CIPSA (pronounced ‘sip-sha’) stands for Certified In Practical Scaled Agile and extensively uses MS Project Agile software tool to do scaling. You can download and read the CIPSA framework guide for free here.

Sprints at Scale with Multiple Teams *** UPDATED ***

In the CIPSA framework, when you team-level Scrum, it’s called CIPSA Scrum Framework and when team-level Kanban is used, it’ll be CIPSA Kanban Framework. The CIPSA Scrum Framework is shown below. 


A single Product Backlog is cross-team refined and presented with the Product Goal to the CIPSA Team (sum of all Scrum teams) in the CIPSA Sprint Planning meeting. In this meeting, the “what” items to be delivered in the upcoming Sprint is decided. The items are taken from top of the Product Backlog and individual Scrum teams will execute the work items.

The below video [duration: 3m:22s] sheds light on how multiple Scrum Teams will tackle a single Product Backlog, take the backlog items, and execute them in respective individual Sprints. Watch this video before proceeding with the article to have better clarity. For the best experience, go full-screen HD mode and plug in your earphones.  


Synchronized Sprints in CIPSA *** UPDATED ***

Did you realize in the above video explanation that the Sprints across the teams are synchronized? It’s a key point to understand and apply. 

The Sprints are not only of same duration, but also have similar Sprint Start and Sprint Finish dates. This is important for a number of reasons, noted below:

  • All Scrum teams and its members understand that they are progressing towards the same goal in the current Sprint, which in our case is the CIPSA Sprint Goal. Do note that individual teams can have separate Team Sprint Goals.
  • While increments can come at any point during the Sprint, the final Integrated Increment, i.e., CIPSA Integrated Increment will come at the end of the Sprint. It’s the sum of all team increments.
  • With disparate and uneven Sprint lengths, the individual teams tend to optimize locally, not for the product/system as a whole. But with the same length of Sprint and synchronization, co-operation among teams increases.

Next, we will execute this process step-by-step with MS Project Agile.

Our Product Backlog

In our case, we are building a large Stock-Trading system, on which multiple Scrum Teams will be employed. It’s shown below in the Sprint Planning Sheet view, which can be opened by going to Sprint Tools > Sprints tab > Views group and choosing the respective command from Planning drop-down list.

                  

The Product Backlog has gone through the initial cross-team Backlog Refinement meta-event (which we saw earlier in the first video) and all high-priority items are towards the top. However, at this stage, the backlog items are not out into individual Sprint buckets and are not associated with the Scrum Teams.

Plan and Add the Sprints

To add Sprints across the Scrum teams, go to Sprint Tools > Sprints tab > Sprints group and use the Manage command. Remember to use the available Sprints template to create the plan. Otherwise, you can add the Sprints from Gantt Chart tools > Project tab > Manage Sprints command. For our case, each Sprint will be two weeks in duration with the same start and finish dates. 

As shown:

  • We have 5 Sprints planned for and added into our plan.
  • Sprint 1 starts on Mon 10/5/26. Each Sprint is two weeks in length.
  • Subsequent Sprints are planned and added in similar fashion. 

You can plan for as many Sprints as you want for the CIPSA team. MS Project Agile software provides this capability. 

Segregate the Individual Scrum Teams

In this step we will divide the CIPSA team into three Scrum Teams: Team A, Team B and Team C, working on our single Product Backlog. For that we will add a Team custom field, taking the text custom field. You can create this field by going to Task Sheet Tools > Format tab > Columns group > Custom Fields command > Task custom fields. This is shown below.  

As shown, we have taken the Text1 custom field and renamed it as “Team.” Next, we will use the “Lookup…” command in the above view to add the team details.


As clearly shown above, we have three separate Scrum Teams – Team A, Team B and Team C. These teams are part of the larger CIPSA team but will work in different backlog items on the single Product Backlog. The values in the Lookup table are:

  • Team A, for work items assigned to Team A.
  • Team B, for work items assigned to Team B.
  • Team C, for work items assigned to Team C.
  • All Teams, for work items assigned to the CIPSA Team.
  • Unknown, for work items not yet assigned. This will be the default value.

You may be wondering what items will be for “All Teams”?

It’ll be work items such as CIPSA Sprint Planning, CIPSA Sprint Review, CIPSA Sprint Retrospective, among others. These are meta-events and not specific to individual Scrum Teams.

--


References