Many companies in the early stages of agile development often focus their efforts on pockets of opportunity within existing business lines, or new areas in which they hope to gain early leadership. That often leads to early wins and excitement, but scaling up to address the enterprise at large may seem elusive.
Agile development is often initiated as a pilot project with a small team, to test out new methodologies and tools aimed at bringing new products and services to market faster. Typically, success will lead to implementation across one or more small portions of the business. But translating that to broader business agility is not automatic, particularly in larger businesses where scalability is essential and strategic goals may rely on managing and coordinating multiple teams across business units. In such situations, top executives need insight into the broader portfolio effort that is under way.
“Agile delivery has hit a tipping point, with the majority of IT organizations finding some level of agile success,” writes Scrum.org CEO Dave West. “For these organizations, the next logical step is to scale this success into an ‘enterprise adoption,’ taking the value they are getting from a single team and replicating it. This is often where it all starts to go wrong. Enterprise agile adoption is a large endeavor requiring changes to many processes and systems and adoption of new tools.”
Moving from smaller, relatively self-contained areas of opportunity to forming “teams of teams” across organizational lines requires a greater level of effort and a broader strategic focus. Part of the difficulty in scaling up is in replicating cultural change, supported by the right tools, across the organization. Scaling agile requires tools that can scale as organizations grow, offering the essential transparency and visibility across all work across teams. As many businesses have learned, there are many barriers that must be crossed to make agile development a success.
A research paper by a team at New Zealand’s Eastern Institute of Technology concludes that software companies trying to make the transition to agile have encountered “general organizational resistance to change, lack of user/customer availability, pre-existing rigid framework, not enough personnel with agile experience, concerns about loss of management control, concerns about lack of upfront planning, insufficient management support, concerns about the ability to scale agile, need for development team support, and the perceived time and cost to make the transition.”
Transitioning from small to large outcomes
Many organizations started their agile efforts by isolating a group of developers from the traditional organization and processes. Figuring how to foster multiple entities and get them all working together may seem paradoxical.
Mike Perrow of TechBeacon Learn observes that “taking agile principles and methods up a notch to company-wide software development plans requires additional planning and coordination, to say the least. Those who are grounded in agile methods may wonder: ‘More planning? The whole point of agile is to reduce requirements gathering and managing and get on with the production of working code!’”
Small group dynamics don’t always easily translate to larger groups, or across multiple teams. Not all agile teams are created equally and not all people work the same way. And not all agile teams follow the same process, guidelines, or frameworks. A 2017 survey by Gateway Research found that 75% of primarily senior decision makers indicate they want to move toward business agility in some way, but only 39% say they are confidently on their way. More than a third are either working on a plan but not sure how to get started, or still in the discussion phase.
Businesses must recognize that an organization in which only a few teams have incorporated agility isn’t realizing the benefits of business agility. Agile must extend beyond the IT, project management, and service and support teams to achieve transformational outcomes and sustainable business value.