This article is part three of Toptal’s Agile scaling series, designed to guide project managers in their team expansion efforts. Be sure to read part one, “5 Agile Scaling Frameworks Compared: Which One Should You Use?” and part two, “Agile Scaling: SAFe Best Practices for Scrum Masters.”
Agility is practiced in some fashion by 94% of companies, according to the 15th Annual State of Agile Report. But research also suggests that 90% of organizations struggle with enterprisewide Agile implementation. Typically, it’s the work of Agile coaches, Scrum masters, and other project management professionals to lead and organize these efforts. Often, they are working with teams or departments that are resistant to change, in a company culture that is difficult to understand.
In this roundtable, three Toptal project managers discuss the challenges of leading Agile transformations. Because their solutions comport with the Scaled Agile Framework (SAFe), we also spoke with Dean Leffingwell, creator of SAFe. Their collective insights illustrate the need for SAFe practitioners to prepare a clear vision of what agility is and a leadership plan that can bring recalcitrant teams on board.
Talking SAFe With the Framework’s Creator
SAFe, a framework formalized by Scaled Agile, dates back to only 2014. But for Leffingwell, the work began when he first encountered Agile teams in the early 2000s. As a software development methodologist, he was impressed with the results of Agile practices on dev teams, and he immediately began exploring how the mindset could be applied across an entire company. If an Agile team could produce results, what could a team of aligned Agile teams produce? How could Agile practices be used for full-scale transformation projects at national or international companies? As Leffingwell puts it, “I love software development. I love Agile. I just want it big.”
In the years since, companies have recognized the benefits of SAFe, including shorter deliveries, higher product quality, greater efficiency, and more engaged employees. As of 2021, more than a third of organizations around the world used SAFe, and among its most important aspects are the shared processes and unified language that it provides. For example, if one team thinks a sprint is two weeks long and another thinks it’s 30 days, it creates what Leffingwell describes as a “Tower of Babel problem.” It’s hard for teams to discuss what features to add if they can’t even agree on what “feature” means. “You [need] people working in a common way if you want to build big solutions,” he says. “There’s not a term in our industry that isn’t overloaded, like ‘iteration’ or ‘sprint’ or ‘backlog.’ That’s not helpful if you’re trying to work across team and regional boundaries.”
Agile Success Stories
Getting everyone at a company to adopt a unified way of speaking about and doing work is a daunting task even when there’s a tremendous urgency for change. In established corporations, it can be harder. Leffingwell elaborates: “You’re looking at the largest companies in the world that are making lots of money and doing incredibly well and competing—and they have to change. Well, the question for them is why should they?” The Toptal project managers featured here each encountered questions like this during their own scaling activities, and each found their own way of working through their Agile transformations using SAFe.
Demonstrating Value
Alvaro Villena, a Toptal project manager in Santiago, Chile, recently completed a SAFe transition for a portfolio developing a cross-business platform. “The first milestone in my transition was conducting a value stream workshop,” he says. In simple terms, a value stream workshop is a kickoff meeting to identify the entire business process from concept to delivery and all the steps, users, systems, and pain points in between.
Getting representatives from the entire enterprise into the workshop helped Villena understand the company culture and what his obstacles would be. “Before we implemented the workshop, there was a structure where one business had their team, another business had their team, and the next business had their team—the three didn’t talk to each other.”
Villena found that although all the teams shared similar pain points, there was no collaboration on solutions. For instance, although every business in the portfolio shipped products, only one had developed a tracking system. There was no reason they couldn’t all use it, except that nobody had shared the knowledge. Once the workshop got them talking, knowledge started to flow among teams, businesses, and product owners. “That kind of conversation was really, really powerful for the program. It was a nice starting point,” Villena says. When DevOps, design, and product all know what other teams are doing, they see that there are solutions in the company that they can be using. “They start asking, ‘How can I have that?’ And that’s where you step in and say, ‘Follow this process.’”
“Nobody wants change until they know why. So you start with a why and give them a better future.”Dean Leffingwell, creator of SAFe
Leffingwell knows that teams are sometimes resistant. “Nobody wants change until they know why,” he tells Toptal. “So you start with a why and give them a better future.” Giving teams a glimpse of how much more efficient they can be is a powerful tool for change leadership.
Even when everyone is enthusiastically on board, you should still expect rocky starts. Teams that are accustomed to traditional Waterfall development and big releases, for example, may have trouble moving to a more iterative and agile development process, even if they see the value in it. “The first program increment that we did was kind of a disaster with the teams,” says Villena. “And we knew it would be; we told the client to expect that the first three months may be difficult.” To compensate for this, he built in a one-time weeklong iteration at the end of the first program increment (PI) in which the teams could evaluate their progress. He organized a sprint devoted solely to process improvements and evaluations that would go beyond the usual inspect and adapt. He found it useful to apply an Agile mindset to not just the product but also the business transition, taking the time to step back, see what worked and what didn’t, and adjust accordingly.
Creating Small Victories
It’s important to be prepared for unexpected obstacles in your SAFe adoption. Some years ago, Toptal project manager Miroslav Anicin in Belgrade, Serbia, was transitioning a telecommunications company to SAFe. The company had outsourced all of its software development. Incorporating an off-site team wasn’t a particularly onerous task—the issues involved were mainly logistical. But the effort created unforeseen challenges in transitioning the company itself. “I was searching for the competencies we need in the release train,” he says. “And all of the people I had to choose from were from marketing, from legal, from products, from finance—completely lacking the Agile mindset or even any experience in Agile.”
It became evident that management had no experience handling Agile teams. Distributed decision-making requires managers to relinquish some control, a fact leadership can balk at if they’re not experienced with Agile frameworks. To solve for this, Anicin had to train from the bottom up and from the top down, coaching leaders along with their teams.
Such a move to more decentralized decision-making requires “changing the way of working from command and control, through servant-leadership, to this empowering culture of learning and culture of Agile—and the ability to tolerate mistakes,” says Leffingwell.
Anicin began the process of scaling incrementally—with small Agile projects performed within single teams, not within a SAFe framework—so individual teams could develop some hands-on experience. These projects had to be nonessential and small enough that the company wouldn’t be harmed if something went wrong on the first try but useful enough to show the team what could be accomplished with the approach. For instance, the marketing team created an internal marketing campaign, during which Anicin taught them the basics of Scrum. Similar to Villena’s workshop, these smaller projects demonstrate the value of Agile in real terms, so team members and leadership can see the benefits of short releases and continuous improvement before the full-scale transition.
Meeting the Needs of Your Teams
When Imane Marouane, a Toptal project manager based in Paris, led a transformation for a large, multinational financial institution, she stepped into a chaotic environment where individual teams produced solid work but shared no companywide vision. “Each team had their own priority. Each product manager wanted their product to be delivered first.”
SAFe’s solution to this problem can be found in the weighted shortest job first (WSJF) model. WSJF provides a standard for prioritizing work so when it’s time to decide what the next task should be, the first step doesn’t involve disputes over how to rank importance. In a flow-based Agile system, you don’t have to worry about delivering everything at once because, as Leffingwell says, “the most important thing is what job to do next. And that’s a much easier question to answer than what’s the most valuable job.” SAFe provides a way to resolve dependencies between teams—ordering tasks is essential to this outcome.
Marouane’s path to dependency resolution became uncertain: “After two sprints, before the first inspect and adapt, we noticed that some teams were not following our PI plan.” Dependencies that were defined in the PI plan weren’t being followed, so one team’s work couldn’t begin because the contribution from another team wasn’t ready.
“Since it was the first iteration, and the teams weren’t used to this kind of work, we decided to put an extra ceremony into place—a weekly meeting to discuss progress on dependencies,” Marouane says. “One person from each team came to update progress on their contributions.” This way, if Team A said they were unable to deliver, Team B could know ahead of time and plan accordingly, instead of waiting for contributions that weren’t going to materialize at the beginning of their sprint.
Leffingwell preaches caution when making these kinds of adjustments to SAFe: “SAFe is a system of responsibilities. … You can adapt it, but you’ve got to be really careful.” Although the framework is intended to be adaptable, changes tend to get baked in if not reassessed. The Essential SAFe configuration exists to make sure that any alterations meet basic criteria.
Marouane’s extra ceremony was included again in the second PI, and by the third it had been phased out. Teams had nothing to report on that hadn’t already been communicated. A little extra flexibility allowed Marouane to get the teams back onto a more traditional process track. She found that the transition itself required an Agile mindset to get the most out of the financial institution’s teams. And importantly, the change she made, through its commitment to continuous improvement, ultimately served the Lean-Agile principles that are the groundwork of Essential SAFe. Her solution gave the company the unified vision it lacked and allowed the teams to work together toward the same priorities.
Adapt for the Future
Any framework operating at scale is going to come with challenges. The number of moving parts and competing interests is immense. But the payoffs are equally large, and a well-executed transition will give teams the tools they need to work toward common goals. The obstacles you face in such a large-scale implementation will be unpredictable, and an Agile mindset helped Villena, Anicin, and Marouane adapt to unexpected challenges. After all, that’s what continuous delivery is for: empowering your process with the tools to adapt to the unforeseen.
Scaled Agile also adapts to new technologies and evolving industry standards, introducing new tools and capabilities as necessary. Everyone needs to stay nimble and prepare for the unexpected. “We have no crystal ball,” says Leffingwell. “We just run fast, lead hard, and follow hard—and write as fast as we can.”