“By and large people have a handle on team-level agile,” said Lee Cunningham, director of enterprise agile at VersionOne. “The next frontier is really how do we take what works really well at the team level in terms of quality, in terms of throughput, in terms of the morale of the people; how do we get that in and have that permeate our entire enterprise?”

Organizations who have implemented agile at the team level have experienced improved time to market, more predictability in costs and timelines, better ability to engage users, and high retentions of developers, and now they want to see those benefits work for the entire business, according to Andrey Akselrod, cofounder and CTO of Smartling. “Speed and quality of product development is a significant competitive advantage. Enterprises can no longer avoid being agile if they want to survive very competitive markets and very tech-savvy competitors,” he said.

According to Cunningham, although departments such as HR, finance, marketing and sales may not have the same work as the software development department, agile can still help with their daily workflows. “They are really dealing with the same things that your software organization is dealing with,” he said.

“They have more work than they can possibly do in the time they are given, things are changing, and the things that they are being asked to do are often ambiguous. They need to have some systematic way to think about their work.”

(Related: Testing needs to catch up with agile)

But scaling agile beyond the team level is a lot harder than it is implementing it into one department. According to Christine Hudson, solutions manager at Rally (a CA Technologies company), it needs everyone in the entire organization to be involved and on board, and requires a lot of time, money and resources. Organizations may shy away from the approach because of the complexity, but Hudson believes the benefits are worth the risks.

“The benefits of agile at scale are beyond exceptional, and the costs of standing still greatly outweigh the costs of adoption,” she said.

Are you ready to scale agile?
If you want to scale agile, you have to have agile to scale in the first place, according to VersionOne’s Cunningham. He believes it is essential for an organization to have success at the team level before it can move beyond that.

“An organization has to first understand how agile works on a small scale, because the way I look at scaling agile is really taking those principles, those things that work at the team level, and just figuring out how to make them work on a larger scale,” he said.

In addition, since enterprise-level agile requires participation from everyone in the organization, everyone needs to embrace it, and achieving that executive support and participation is required. Executive support will help solidify that movement to agile is the right move, according to Cunningham.

“It is not only about an understanding of the agile principles and mechanics, but also the extent to which there is a demonstrative willingness to embrace it and to undergo the necessary organizational change,” he said. “Those two things are really good at indicating the extent the organization is not only ready to embark on something, but also [are] a leading indicator on how successful they might be.”

Another good way to measure how the company’s current business strategy is performing can simply be by answering these questions: “How does work flow to your teams? How far into the future do you plan? Do you include people from outside IT or engineering in your planning? What happens if the world changes after you plan?” said Rally’s Hudson. “And finally, you should ask yourself if you can afford not to adopt agile practices across your organization. Are your current methods for working keeping up with the rate of change and disruption influencing you?”

The answers to these questions can help gauge where the company is at right now, but perhaps one of the most important question an organization should ask themselves is “Do you want to keep your business alive in the 21st century? If so, then you’re ready for agile,” Hudson added.

Although Larry Maccherone, director of analytics and research for AgileCraft, argues that an organization is never really ready. “You’ll likely never be as ready as you wish you were,” he said. “The best course is to decide that you are going to do it, and then essentially do what you need to do to get ready.”

Maccherone adds that more and more organizations are seeing success with “big bang” agile transformations. A big bang agile approach consists of taking a leap and rolling out the deployment all at once, rather than the recommended small start into scaling.
“You would likely need expert help to take this approach, but it does offer the quickest path to reaping the benefits of scaled agile,” he said.

Prerequisites for agile
While Maccherone doesn’t think organizations will ever be completely prepared to scale agile, there are some basic principles and practices that can make the transition smoother.
According to Maccherone, there is a critical stepping stone organizations should use. “The first critical step is to orient around the product or service that you provide rather than the activities that the various workers perform,” he said. To achieve this, organizations should change their periodic planning activities, and eliminate organization obstacles to product or service orientation, according to Maccherone.

“If the testers, analysts, UX and Ops folks all think of themselves as working for their functional manager rather than on an agile team that is focused on a product initiative, you’ll never accomplish that first critical step,” he said.

Since agile is based on the idea of collaboration, communication is key and is not something that organizations can overlook when scaling their agile efforts, according to Baruch Sadogursky, developer advocate at JFrog.

“Agile is all about the communication and getting feedback. In order to get rapid feedback, team members and stakeholders need to be able to talk to each other to explain the work, what needs to be done, and what has already been completed,” he said.
If communication channels are not in place, then driving the agile message across the organization is going to be problematic, Sadogursky added. “Organizations need to put more efforts to make the communication channels open in order to maintain the flow of information,” he said.

Having a disconnected information flow is often the source of failed rollouts at scale, according to Steve Elliott, CEO and founder of AgileCraft. “Without a scaled agile platform in place to provide transparency from top to bottom and side to side—or said another way, without transparency from enterprise to portfolio to program to team—it is almost impossible to see progress and target coaching across the enterprise. It’s also difficult to measure the impact of the transformation or the value of the work being done during this phase,” he said.

Organizations should also make sure they are open to an agile mindset, according to Rally’s Hudson. “You need to be prepared to question the efficacy of your standard operating procedures,” she said. “And you need a willingness to inspect, adapt and improve as you go.”
Other organizational and development process changes that need to be in place before scaling include moving from a centralized command-and-control system to a decentralized system, according to Smartling’s Akselrod. A decentralized system can help teams become more in tune with their product.

