receives compensation from some of the companies listed on this page. Advertising Disclosure


Too Big to Be Agile? Not With the Scaled Agile Framework

Tim Sorweid

Learn How to Implement and Scale Your Agile Development Efforts

If you have been considering the benefits of leveraging Agile Methodologies in your organization, you might have some question as to what is too big for success.

The answer is an emphatic, nothing is too big. However, there are some important pre-requisites that you must have in place before you embark on an enterprise transition.

Not every organization can adjust to the mandates of Agile and frankly there are some types of work that don’t lend themselves to this style of team engagement.

But if you developing application systems and software products in a large enterprise the Scaled Agile Framework (SAFe) is for you.

While Agile is usually applied as a software development methodology, it can be used for just about any type of work whether preparing customer communications, or implementing new business processes.

The big hurdles to successful enterprise agile center around corporate culture and change, maintaining an architectural roadmap for both tech and business, managing dependencies and insuring completeness and quality.

Related Article: From IoT to Wearables: The 3 Technology Trends You Need to Watch in 2016

Here are a few areas that should be explored when determining if Agile is a fit for your company, large or small, the steps to success, tools, process and the challenges you will likely see when trying to go big. Regardless of the type of product you are delivering you must:

  • Have the business engaged the whole way. It’s a partnership.
  • You must tailor your agile process to the culture, but shed wasteful ways and thinking, keep the good and throw out the bad.
  • Engage certified agile coaches to help teams through the learning curve. You need an Agile Center of Excellence and a Community of Practice to shepherd the organization through this big mind shift.
  • If Agile doesn’t fit a particular type of work, don’t force it. Square pegs in round holes are painful for everyone.
  • Agree up front on the right level of process, tooling, automation and ceremony to make your process go smoothly. Then agree that these processes must and will change. Measure your success, and remember agile is all about course correction, iteration and retrospective. Learn to fail fast and you can harden or soften your style as you go.
  • Determine how you will manage dependencies where some teams may be agile and some may not, especially in the early stages of an agile roll-out. There are industry standard processes and tools to help with this. If you have a large enterprise then you will need the Scaled Agile Framework (SAFe), or a similar structure.
  • Architecture is still relevant. Enough said.
  • Automate everything you can such as build, deployment, testing and release. The more you automate the smaller your teams and the documentation of yesterday is now in code.

“If the discipline of requirements specification has taught us anything, it is that well-specified requirements are as formal as code and can act as executable tests of that code.” ― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship


Agile has been around for a long time. Influenced heavily by lean methodologies practiced by Toyota Motor Corporation. That’s the waste part.  Small organizations are, by nature, agile. Their small scale doesn’t require wasteful processes in coordinating a large workforce, and communications is much easier to accomplish.

The Agile part, and there have been many models like XP and SCRUM, is about organizing around the business to deliver product, in our case software, in small increments that have has all eyes on during a two to four-week cycle (sprint).  

The Old

One of the main drivers of a waterfall methodology is that organizations will manage a date for delivery, with requirements collection taking a larger part of the project. The business is engaged to some extent as BSAs work with, hopefully, the right people and then deliver requirements (lots of documentation) to the delivery teams.

If something is missed or miscommunicated too bad, you won’t find it until the delivery teams are well along in testing. The cycle is long, and requirements are likely to change by the time software is delivered, an endless cycle of catch-up and miscommunication.

“A programmer’s wife tells him: go to store. pick up a loaf of bread. If they have eggs, get a dozen. The programmer returns with 12 loaves.”

Related Article:Is Silicon Valley Still the World's Top Technology Hub?

The New

Pilot a few delivery teams collecting the requirements for a sprint’s worth of work; this is called grooming (minor documentation). Your product owner is right there with the team and can clarify the stories as needed as the developers build the small increment of product. The product owner is also empowered to make decision right on the spot.

No big meetings to run decisions up to senior management only to wait three weeks for an answer. This is typically a huge cultural change. As your pilot teams show success expand the practice and, eventually, the enterprise will become agile. You’ll need a framework that brings all of these teams together; something like SAFe where architectural runway meets the release train and feature teams meet horizontal component teams and agile ceremony reigns.

This is how dependencies are managed and it’s all defined right here at SAFe and vendors like CA Technologies (Formerly Rally) have developed complete tool sets around this framework that embrace the spirit of SAFe.

Business and Technical Architectural Roadmap

There is still, and always be a debated about the relevance of architecture in an agile world. That may be true for smaller organizations, but when dealing with an enterprise some semblance of standardization in infrastructure, software tools and application design approached must be maintained.

Without it, agile team would run riot with many flavors of the same wheel driving cost right over the edge. In parallel some business vision must keep everything on the rails to and ultimate business goal. A business capability roadmap still need to influence what gets implemented and the priority of the build

The Old

Ivory Tower architecture used to rule the day, where massive strategies are formed to align the enterprise in a particular technical or business direction. Roadmaps extend one, two, sometimes three years as the organization embarks on a waterfall approach to implementing a standard architecture, marching to the goal, but never getting there as it all changes after the next reorg or technology revolution.

The New

SAFe brings incremental architecture into the picture. An architectural runway that influences how things are built as the release train progresses. This is known as incremental architecture and it does have some ivory tower research in its DNA, but it was done in an agile manner with technical POCs being tested along the way.

In the meantime, business has done some of the same type of work testing innovative capabilities in small agile efforts. These come together to influence the backlog of local, divisional or enterprise release trains usually consistent of seven to eight sprints (12 to 16 weeks). Got it wrong? You only wasted three months of effort, not two years. Fail fast.

Dependencies, DevOps, Tools and Automation

Finally practicing SAFe, finding the right tools to support agile project management, and continuous delivery are critical to bringing it all together. To make Agile, well, agile, you need great tools to make things quick and easy. No more spreadsheets, PowerPoint decks, status reports, broken builds and waiting three weeks for network to configure a firewall.

Related Article: 5 Technology Trends That Have The Power to Change Your Business

The Old

Requirements in spreadsheets, armies of offshore testers, staging infrastructure (better get it right the first time), lots of business system analysts, lots of developers, lots of project managers, three year projects…the list goes on and on. And while this may bring a nostalgic warmth, it’s expensive and painful.

The New

Tools for Agile management, story grooming, prioritization, automated builds, artifact sharing, test automation, defect tracking and cloud formation all joined together to enable small, high performing delivery teams delivering incremental product that is business certified. What’s not to like?

For large enterprises, practicing Agile is a definite possibility, and in fact, recommended. The market for sophisticated tooling has matured extensively over the past several years and there are many success stories for those who have considered a measured and rational approach to implementation.

With SAFe, many organizations will notice they already have one to one mappings with many tenants of SAFe and, with some minor adjustments, fit right into the model.

Image Credit: Monkeybusinessimages / Getty Images
Tim Sorweid Staff
I’ve been in software development for the last decade and have personally witnessed a shift in the way development teams interact with their customers & product managers. Gone are the days of 6-month planned waterfall software development cycles which are now replaced with iterative and feature driven agile engineering. As ScrumMaster for, I am the evangelist for Agile Scrum software development throughout the company and have our engineering teams embarked on an endless journey of seeking out the perfect 2-week development sprint cycle.