In the current software development parlance, "agile" has become synonymous with innovation and speed. But many organizations limit their agile approaches to one or two siloed departments out of a mistaken belief that they're too big, too 'legacy,' too process-oriented to scale the approach across the larger business.

That's just not true, says Jennifer Jaffe, vice president of product and marketing at Jama Software. You -- yes, you -- can reconcile the benefits of agile development with other enterprise functions and scale the approach to benefit your entire enterprise.

Most large enterprises want to adapt to an agile mindset to establish more insight and transparency into their operations; they've seen it work with one or two small development teams and want to extrapolate that success across the business, says Jaffe. But that's admittedly easier said than done.

"There is a lot of unease around agile because it tends to operate in a Black Box. As a result, many business managers view agile developers as a rogue team and approach it with a heavy dose of skepticism. However, if these teams could show their progress and demonstrate how it accrues to the overall vision for the project, more managers and business leaders would be on board," says Jaffe.

To establish that transparency, you have to first address some common misconceptions about agile and make sure the entirety of the business is on board with the shift and is using the same language and nomenclature for IT projects.

Find the right size

"There's a key misconception -- agile isn't anti-documentation or anti-process, which is what many large organizations fear. Agile is about right-sizing process and right-sizing documentation to make the business as nimble and responsive as possible," Jaffe says.

Twenty-one year old digital asset management solutions firm Extensis didn't have the luxury of starting out as an agile shop, and decided to make an organization-wide transition about 18 months ago, says Toby Martin, Director of product development at Extensis.

"Most firms of our size and age, like us, were waterfall shops. We wanted to get more nimble and agile with our releases -- and do them more often than five or six times a year -- and get our new products to market faster. The best way to do this is to spend less time in the waterfall planning stage. With waterfall, someone comes down from the 'executive mountain' with this stone tablet and tells you everything you're going to do for the next two years … except what if you figure out in month 4 that you're on the wrong track? Then you're stuck for the next 20 months!" says Martin.

Start small

Extensis decided the best way to get their entire organization on board and up to speed on the strategic shift was to hire an agile trainer and coach to establish a framework for the transition, educate the workforce and get company-wide buy-in, according to Martin. Then, Extensis began the transition by having a single development team start with the new methodology with the intention of eventually transitioning their other two development teams.

Once that team was up to speed and comfortable, Martin says, there was room for experimentation and adapting agile to better fit the unique needs of Extensis. "We felt like, we're making this huge shift, so at first we wanted to start small and follow the directions of the coach and the trainer to the letter. Then, once we had the agile mindset, the processes, the tools and the language down, we could look at how to tweak that for our own individual teams. That's the great thing about agile -- it makes you nimble, but in and of itself it's also very flexible and you have many different variations to fit your business," Martin says.

Break it down

Another crucial part of scaling agile is demonstrating how individual projects impact the larger business strategy, and breaking down each project into the same sprints the agile teams are using.

"It works best if you can draw correlations between the business' financial and business goals and the work your teams are doing daily. Start with an annual plan and then break that down, piece by piece -- you want to increase revenue by X? You want to reduce overhead costs by Y? You want to, say, boost the number of hosted users by a factor of 2? Here's how the product drives that goal. Here's each step in that process, which becomes your agile roadmap," says Jaffe, "Once that's in place, you can designate what goals are set and achieved each quarter, each month, each two-week sprint."

"Agile lets you retain the larger context in which all the other work resides. All the executives upstream and all the developers downstream are looking at the exact same map, so it all lines up with what each group is dealing with. That way you can say, 'OK, this is step 1 of our 70-step plan to increase revenue by X! We're on our way!" Jaffe says. To do that effectively across an entire organization requires a shared architecture and extensive communication and collaboration, which isn't without its issues.