Enterprise Agile: One Size Does Not Fit All

Share on LinkedIn78Tweet about this on TwitterShare on Google+2Share on Facebook0

Guest post by Tim Mattix

It’s no surprise that agile development software methods are quickly claiming ground over waterfall methods. The linear waterfall model and its sequential design process run counter to the reality that customers often don’t know exactly what they want up-front; rather, they tend to fine-tune their requirements through ongoing two-way interactions during the life cycle of the project. On the other hand, the evolutionary development approach inherent in agile gives designers more freedom, enabling them to respond to changing needs as they arise.

While the benefits of agile are clear, scaling agile is not without its casualties. Reaping the benefits hinges on adapting the right agile methods to the unique needs of the business—not force-fitting a theoretical “one-size-fits-all” agile framework on your enterprise. One approach to help teams scale agile is PwC’s Architecture Driven Agile, which is well-suited for enterprises that need a strong focus on architecture. Integrating enterprise architecture perspective into any software development lifecycle helps organizations realize and sustain business value. Enterprise architecture thinking is particularly relevant for new software implementations, e.g. non-functional requirements (NFRs), as well as for existing, complex applications undergoing significant change. Architecture Driven Agile takes advantage of agile essentials, while breaking from traditional elements in architecture, planning, and governance.


While traditional agile assumes that architecture guidance is already in the background (often it’s not), Architecture Driven Agile either builds in an architecture strategy and approach from the beginning, or leverages ongoing enterprise architecture processes – both with the organization’s business goals in mind. A common architecture, as well as architecture collaboration, consistency and end-to-end oversight, all help ensure success in scaling agile as interactions become more complex.


While agile teams typically plan in isolation without formal communication mechanisms beyond the scrum of scrums, Architecture Driven Agile promotes a progressive planning process that is required to move requirements from vision to story success. Continuous, sustainable steering committee reviews help push critical program decisions, and a standard planning cycle creates visibility and effective management of enterprise dependencies.


While the efficiency of self-directing agile teams is remarkable, the seams between teams can show in the final product. As agile scales, seams can be eliminated through adapting governance processes, e.g. a flexible governance strategy with a target state in mind, actionable objectives and a focus on collaboration all contribute to success.

Architecture Driven Agile is by no means the only agile framework that we use, and other options are plentiful depending on your needs. For instance, Scrum, the most popular and widely adopted agile method, concentrates on managing tasks within a team-based environment. A more radical approach, Extreme Programming (XP), zeroes in on software engineering while wrapping in novel approaches to boost quality. While Scrum and XP are easier to implement and take on different aspects of software development projects, Dynamic System Development Method (DSDM) is likely the most complete agile methodology. Another option, Scaled Agile Framework (SAFe), banks on leading practices from Scrum, XP, and lean for more complex enterprise scaling initiatives. We’ll do our next blog post on SAFe to provide a deeper glimpse into this approach.

Whatever approach you choose, scaling agile requires complex navigation during each phase. It’s an evolutionary process, requiring balance across many different aspects of the organization. With a strategic and tailored approach, organizations can successfully scale agile and realize all that a greater agile reach has to offer. If you steer clear of the hurdles, it’s a worthwhile journey.

Photo: Tauno Tahk

Share on LinkedIn78Tweet about this on TwitterShare on Google+2Share on Facebook0
  • We agree! Being agile has to be a case-by-case approach and one size does not fit all. Agile success for any company is much more of a journey rather than a race.

  • Nice post. The “architecture-focused” framework that you described is an important addition to agile conversation. From my experience, Agile’s emphasis on iteratively building working and useful software can come with a downside for architecture-heavy enterprises. If short term releases come at the expense of overall architectural considerations, over time the architecture will likely suffer…which hinders the organization’s ability to build working and useful software in the future.

    I’m glad you brought the enterprise architecture dimension into the agile discussion. Great post!

  • Pingback: Scaled Agile Framework (SAFe) Considerations — CIO Dashboard()