Enterprise organizations are beginning to buy in to Agile techniques outside of their development teams, to gain companywide benefits from being Agile. Enterprises require scale, and with that scale comes process.
A big question remains left unanswered: How do you ensure that future Agile teams have “agility” and can collaborate and deliver value, instead of just “doing Agile?” How can you allow teams to continue to respond to change while still working within the parameters of large organizations? Ultimately, how do you help teams deliver value over blindly following the Agile process?
SD Times reached out to Suzie Prince, head of products for ThoughtWorks. Prince leads product development for Mingle, GoCD and Snap CI. We talked with her about how organizations can help their teams remain true to agility and deliver value as they scale Agile—without following a one-size-fits-all process.
SD Times: What should be the measure of success for Agile scaling?
Prince: There’s a lot of discussion about doing Agile vs. being Agile. The measure of success is not the label; it’s delivering the right thing at the right time.
There is no right level of agility that is the same for every organization. For some organizations, agility only goes so far as it is needed for software delivery, while others may need to implement a holistic, organization-wide change to achieve enterprise agility. It is important to remain focused on what is needed to bring the most value to an organization above all else.
A good way to assess the agility needed for a particular organization is to understand the level with which a business must become adaptive to achieve its goals. One way to do this, as described by Jim Highsmith, is to determine whether your organization is striving for responsiveness (agility) or efficiency. Organizations can—and do—care about both responsiveness and efficiency, but understanding which one prevails as the top priority may help you understand the extent with which agility needs to extend in your organization.
What are the different approaches for scaling Agile?
Among [ThoughtWorks’ project management software] Mingle’s customers and the companies I consulted for, I’ve experienced top-down and bottom-up approaches, and mixed top-bottom. Top-down Agile scaling is common, in which one Agile framework is selected for all teams and rolled out. Bottom-up Agile scaling is where individual teams are enabled and coached to be Agile, and they work out their own goals, processes and mechanisms to achieve the goals. There is a third approach: mixed top-bottom. There are also organizations that use a mixed approach and tailor it to fix their organizational goal.
What are the pros and cons of a top-down approach?
The top-down approach is convenient, understandable, well explained and (in some cases) it’s all that’s needed for a particular business. If your organization’s goals are to streamline delivery and allow for releases every three months vs. every year, a cookie-cutter framework may well bring success (and if it does, you should celebrate!).