You have to give it to Silicon Valley: it sure knows how to disrupt industries. It has left its mark on every facet of our life—from how we socialize and interact, to how we travel, how we earn, and how we pay. The scale of impact has led to traditional companies in the ecosystem asking themselves, How do we get our large organizations to adapt and move as quickly as these nimble start-ups? The answer in many cases has to do with being more agile.
Stay current on your favorite topics
Agile principles have been one of the key drivers of Silicon Valley’s ability to innovate, learn, and adapt rapidly. Agile started as a set of principles for software development to write and release code iteratively without waiting for months (or years) to release functionality. The term “agile” has now expanded to many facets of solution development with the same underlying principles—develop iteratively, release frequently, focus on the customer, and collaborate through a cross-functional team—always prioritizing test-and-learn methods over detailed planning. Beyond solution development, we are designing and implementing enterprise-wide operating models based on these principles.
While many traditional heavyweights have embarked on agile transformations, most have faced real challenges in achieving their desired objectives. Based on our experience across numerous transformations, we see the following as common missteps on an agile journey.
Misstep 1: Not having alignment on the aspiration and value of an agile transformation
Agile, fundamentally, is a redesign of the operating model of (parts of) the enterprise. We have often seen organizations embark on such transformations without first ensuring alignment among the leaders of the organization on the aspiration and value of the transformation. Further, even when there is such alignment, we often see companies that, in the spirit of adopting some agile principles—such as experimentation and empowered teams—end up creating a burning platform, as different leaders across the organization choose different approaches to implementing agile, while others dig in their heels to maintain the status quo.
While we don’t encourage attempts to design an end state in granular detail, the depth and breadth of an agile transformation requires aligning at a high level on the aspiration, the value it would deliver, and a plausible plan for achieving it. The identified value drivers are then used throughout the transformation, from guiding the design of the operating model to ensure value delivery, to designing metrics to monitor value capture during rollout. Not doing so can constrain the impact the transformation might have.
For example, a large global company initiated a bottom-up agile transformation without first aligning on the end-state aspiration and the value the transformation would create. The transformation ended up having limited impact, as teams in different parts of the organization applied agile principles to varying degrees and in multiple flavors, which led to a significant increase in the overhead of managing across teams. Further, the lack of alignment on the value of the transformation meant that teams spent little time thinking through and tracking the value their efforts would deliver.
Misstep 2: Not treating agile as a strategic priority that goes beyond pilots
Too often, companies find themselves limiting agile to pilots within a small part of the organization, with a small set of leaders. While the pilot is typically successful, its impact is restricted to a few teams or a bunch of technologists. The limited nature of the pilot often prevents the CEO and executive team from grasping the far-reaching impact and strategic value a broader agile transformation could have. Companies often end up carrying a series of such pilots, before they’re eventually killed once the need to reallocate funding for new initiatives arises.
While it is completely OK to start the agile transformation within, say, a small part of the organization, it is important not to stop there and to treat it as a strategic priority for the enterprise. Taking agile beyond small experiments is where the real benefits arise. For example, a large North American company was trying to implement agile in its technology organization, which encompassed 1,000-plus people. Every time business executives were asked about agile, they had a limited understanding and simply referred to it as “that project the technology team is trying to implement—we know nothing about it.” The impact was limited, until 18 months into execution, when a massive change came about because one of the senior vice presidents started to take interest, understand, adopt, and make changes to his business practices to match the more agile technology organization. This led to an enterprise-wide transformation, with agile being identified as one of the top five enterprise priorities.
Misstep 3: Not putting culture first over everything else
Words cannot emphasize the cultural implications of an agile transformation. Ignoring the cultural and change-management implications of agile is one of the biggest mistakes large organizations make. Successful transformations require not only bottom-up change in the way of working at the team level but also a change in the way the executive level operates, as this has a disproportionate influence on the culture of the organization. “Culture is the king,” as a senior executive appropriately said when referring to the recipe for success for an agile transformation. Conversely, an agile transformation can help drive significant cultural changes where desired, helping increase customer centricity, collaboration, learning, and more. These gains often require giving up some preexisting ways of working. A senior executive who has led multiple agile transformation puts it aptly: “The first question I ask leaders considering an agile transformation is, ‘How much are you willing to give up?’”
For example, a large North American company had embarked on an ambitious agile transformation and hired several agile coaches to support teams. However, leadership in one of the businesses continued to work within the paradigms of the old culture: they were hesitant to empower teams, wanted detailed designs of the end product, and asked for project-management-office-style status reports on a weekly basis. Within the same organization, leadership in another business took a completely different approach and worked on changing the culture. Leaders empowered product owners and minimized bureaucracy. After one year of effort, the former business had little progress to show for any of its projects, whereas the latter had released multiple minimum viable products.
Would you like to learn more about our People & Organizational Performance Practice?
Misstep 4: Not investing in the talents of your people
One of the things that has made Silicon Valley start-ups successful has been their emphasis on finding and hiring the best talent. That talent is the fuel that powers the agile machine. This allows companies like Amazon to create truly cross-functional, empowered teams, with high-caliber, experienced talent embedded in them.
For many traditional organizations, talent strategy is an afterthought of an agile transformation. In the process, some crucial questions that merit careful consideration, such as the following, remain unanswered:
- What are the intrinsic skills required to be successful in the agile organization?
- Where will talented individuals with these intrinsics be sourced from?
- How will these employees be supported as they transition to an agile way of working?
- How will career paths change to a more expertise-based model?
- How will performance be managed in the new organization?
- What will happen to individuals who might not be required in the new agile organization?
The result: lack of excitement about taking on the new agile roles or joining agile teams due to lack of clarity on the career path, leading to teams that still require senior leadership to be deeply involved in decision making. For example, a midsize global company wanted to emphasize customer centricity as part of the agile organization. To achieve the goal, the client wanted to create a “design function” from zero people to more than 25 designers in various roles across multiple customer journeys. Such an endeavor required an up-front talent and recruiting strategy, diligent follow-up and interviews, and a careful scale-up approach to attract talent and excite them about the role and career opportunities. Because of a lack of detailed planning through these steps, seven months through the agile transformation, the client had not only struggled to recruit new designers to the function but also faced attrition among existing designers because of a lack of role clarity and excitement. This led to a significant amount of leadership time being spent on solving for these challenges. A similar situation occurred with a European company, where 11 out of 12 product owners in the first tribe set up as part of the transformation left for their old roles as they lacked coaching for transitioning to their new roles.
Misstep 5: Not thinking through the pace and strategy for scaling up beyond pilots
It is one thing to pilot agile in small pockets of an organization, where one can deploy resources from across the enterprise to support the pilot and make it successful. However, scaling across a broad cross-section is another story and requires up-front planning. One must think through the readiness of the organization, resourcing constraints, leadership bandwidth, and consequently the pace of the transformation, among other things. These plans need to be adjusted based on learnings through implementation.
For example, a midsize global company had planned its agile transformation around five waves. However, it had not spent enough time thinking through the scale of leadership bandwidth that would be required and the effort that would go into recruiting for the new agile organization. After completing the first two waves, the company was forced to reconsider the pace of its agile transformation and extended it to seven waves.
The five trademarks of agile organizations
Misstep 6: Not having a stable backbone to support agile
Too often, agile is taken as an approach to managing projects. It is important to recognize that for teams to operate using agile methodology requires changes to core management processes and the supporting tools that a team has access to, among other things.
For example, iterative development also requires iterative funding. This is a concept that is hard to grasp for many traditional businesses. A large North American company wanted detailed estimates of every project with respect to investment required and benefits expected when the project was complete. While initial and early estimates are beneficial, a dogmatic approach made product owners panic, led teams to fight over hypothetical financials, and caused massive enterprise-wide confusion.
Agile teams also require the ability to deploy technology assets rapidly. For example, a large North American company required around six to eight weeks to provision environments, which meant that the team had to spend considerable time planning to compensate for the time lag.
Absent these changes to core management processes, teams may find it hard to execute rapidly, which hampers innovation, increases time to market, and so on.
Misstep 7: Not infusing experimentation and iteration into the DNA of the organization
If you ask practitioners about the traits of an agile organization, you’re likely to hear most of them mention iterative development. While this comes naturally to a start-up, which doesn’t have an established product and needs to test and learn to develop one, it is more complex to grasp for an organization that has not one but many product lines that have a reputation of excellence in the market. This also applies beyond product development—consider how your organization prepares, for example, business strategies, recommendations to the leadership team, and product-launch strategies. All too often effort is wasted by teams operating in a vacuum, second guessing what stakeholders might want to see, or perfectly executing the wrong plan rather than engaging stakeholders throughout the process to get input regularly and ensure the team is focused on what really matters.
Another aspect that often limits experimentation is the rigid application of scaled agile frameworks. Too often, companies end up shifting the focus of an agile transformation away from minimizing processes and changing mind-sets and behaviors to enable innovation, toward putting in place the right framework. While frameworks can be valuable in providing structure to the transformation, it is important not to be rigid in their adoption, and to always think of how they can be adapted to suit the needs of the organization. After all, one of the pillars of the original agile manifesto was to favor “individuals and interactions over processes and tools.”
For example, while a North American company embraced iterative agile development in theory, management stuck to a rigid framework it had developed that required high-fidelity mock-ups of the end product and detailed business plans before product development had even commenced. An agile organization would have done just enough to get a version of the product out to market quickly and gather feedback from customers to guide future developments, seeking input from the real end users of the product. This rigid application of the framework ended up limiting the impact of the agile transformation.
There are undoubtedly many other examples of missteps that have derailed agile transformations. In our experience, these missteps are largely preventable but too often result in agile being written off. Becoming armed with the right level of understanding for how to drive an agile transformation, and respecting the complexity of such a transformation, is a first step toward a successful journey—and based on the impact we have seen with companies that have undergone successful agile transformations, a very worthwhile investment to make.
