BETA
This is a BETA experience. You may opt-out by clicking here

More From Forbes

Edit Story

Scaling Agile Software Development for Digital Transformation

This article is more than 9 years old.

True digital transformation initiatives require change at multiple levels of the organization. Revamping the customer experience with digital technologies is never a superficial change, as it requires better, more flexible software as well as a dynamic, agile organization to drive innovation and to respond to marketplace changes.

Agile software methodologies like Scrum and Extreme Programming (XP) are now established approaches for building software in dynamic environments. Agile approaches don’t solve every software problem, however, as they typically work best with relatively small, self-organizing teams.

Scaling Agile to the enterprise level is a challenge that The Scaled Agile Framework® (also known as SAFe™) means to address, as it combines Agile approaches with more enterprise-centric organizational practices. Yet, while SAFe has led to several dramatic successes, challenges still remain, especially as enterprises undergo the broader organizational change necessary for digital transformation success.

Success with SAFe

SAFe is an interactive knowledge base for implementing Agile practices at enterprise scale, according to its Web site. This enterprise-driven approach is largely the brainchild of Dean Leffingwell, Director and Chief Methodologist at Scaled Agile, Inc. Leffingwell has been a leader in the software development industry for decades, having founded Requisite, Inc., the makers of the RequisitePro requirements management tool, now part of IBM ’s Rational division.

According to Leffingwell, Agile methodologies alone do not address top-down questions of business strategy, as Agile teams work bottom-up. “You can’t add up opinions of people to come up with the business strategy,” explains Leffingwell. “Some things require centralized decision making.”

SAFE, therefore, provides the organizational structure for top-down, centralized decision making that works in conjunction with self-organizing Agile teams. “SAFe promotes the core values of empowerment and decentralization of control, but not the decentralization of everything,” says Leffingwell. “Cascading centralization and decentralization leaves empowerment to the troops.”

In fact, neither top-down nor bottom-up adequately describe SAFe, according to Leffingwell. “Program execution happens at the program and team levels,” he explains. “The traditional models of centralized program planning and micro-technical-management are a thing of the past with SAFe. That is empowering.”

This balance of top-down control and bottom-up empowerment has shown notable success at several enterprises. “We’ve seen extraordinary work,” Leffingwell says. “30-50% improvement in productivity and quality, as well as a 2X – 3X improvement in time to market.” Furthermore, many SAFe success stories had little or no Agile to begin with. “ BMC Software , John Deere & Co , Discount Tire – none had real Agile at the start, or maybe just a few Scrum teams.”

John Deere, in fact, is one of SAFe’s most notable success stories. “We knew we needed to increase our speed to market while keeping our budget and resources static,” said Steve Harty, former Agile Release Train Manager at John Deere. “Moving our team to Scrum was scary, challenging, and liberating, all at the same time.  Scrum was ‘our little secret’ that helped move our delivery time timeframe from 12-18 months to 2-4 weeks. Plus, our engineering teams were happier and customer satisfaction went up.”

Discord over SAFe within the Agile Community

In spite of its successes, however, there is disagreement in the Agile community over whether SAFe is as good as it should or could be – namely from Ron Jeffries, one of the three creators of XP and one of the 17 original signatories of the Agile Manifesto, thus making him one of the fathers of Agile. Jeffries points out that “the structure and teaching of SAFe is relentlessly top down.”

In fact, Jeffries is rather cynical about SAFe in particular as well as Agile in enterprises in general. “I’m pleased that larger enterprises are trying to be agile, but I’m not optimistic,” he muses. “SAFe’s strength is that it appeals to large organizations who are not Agile. It confirms that the Big Guys know the stuff and that all that’s needed is for the Little Guys to rush around doing what they’re told. SAFe is trying to build a framework enterprises will buy.”

Leffingwell predictably disagrees. “SAFe focuses on decentralization at the proper level,” Leffingwell explains. “Self-organizing teams of teams, not a command-and-control environment.” But from Jeffries’s perspective, “In an organization where teams can do what we teach,” referring to the broader Agile movement, “there’s no need for SAFe. Most enterprise work can be handled by one or a few Agile teams working independently.”

Proof in the Pudding

This battle of the Agile curmudgeons doesn’t amount to much, however, in the face of customer successes. After all, it’s difficult to disagree with Leffingwell’s rhetorical question, “what Agile value trumps the value of an effective business strategy and great economic results?” Yet, while John Deere was able to move a large software development organization to Agile in a short period of time by following SAFe, they still face challenges.

“We’ve got an organization here that’s developing products and then the big IT organization that’s helping the core business,” says Mano Mannoochahr, director of enterprise architecture, information management and computer security at John Deere. And yet, “there was a period of confusion,” continues Mannoochahr. “Are we helping the core business, or are we creating a brand new business?”

In other words, moving their large software development effort to Agile with SAFe only addressed one facet of John Deere’s overall digital transformation challenge – but there’s more to digital transformation than software development.

“We have thought about how to grow new DNA for the big IT organization through this new organization we’ve created,” Mannoochahr warns, “so we’re revaluating and thinking how to best connect.”

The missing piece of the digital transformation puzzle for SAFe, in fact, may be enterprise architecture (EA). It’s not surprising that EA is out of scope for SAFe, as first, the field of EA has faced a number of challenges in its own right, and second, SAFe questionably casts EA as a software effort.

According to SAFe, “the Enterprise Architect works with business stakeholders and System Architects to drive holistic technology implementation across programs” – an overly technology-centric view of the role of the EA that shortchanges the organizational and process change that digital transformation initiatives require.

In fact, Leffingwell makes it quite clear this software-centric perspective on EA is intentional. “SAFe doesn’t tell you how to transform other elements of the business,” Leffingwell explains. “We’re software guys. That’s what we do. Business issues aren’t our call. Where it touches software is where we can help.”

The greatest challenge with applying SAFe, therefore, isn’t whether it can do what Leffingwell says it can – customer successes are sufficient evidence of that – but rather the difficulty of understanding its scope. SAFe is for scaling Agile software development to the enterprise, but not for addressing digital transformation issues beyond the enterprise’s software development challenges.

Digital Transformation: Getting the Vocabulary Right

The central problem here may simply be one of language. For the digital transformation professional, understanding different uses of essential terminology is a critical part of understanding the overall transformation initiative. “Agile,” for example, may represent an approach to building better software, or may refer to the broader organizational challenge of business agility. Simply scaling up the first sense of Agile as SAFe does, however, is not sufficient for achieving the business agility goals of the transformation effort.

Similarly, “enterprise architecture” is a frequently misunderstood term. People in the software world often use the term to refer to a holistic approach to technology systems architecture, as Leffingwell does. In contrast, many enterprise architects think of the practice of EA as an approach to documenting enterprise best practices following a framework like TOGAF – a perspective that has limited value.

Fortunately, a third sense of EA is becoming increasingly prevalent: agile EA that directly addresses organizational, process, technology, and information change in support of continuous business transformation. This agile enterprise architecture connects the dots between scaling Agile software and achieving the business agility that digital transformation initiatives all depend upon. Digital transformation professionals, therefore, must choose their tools with care.

Image credit: Jack Snell

Follow me on TwitterCheck out my website