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.
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.
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.
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!
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.
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:
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!