Are you one of the many executives with a sense of certainty about your readiness to do Agile? What about at scale? If you find yourself willing to rely on stellar results from a few standalone Agile projects as a guide, you might need to think twice. While 98% of Agile projects succeed, the truth is that Agile pilot projects alone don’t necessarily prepare you to expand the benefits of agile ways of working to meaningful scale.
First, Agile projects often focus success on speed of delivery. Attention concentrates on the way people inside cross-functional teams develop software by adopting sometimes narrow applications of the Agile ways of working. The special nature of the Agile ways of working is nurtured. For instance, Scrum Masters frequently stand as team member’s protectors, keeping them isolated from the rest of the organization as they produce proof that Agile works.
Yet, Agile team dynamics impact work beyond the team—touchpoints between legal, compliance, suppliers, and security, among others become more frequent and urgent. Organizations’ established protocols for handling legal queries, managing compliance with regulatory agencies, and adjusting funding or scope to projects rarely match well with Agile ways of working. To propel an Agile project to success, sponsors remove organizational impediments, and people asked to support Agile teams bend their own rules. These common techniques may seem familiar: the sponsor gets an Agile team’s code through the pipeline faster; a charismatic team member persuades a compliance officer to review the team’s solution early as a favor; or the product owner makes a deal with a vendor to deliver supplies in more frequent increments than called for in an existing SOW.
It’s these favors granted to Agile teams that impede expanding the success of one Agile project to multiple projects and teams. Special favors don’t scale. Instead of creating special circumstances to buoy the carefully nurtured teams in an Agile project, organizations should treat the need for favors as early indicators of systemic changes required for scale. At scale, development teams will need to be tightly coordinated both upstream and downstream. Relations with resourcing, funding, and compliance will need to be tightly aligned with development as will relations with the security team, quality assurance, operations, and marketing. An Agile pilot designed to begin changing existing protocols with both upstream and downstream stakeholders can establish a scalable method for organizations to test and learn how to expand Agile ways of working beyond development teams—throughout their entire culture.
Agile at scale can change an entire organization’s culture and design. Existing frameworks for scaling—SAFe, LeSS, DAD, and others—lure many with recipes to handle organizational changes beyond individual Agile teams. While these frameworks are effective for some, there is no perfect recipe for agility. “[A] set of tools or practices that works well in one context might not be equally effective for a major competitor,” according to the MIT Sloan Management Review’s report A New Approach to Design Work about the dynamic nature of developing business agility.
A New Approach to Design Work noted that “Best practices are ‘best’ when they manifest an underlying behavior principle in a way that is well matched to the organization that uses them.” Organizations need a method to figure out what type of recipe works best for them: ready-made or homemade.
One method for anticipating scale is to run side-by-side projects. Why? Dual projects can focus on getting the Agile team dynamics right while also providing enough pre-scale pressure to give corporate functions, vendors, and other projects or teams whose work intersects with the Agile pilot teams a chance to test new protocols and learn what’s needed to support Agile ways of working in a relatively contained manner. One effective method is to pilot agile in different team and product settings, such as having one team focused on a brownfield product and one on a greenfield product. These tests build confidence among business leaders that changes can be rolled out across the enterprise because they track both changes inside teams and impacts teams make on the rest of the organization. Smart pilots plow new decision-making channels that help leaders come together in new ways and sow the seeds of organizational change. By the end of the smart pilot, the organization will have a protocol to continue testing and learning how to adapt to Agile ways of working throughout their organization, with next steps customized to address their most important challenges.
For more information on how to drive Agile transformation more effectively in your organization, check out our thought leadership pieces on Agile’s Five Hidden Amplifiers and Agile Change.
First, Agile projects often focus success on speed of delivery. Attention concentrates on the way people inside cross-functional teams develop software by adopting sometimes narrow applications of the Agile ways of working. The special nature of the Agile ways of working is nurtured. For instance, Scrum Masters frequently stand as team member’s protectors, keeping them isolated from the rest of the organization as they produce proof that Agile works.
Yet, Agile team dynamics impact work beyond the team—touchpoints between legal, compliance, suppliers, and security, among others become more frequent and urgent. Organizations’ established protocols for handling legal queries, managing compliance with regulatory agencies, and adjusting funding or scope to projects rarely match well with Agile ways of working. To propel an Agile project to success, sponsors remove organizational impediments, and people asked to support Agile teams bend their own rules. These common techniques may seem familiar: the sponsor gets an Agile team’s code through the pipeline faster; a charismatic team member persuades a compliance officer to review the team’s solution early as a favor; or the product owner makes a deal with a vendor to deliver supplies in more frequent increments than called for in an existing SOW.
It’s these favors granted to Agile teams that impede expanding the success of one Agile project to multiple projects and teams. Special favors don’t scale. Instead of creating special circumstances to buoy the carefully nurtured teams in an Agile project, organizations should treat the need for favors as early indicators of systemic changes required for scale. At scale, development teams will need to be tightly coordinated both upstream and downstream. Relations with resourcing, funding, and compliance will need to be tightly aligned with development as will relations with the security team, quality assurance, operations, and marketing. An Agile pilot designed to begin changing existing protocols with both upstream and downstream stakeholders can establish a scalable method for organizations to test and learn how to expand Agile ways of working beyond development teams—throughout their entire culture.
Agile at scale can change an entire organization’s culture and design. Existing frameworks for scaling—SAFe, LeSS, DAD, and others—lure many with recipes to handle organizational changes beyond individual Agile teams. While these frameworks are effective for some, there is no perfect recipe for agility. “[A] set of tools or practices that works well in one context might not be equally effective for a major competitor,” according to the MIT Sloan Management Review’s report A New Approach to Design Work about the dynamic nature of developing business agility.
A New Approach to Design Work noted that “Best practices are ‘best’ when they manifest an underlying behavior principle in a way that is well matched to the organization that uses them.” Organizations need a method to figure out what type of recipe works best for them: ready-made or homemade.
One method for anticipating scale is to run side-by-side projects. Why? Dual projects can focus on getting the Agile team dynamics right while also providing enough pre-scale pressure to give corporate functions, vendors, and other projects or teams whose work intersects with the Agile pilot teams a chance to test new protocols and learn what’s needed to support Agile ways of working in a relatively contained manner. One effective method is to pilot agile in different team and product settings, such as having one team focused on a brownfield product and one on a greenfield product. These tests build confidence among business leaders that changes can be rolled out across the enterprise because they track both changes inside teams and impacts teams make on the rest of the organization. Smart pilots plow new decision-making channels that help leaders come together in new ways and sow the seeds of organizational change. By the end of the smart pilot, the organization will have a protocol to continue testing and learning how to adapt to Agile ways of working throughout their organization, with next steps customized to address their most important challenges.
For more information on how to drive Agile transformation more effectively in your organization, check out our thought leadership pieces on Agile’s Five Hidden Amplifiers and Agile Change.