<img height="1" width="1" style="display:none;" alt="" src="https://px.ads.linkedin.com/collect/?pid=299788&amp;fmt=gif">
Skip to content

Guest Contributor: Robert Nadon

Untitled-38

Once your organization has adopted agile and experienced the many benefits of it,  including flexibility, speed to market, costs, and more, the natural next question is: should we take it to the next level and move to scaled agile? In this blog post, I'll pose five simple questions to ask yourself to help guide you on your scaled agile journey.

Large organizations evolve over time and have a tendency to create policies, methodologies, and practices that vary from department to department. I have worked with many large organizations—and while there are some top-level corporate ideals and practices that are adopted by everybody—the more likely story is that the various departments operate as separate entities. While this sometimes works well, if there isn't good alignment across separate divisions or departments, there can be also be duplication of efforts, waste, and interdepartmental fighting.

One good solution to this is to move everyone to a similar method or system of software development and track how each department's solutions and products interact with each other. If that sounds daunting, it is! And without a proven methodology in place, it can cause more problems than solutions.

So what can you do? Well, for many organizations, particularly those that deliver software and internet-based products, the answer is scaled agile. 

Next, I'll provide a little background on agile and scaled agile, then I'll get to those five important questions that will help you determine whether or not to move to scaled agile.

 


What is Agile?

The agile software development lifecycle is a set of methods and practices for supporting a team of engineers (developers, testers, product owners, etc.) as they create solutions in a dynamic environment. It's designed to not only allow for change but also to embrace it. Agile is based on the notion of self-organizing teams consisting of cross-functional members.

Within agile's primary predecessor, the waterfall model, a change to a product's functionality in any stage past the requirements phase would cause large cost and time penalties that would frequently push any type of non-detrimental change to the next release. The cost would increase the farther down the waterfall the change was found to be needed.

 


What is Scaled Agile?

Scaled agile is taking agile and spreading it across an organization, including multiple teams and products. In 2011, Dean Leffingwell realized that these self-organizing teams were great, but not really practical when it comes to large organizations (due to many interacting teams and developing products that were dependent upon each other). His solution to this problem was SAFe®, the Scaled Agile Framework. Since that time, there have been many frameworks that have come out to solve this problem, and collectively, they're referred to as scaled agile.

 


Should My Organization Move to Scaled Agile?

Scaled agile brings many advantages to large organizations; however, there is a lot of overhead and extra activities, costs, and tools necessary to truly reap the benefits of moving to a scaled agile model. 

So how do you know if you're ready? There are several factors you should evaluate, and these five questions will help you do just that!

 

1. Are you already agile?

If you're not already agile, trying to jump directly into scaled agile is, to put it nicely, a little overambitious. First, try moving a few teams to agile and see how that fits into your corporate culture.


2. Do you have at least 50 engineers developing products?

There is a threshold to reach before the cost and overhead of a scaled agile framework are worth the investment, and although it is not a hard and fast rule, that number is generally around 50 engineers. If you don't have at least 50 engineers, chances are that a less-formal solution can be found to align and track interdependencies between your agile teams. 


3. Does your organization have teams, projects, and activities that really do not align with the company vision, direction, and goals?

From my experience, one of the best benefits of using scaled agile is that it can find teams, projects, and activities that really in no way correspond with the vision, goals, and direction of the company. Once discovered, these initiatives can be eliminated, and the resources behind them can be redirected to initiatives that do align with company vision. I've had clients who stated that, by finding and eliminating these activities alone, they saved enough money to make the entire effort to move to scaled agile worthwhile.


4. Do you have interdependencies between teams? 

This is another big selling point for scaled agile, and some say it's the reason it was originally created. Agile teams work independently in silos, and tracking the dependancies across agile teams, without using a scaled agile framework, can lead to a shift away from "true" agile. Picture this: you have teams, A, B, C, and D, and they all depend on each other. A and B decide to have people from each team join the other teams' scrum meetings, and teams C and D decide to have additional cross-agile meetings to keep in sync with each other. Now A & D try to find out how to fix their dependancies, as do A & C, B & C, etc. Using the same process across each will become a necessity. That consistently will come from all following the same scaled agile methodology.


5. Do you align your portfolios to the team level?

Some of the scaled agile frameworks will go as far as to align each story or piece of work to what portfolio the effort is coming from. This can be beneficial in doing projected budgeting and resource analysis; however, it will add to the overhead in that the mapping must be done, and if not done correctly, it can cause more harm than good.

Do you need to answer all of these questions with an absolute "yes" before deciding to move to scaled agile? No, you do not. However, I would say 1 and 2 are required, as well as having at least a desire for the next three before you to starting the migration to a scaled agile framework.

 


OK I'm Ready! Now, How Do I Get There?

There are several different frameworks for moving to scaled agile. I would recommend that the first step would be to evaluate the different frameworks and find which one most closely matches your corporate culture. Some of the more common frameworks are:

  • SAFe, Scaled Agile Framework
  • S@S,  Scrum At Scale
  • LeSS, Large Scale Scrum
  • DAD, Disciplined Agile Delivery
  • Nexus
  • FAST, Fast Agile Scaled Technology 
  • Spotify
  • and more...

Once you have chosen a framework, I recommend hiring a framework expert. Many of the frameworks have certifications that qualify candidates to be able to implement them. Also, there is no substitute for past experience. If you cannot find a candidate, many of the frameworks have people or teams that can (for a price) walk you through the initial phases of migrating to it. 

Next, remember it is a framework to follow, not a blueprint. This means that not every part of the framework is necessary to achieve success. If there are portions within the framework that have results that can be accomplished in other ways in your organization, then substituting those should not cause major concern. However, these items should first be reviewed and approved by the framework expert, in order to ensure that you are not deviating from the frameworks ideals.  

Next, find the right set of tools. There are tools that can help organizations get the framework functioning. Of these tools, my top choice is Jira Align. However, just like frameworks, there are a ton of other tools available.

Finally, when implementing the framework, start off small.  Do not try to do everything all at once. Instead, pick a single program or a set of teams. I recommend picking ones that are both anxious to move to the new framework and those that will be the easiest to move. By doing this, the framework can be implemented and initially launched, and lessons can be learned before tackling those areas that are going to take a little more effort to convert. Also, once the first programs launches—if done properly—teams dedicated to other programs and areas will see the benefits, and this will make them more eager to adopt the practices.

I hope this introduction to scaled agile gives you a little insight into the movement!

Download the whitepaper

See More From These Topics