“On the development side, processes like Continuous Integration, log monitoring, fully automated testing, and push-button deployment must be in place to make technology teams truly agile,” he said.

Finally, organizations need to realize that if they are going to embark on an agile transformation, the transformation will never be completed. According to Hudson, an organization will never be 100% agile because there is always going to be ways they can improve.

“The minute you’re complacent is the minute your competitors begin to close the gap,” she said. “That said, each iteration of the transformation is finished. You bite off small chunks, implement a step toward the desired change, finish, and evaluate it—then look at the results so you can determine the next right step to implement. The goals of enterprise-scale agile aren’t just predictability, performance improvements, quality improvements, and increasing customer happiness; you also need to strive to continuously improve.”

While the task can never be completed, JFrog’s Sadogursky does note that there is a point where organizations can say they are doing it correctly. “Converting or adopting agile is a process. It is not a task that can be completed,” he said. “We can definitely get to some point when we say what we are doing is correct, but it is a very long process and includes joining the new organization all the time, and making the communication channels better.”

If an organization decides to scale agile, they should expect a constant state of learning and improving from that point on, AgileCraft’s Maccherone added. “The entire concept of agile is about trying something out, and then improving based upon feedback from the real world.”

Major roadblocks standing in the way
Changing the thinking and workflow of an entire organization is difficult, and requires a lot of time, resources and money. Organizations want all the benefits of scaled agile, but not the costs that comes with it. Those costs are a major obstacle standing in the way of an organization’s path toward success, according to Smartling’s Akselrod.

“It takes time and money that you have to spend on the toolset, hiring a DevOps team, implementing all the software and practices enabling agile,” he said.

Akselrod justifies the costs by believing it is an investment that is worthwhile, and is a matter of spending the money or losing your business. “It really comes down to a very simple equation: Adopt agile or be destroyed by your competition. It is as simple as that,” he said.

In order to make the costs worthwhile, organizations need to have expectations set properly, which will help determine their readiness to move forward and guide them in terms of those expectations, according to VersionOne’s Cunningham. “The last thing that you want to happen is for a company to make a big investment in coaching, training and tooling, only to become disillusioned a few months down the road.”

In addition to investments, organizations need to remember that agile is a culture shift. Concentrating on the tools and process too much, and forgetting about how this is going to impact employees is usually what fails in a transition to agile, according to JFrog’s Sadogursky. “When organizations just blindly use the tools that were recommended by some agile book without actually explaining what they are trying to achieve and what are the end goals, that is 100% a recipe for failure,” he said. Driving the message about what’s really important—and deemphasizing what’s less important—will help the employees better understand the path they are on, he added.

“Agility requires a willingness to adapt at enterprise scale, and it takes courage to re-architect a whole business system for speed, steering, and opportunity capture,” said Rally’s Hudson.

Sadogursky also believes organizations who want to take that big bang approach will fail because it is easier to start small and then scale from there. “A more granular or step-by-step approach is more successful, because when you start with smaller teams, you can actually explain what they are trying to do, [and] you can monitor the process and get feedback,” he said.

VersionOne’s Cunningham went on to explain that an organization first needs to understand how fast they can absorb change before jumping too quickly into anything. “You are not only transforming the way people think about work, or do their work,” he said.

In the end, agile will help an organization be more responsive, more in tune with customers and competitors, and do things much more efficiently with less waste and less defects.

“You may have heard the quote that ‘Culture eats strategy for breakfast.’ Well, execution eats strategy for breakfast, lunch and dinner.” said Maccherone. “Agility means being able to change your strategy to fit your most recent understanding of the market.”

Choosing a methodology
There are many flavors of agile: lean, Kanban, Scrum, and custom-made ones organizations build from their previous methodologies. According to said Lee Cunningham, director of enterprise agile at VersionOne, there is no wrong approach; organizations just have to decide what works best for them.

“Even at the high level of the organization, they may be borrowing some practices from XP, some from Scrum and blending them and kind of putting them together in a method that works well for them,” he said.

Agile refers to methodologies built on iterative development. Focuses on collaboration and cross-functional teams.

Kanban aims to provide continuous collaboration, visualization, limited amount of work in progress, and ongoing learning.

Lean focuses on delivering value to customers, eliminating waste, and providing fast delivery cycles, rapid feedback, and continuous learning.

Scrum is a lightweight framework that focuses on short iterations and team collaboration for quickly solving complex problems.

XP, also known as Extreme Programming, is designed for communication, feedback, simplicity, small releases, simple design, pair programming, test-driven development, refactoring, collective code ownership, and sustainable pace.

Cunningham also notes that while organizations will take different approaches, a high-level approach should have more lean workflows and principles in place. “Lean agile is really more than having visibility into the workflow, limiting the work to the actual capacity, and forcing prioritization and decision-making up the line,” he said. “It also helps the enterprise as a whole have a really better feel on where they need to make investment, where they need to allocate or periodically reallocate people.”

Top reasons agile transformations fail
Every organization will have their own unique failures and success, but according to Larry Maccherone, director of analytics and research for AgileCraft, there are seven recurring themes in agile failures. They include:
1. Lack of executive commitment
2. Overly expensive or ineffective planning, alignment and steering activities
3. Inability to get a real-time single source of truth for resource management, value planning and progress reporting
4. Organizational structure obstacles to orienting around the product or service you provide rather than the activities of the users
5. Mid-level and functional managers failing to let go of their prior control and accept a new role
6. Lack of team-level agility
7. Failure to plan out and acquire the necessary training and resources to accomplish the transformation