Many large-scale Agile Transformations are struggling. Some have failed. Others can’t figure out why things aren’t working after multiple attempts. It’s easy to blame the people, the process, and the culture. It’s especially easy to blame management. However, the underlying problem is that most large organizations weren’t built to be Agile.
Organizational Barriers to Agile
Many organizations that adopt Agile operate with hindrances present. These dependencies don’t necessarily limit an organization’s ability to “do Agile;” however, these barriers negatively impact an organization’s ability to achieve Agility. Here are a few of the most common dependencies that organizations encounter:
- Individuals Spread Across Multiple Teams
- A Lack of Instantly Available Resources
- Too Much Work-in-Progress
- Limited Access to SMEs
- Shared Requirements Between Teams
- Technical Debt and Defects
- Low Cohesion and Tight Coupling
- Large Products with Diverse Technology
Enterprises that don’t address these barriers, whether due to ignorance of the presence of these dependencies or a present refusal or inability to do so won’t achieve the level of Agility that they seek.
Overcoming these impediments requires an intentional, realistic inward look at an organization’s functionality. An Agile Transformation will naturally break or otherwise limit these dependencies when conducted effectively.
Beginning Your Agile Journey
To begin an Agile Transformation, we must first recognize what exactly we’re transforming within the organization. Many suggest that Systems, Agile Practices, and—stop me if you’ve heard this one before—Culture are the keys to a successful Transformation. If we can believe this, where should we start our Journey to ensure that we are attaining the better business outcomes and delivery system that Agility provides?
While Culture, Agile Practices, and supporting Systems are all integral and must be present to achieve a successful Agile Transformation, it is of equal importance where you begin.
Many organizations begin their Agile journey by prioritizing a culture shift. This can manifest in a few familiar ways—CSM workshops, collaborative office spaces, rearranged desks, and motivational posters come to mind. Prioritizing this kind of cognitive shift is usually founded in the reasoning that if our people’s individual hearts and minds change, a new delivery system will emerge. Undeniably, if everyone bought into Agile adoption, if everyone just “got it,” complete Agile Transformation would be a much simpler process.
This idyllic outcome may be a plausible reality for a company with thirty-five enthusiastic employees. However, structural barriers exist that hinder Agility for large-scale enterprises. While an adherence to the values and principles of Agility promotes Transformation, a mere state of mind is an inadequate foundation for successful Transformation.
After completing a successful Agile pilot, many organizations overlay standard Scrum roles, artifacts, and ceremonies across the remainder of the organization in hopes that these practices will take root. They operate under the assumption that going through the motions of Agile enables them to overcome structural dependencies and foster a culture that supports Agile Transformation.
But while daily standups, sprint planning, and burndown charts give the appearance of Agility, these activities have become conflated with the benefits of Agility. While Scrum practices are integral to an Agile Transformation, these practices won’t yield better business outcomes if the underlying systems of an organization don’t provide a suitable environment where Agile practices can thrive. For this reason, many organizations that “do Agile” won’t get the benefits of Agile they sought at the onset.
While we recognize the importance of Culture and Practices, we’ve learned that a functional system that supports Agile practices must be established first, then the cultural shift will naturally follow over time.
Teams Level – The 3 Things
Once we understand what we’re Transforming in the organization, we must establish a firm foundation to build the System on. This foundation consists of the 3 fundamental mainstays of an Agile Transformation–or The 3 Things–Forming Teams, Building Backlogs, and Producing Working, Tested Software.
An Agile team should consist of everything and everyone necessary to deliver—6 to 8 people dedicated to producing a working, tested increment of the product. These teams need to be cross-functional and decoupled to prevent dependencies.
Building teams in this manner not only prevents dependencies that hinder Agility, but also provides accountability to the team, ensuring that teams are able to make and meet commitments.
For many organizations, backlogs have become a series of thematic items that the product owner would like to build—frequently spanning multiple sprints and keeping the team from producing tangible increments of working, tested software. Alternatively, a backlog may appear as minor engineering activities.
A backlog must be functional and be built in a way that gives the teams clarity around what they are building and how what they are building fits into the bigger picture.
Producing Working, Tested Software
Developing a working, tested increment of a product at the end of each designated period is the ultimate goal of adopting Agile.
“The 3 Things” at Scale
Once we have established the foundation for our Agile Journey at the Teams Level, we need to scale those fundamentals across the remainder of the organization. The 3 Things at scale take the form of Structure, Governance, and Metrics.
Structure is the expression of teams at scale. We strive for collaborative participation at all levels of the organization. A vertical slice of the organization including Portfolio, Program, and Delivery teams align around value streams, products, or business capabilities. This regulatory structure ensures that the encapsulated slice has everything they need to deliver value to the organization.
Governance is the expression of backlog at scale. Practically, Governance describes the way we manage the flow of work, prioritize decisions, and make economic tradeoffs in the face of uncertainty. The Portfolio Team plans and provides the strategic business outcomes in the form of epics. The Program Team then decomposes the epics into features and further negotiates with the Delivery teams on prioritization. Many associate this Governance structure with a Waterfall methodology; however, we can apply this in an Agile way that ensures that the work being completed at the lowest level is strategically aligned around the things the organization actually cares about.
Metrics and Tools are the expressions of working, tested software at scale. This entails the ways that we measure how an organization is delivering value not only at the team level but across the entire organization. These metrics look differently at each tier of an organization. For example, Delivery Teams focus on Backlog Size, Velocity, and Escaped Defects, whereas Program Teams are concerned with Cycle Time and Features Blocked. Meanwhile, the Portfolio Teams prioritize Takt Time, ROI, and Time/Cost/Scope/Value. These metrics allow all levels of the organization to maintain strategic alignment and ensure that we’re focusing on work that’s valuable to the business.
Agile fails in many large enterprises due to their operating within a broken system that’s full of dependencies. To overcome this, an organization must build a functional System founded on the fundamentals of an Agile Transformation: Forming Teams, Building Backlogs, and Producing Working, Tested Software. With this foundation firmly set, we become able to scale these fundamentals to the remainder of the organization, dismantling or diminishing dependencies along the way. It is then that Agile Practices may take hold, and an Agile-centric Culture may then follow.