This is the third blog in a three-part series in which we explore scaling agile in further depth. It is common for organizations new to agile to approach scaling similarly to how they would roll out a new software package. This is what is referred to as ‘waterfalling an agile approach’ and is considered a failure mode. How can this scaling agile trap be avoided?
Start small and create advocates
Using an agile framework to roll out the selected scaled agile framework is important. Prototyping with multiple agile teams provides valuable information for set-up, inception, and completion. However, before rolling out a scaled framework, it is important for everyone the change is affecting to understand why it is happening. A communications plan can help foster a more supportive environment, across the company. Next, it is important to trial agile ways of working with early adopter teams. This enables experimentation while limiting risk and allows for easier adaptation of the processes to fit the environment. Small successes should be celebrated, and the teams involved in the experiment should be empowered to be advocates for the agile approach.
Push vs Pull systems
In the context of a system, ‘push’ work can be done by assigning work to the team, or the team can ‘pull’ work in by self-assigning the work. Traditional project management is a push-based system in which a Project Manager determines who is going to work on what and assigns the tasks. Agile is built around the idea that Work in Process (WIP) should be low and therefore the teams should only add to their workload when they have capacity to do so.
There are those that believe if you show success, others will want to emulate that success, demonstrating a pull method. There are others that believe change is an impediment and there has to be an impetus for people to change, thereby advocating a push system. It is likely that both methods will be utilized at some point when navigating to a scaled solution, although advocating a pull method aligns with agile values.
Obtain executive leadership endorsement and involvement
Leadership must create a sense of urgency to proactively drive change by providing a vision of a better future state and giving their teams compelling reasons for the transformation. To play this critical part, they need to understand agile and be ready to learn and exhibit new leadership behaviors. Executives must also provide the high-level objectives to which their organization can align and empower their people to make decisions without constant supervision. This will give teams the license to experiment without fear of failure.
Align around value streams
Identifying end-to-end value streams that deliver real value to a customer ensures the streams can be optimized and teams can be assembled around them. It minimizes hand-offs in delivering value to the ultimate customer for that stream. Once these have been identified, determine the most valuable stream to begin with and start with that single value stream. Train the members of that value stream and ensure that there are knowledgeable change agents to guide and support teams as they rally around a new way of working.
Sustain and increase capability through Change agents
Without knowledgeable change agents the initiative will either fail to properly get off the ground or will lose momentum and stagnate, especially as the going gets tough. As individuals progress down a new learning curve there is an inevitable dip in productivity, and they will easily be tempted to return to their old behaviors unless they have the support of knowledgeable coaches to spur them on and help them refine their newly acquired skills. This is also where new leadership behaviors can help by acknowledging that output is not tied to value creation. Ensure you demonstrate and celebrate success. This creates desire within the rest of the organization and reinforces a pull rather than a push system.
Inspect and Adapt
Although you’ve started working in a scaled framework, and the teams are delivering value together, you’re not done yet! Now comes the challenging (and fun) part of tailoring it further to work best within your organization. Because these are frameworks and not methodologies, they are meant to be adjusted, tweaked, and tailored to you, your organization, and the way your teams are most effective. No matter which framework is used, whether it’s specifically called out in the framework or not, there should be a time when you get your scaled teams together to evaluate and improve the way you’re working. For instance, SAFe mandates a group retrospective (called Inspect & Adapt) during each Program Increment (8-12 weeks), while LeSS advocates a retrospective across teams every iteration. Each of the frameworks articulates the value in pursuing continuous improvement. It is important to identify experiments and hypotheses that can be proven out during the course of the iteration. You can likely look around your organization today and identify opportunities for an experiment that might generate a positive outcome using an agile approach.
“The real measure of success is the number of experiments that can be crowded into 24 hours.” —Thomas Edison
Extend to supporting parts of the business
Often, agile teams come across challenges from other interfacing parts of the business or the need to deliver extensive business cases to gain funding for the initiatives. To address these issues, it is highly beneficial to extend knowledge of agile and its principles to those functional areas (e.g. service transition, operations, procurement and the portfolio management function). This creates alignment, improves productivity, and speed of delivery.
This is the third and final blog in a three-part series in which we explore scaling agile in depth. The first blog discusses the advantages of agile scaling and the second blog recaps popular scaling frameworks. Armed with these insights, now it’s up to you to determine the journey to agile at scale within your organization.
