Agile has evolved quite a bit in the last two decades, offering a proven way to drive performance and gain a competitive advantage. It hit the world in three waves: team agility, scaling agility, and business agility.
In the second part of our Q&A with Agile Coach Josh Fruit, we asked Josh about scaling Agile (read part one: Achieving More With Agile). Josh is a Managing Director at Accenture and the North America Customer Lead for the Business Agility practice. Throughout his 20-year career in technology, he has delivered solutions and fostered agility in startups, SMBs, local and state government agencies, and the F500. In the last 9 years, Josh has consulted for the world’s largest global enterprises helping them on their journey to business agility. He is a sought-after leader for architecting large scale transformations, taking a pragmatic approach to scaling agile, and helping senior leaders navigate the transformation journey.
Q: How should an organization go about scaling Agile?
Organizations seeking to scale agile should do so as deliberately and minimally as possible. Approach scaling frameworks as a collection of patterns and practices, some of which will be relevant and useful and others less so. Adopt the patterns and practices that are fit for purpose and as you learn by doing adapt them to your organization’s context and culture. Align on success measures up front and measure for the intended benefits from scaling and agility. Finally, set a vision and path for the organization to descale over time.
That said, I prefer to start first with the question of whether you should seek to scale Agile in your organization.
Before delving into how to scale successfully, as an alternative consider if you can reduce organizational and technological complexity, remove dependencies between teams and systems, and build small, empowered, customer-centric teams who can move from idea to market as independently and fast as possible.
Admittedly, that can sound like nirvana for non-digital native companies. Such organizations are typically facing complex legacy technology landscapes with tightly coupled architectures. There can be hundreds to thousands of cross-system capabilities and application dependencies that few to none in the entire company can fully explain. Often, many teams are required to work in close alignment across a multitude of systems, applications, and tech stacks to produce something of value to the end user. In my experience, the answer for these companies in the short-term is not to continue working in waterfall, but to find an Agile scaling solution that works for their needs, tailor it appropriately, and over the long-term work towards reducing complexity and “de-scaling.”
If you believe scaling might be the best answer for you, then for starters I would offer the following for consideration as you approach it:
- Start With Leadership: It is critical that leadership across business and technology are educated on agile and scaling. This should include executives through management. There will be change to people, process, taxonomy, architecture, tooling and more brought on by the scaling journey. Like all transformative change leadership at every level is necessary for success.
- Plan Appropriately for the Investment: Take the time to learn about scaling and plan accordingly with clear goals and success measures in mind. This will help you begin to identify what practices to utilize, what practices you may want to minimize or avoid, and what will need to be true to advance beyond scaling to achieve greater business agility. Working with seasoned experts will shorten this cycle some, but all learning ultimately comes through doing. There is only so much you can anticipate in planning such organizational change, so start small with a pilot, learn from it, and then carry to successive waves of the organization over time.
- Be Prepared to Overcome Challenges: One of the more common pitfalls in scaling I have observed is adopting the surface level nomenclature and coordination practices across teams but completely missing the heart and benefits of Agile. In such cases, organizations are often still following big-design-up-front, big-bang-integration at the end, and outdated technical practices rather than XP and DevOps. Team members are still quite disconnected from a clear business vision, measurable outcomes, and the voice of the customer. And teams often sprint for many months to more than a year before they deliver anything to market. On the surface, it can appear such organizations are following agile at scale with new roles, language, and big, multi-team planning events for instance. But, the results of speed to value, improved quality, and more are not realized, and people grow weary, cynical, and disillusioned. Agile itself is often blamed as the culprit.
In the end, regardless of your chosen methods and frameworks, clarify your vision, goals, and success measures for agility, and continually assess whether you are achieving them. Implementing a scaling framework is not the goal; better business outcomes with happier employees and delighted customers is.
Stay tuned for part three of our discussion to read what’s next for Agile and the role of business agility.