After witnessing the success of agile software development teams, people in the agile community began to wonder whether the concept could be scaled to large organisations that develop enterprise solutions. After all, what organisation would not want to be more agile?
But large organisations aren’t designed to be nimble. As much as everybody celebrates disruptive entrepreneurship, being big has its rewards. Large organisations do a lot of interesting work, and there are real advantages to their size, scale, and deliberation. Most of these organisations focus on steady incremental improvements. The challenge is to help such organisations reap the benefits of agile without losing the benefits of being big.
Enter, enterprise agility. As agile software development was hitting its stride around 2007, the agile community started talking about how to put fast-moving agile teams into larger, more established organisations by “scaling agile.” Two early books on the topic were Scaling Software Agility: Best Practices for Large Enterprises by Dean Leffingwell (2007) and Scaling Lean & Agile Development: Thinking and Organisational Tools for Large-Scale Scrum by Craig Larman and Bas Vodde (2008). At about the same time, Scott Ambler had introduced his Agile Unified Process, but he has since stopped working on it to work on Disciplined Agile Delivery (DAD).
However, the notion of scaling was never accurate. Scaling an agile team would turn the team into a lumbering hippopotamus instead of an agile cheetah. A more effective and realistic solution is to find the sweet spot between fast-moving teams and the slow, deliberate enterprise. At the same time organisations were looking to become more agile, the role of enterprise software in an organisation’s success was growing, so large organisations needed their software development teams to become more agile. Yet, they needed a buffer zone between agile and the rest of the enterprise.
Enterprise agile transformations created a whole new genre of articles, books, and consultants. In a few short years, the number of people who changed their LinkedIn profile to “agile coach” went from hundreds to tens of thousands as the demand for experts who could help large enterprises navigate their transformation to enterprise agility soared. Many of the authors of these scaling agile ideas started to create their own enterprise agile frameworks. These frameworks proliferated like diet and exercise programs, and large organisations couldn’t get enough of these pre-packaged solutions.
These frameworks were so enticing that by 2016 nearly half of all enterprise agile transformations were using (or actively considering) an enterprise agile framework. Just a little over a quarter were considering building their own. The little over a half that was using an enterprise agile framework generally settled for one of the top five frameworks: Scaled Agile Framework® (SAFe®), Large- Scale Scrum (LeSS), Disciplined Agile Delivery (DAD), the Spotify Engineering Culture, or Kanban and Lean.
Even when organisations try to build their own enterprise agile frameworks, they often rely on one of these pre-packaged frameworks as a template. So, while there is no standard enterprise agile framework, a consensus is forming around a standard set of ideas.
9 Reasons Enterprise Agile Transformations Fail
Every organisation that succeeds in transforming into an agile enterprise does so in a unique way. Organisations that fail often do so for similar reasons. By knowing the most common reasons for failure, you have a better chance of avoiding disaster.
1. The organisation’s culture clashes with agile values
Many organisations have a disconnect between what they are and what they’d like to be. They may see themselves as nimble, high-tech companies when in reality they have a strong command-and-control culture. Having a strong control culture is fine. In fact, large organisations with well-established functional areas often do very well.
However, organisations often struggle to implement big changes when they overlook their control culture as a challenge to overcome. They don’t have any interest in changing their core values; they want agile to “fit in.”
An enterprise agile transformation is a radical organisational change. While you may be able to retain the corporate hierarchy, that hierarchy must give its agile teams more power to innovate and develop solutions.
2. Teams aren’t interested in making changes
Many teams just don’t have much incentive to change. Trust may be lacking for several reasons, including the following:
- The organisation has a strong competence culture. Team members are reluctant to share knowledge because their competence gives them greater authority in the organisation.
- Management treats employees like “warm bodies,” instead of treating them with respect.
- The organisation suffers from a lot of turnovers, so employees aren’t around long enough to build a culture of mutual respect and trust.
- The organisation has a lot of contract workers on its development teams. They have no incentive to change the way they work, because they know that as soon as their contracts expire, they’ll be moving on.
Prior to embarking on an enterprise agile transformation, make sure you have at least a few long-term employees to anchor your teams and an organisation-wide commitment to create a culture of mutual respect and trust.
3. Executive support is lacking
Executives and managers typically delegate the enterprise agile transformation to directors and team managers and get updates during quarterly meetings.
Unfortunately, acknowledging the change is not the same as supporting it. Leadership usually believes that the organisation will continue to operate the way it always has, just a little better.
You want your executives to be fully involved in many of the details of the change. Remember that enterprise agility is a radical organizational change. It’s much different from how most organizations currently deliver products. Work hard to try to frame it that way to help keep your executives involved in the process. If you can’t change your executives’ expectations, then the changes you implement will be very vulnerable the first time executives get something different from what they’re used to seeing.
You actually want your managers and executives to be a little uncomfortable with the change. Their discomfort shows that they understand the scope of the transformation.
4. The proposed change is too radical
Transforming an entire organisation into an agile enterprise is a major undertaking. Before you start, evaluate your organisation’s track record for implementing change. If your organisation has a poor record for making big changes, you may want to take a more gradual approach. Instead of aiming for a home run, just try to get on base.
If you doubt your organisation’s ability to undergo a major transformation, you can still improve your organization’s agility by making small changes, such as the following:
- Use Kanban and Lean to reduce waste, optimize workflow, and nudge your organisation in the direction of adopting a more Lean-Agile Mindset.
- Try forming one or two agile teams to handle a product or a system within the organisation where you think an agile team could offer some value.
- Start a Lean-Agile Center of Excellence to encourage people in your organisation to start thinking about an agile transformation and to support them in their efforts to implement changes.
- Break one or more functional areas into small self-organised, cross-functional teams and build slowly on their success.
5. The customer won’t cooperate
An enterprise agile transformation changes not only how your organisation delivers value to customers, but also how your customers are involved in the process. Some customers may be reluctant to change.. Just as you need to sell your organisation on the benefits of agile, you may need to sell your customers on the concept of agile product development.
Until your customers are on board, avoid embarking on your enterprise agile transformation. Without close collaboration with your customers, you’re likely to struggle with your enterprise agile transformation. You’ll end up with agile teams being handed a list of product requirements, and you’ll get very little benefit from your enterprise agile transformation.
6. Leadership refuses to invest in training
One easy way to tell whether your organisation is invested in making a large- scale change is to look at leadership’s commitment to training. If your managers balk at the cost of training, they’re likely to neglect other key elements, such as coaching, workspace design, and the expenses involved in greater face-to-face communication.
Training is key to a successful enterprise agile transformation. As more people in your organisation are trained and begin to adopt the Lean-Agile Mindset,
everyone begins to see the tangible benefits, which motivates both leadership and employees to invest more in the transformation.
7. The developers insist on requirements
Some software developers enter the profession because they like the idea of quietly solving problems in their own workspace. They may not like the idea of working in close collaboration with the customer. They may not even like the idea of working closely with other developers. This is especially the case if they’ve been able to work from home for years on their own special corner of the product. Bringing these people into the office and getting them to collaborate can be a difficult transition.
If you have a developer who’s not interested in collaboration, then work hard to change that person’s perspective and see the value in closer teamwork. If that’s not possible, then work to get him off your team. As Netflix CEO Reed Hastings said, “Do not tolerate brilliant jerks. The cost of teamwork is too high.”
Each team wants to do its own thing
Some organisations have agile teams long before they embark on their enterprise agile transformation. Often the teams develop independently of one another. Having an eclectic collection of modified agile teams is one way to begin an enterprise agile transformation, but such an approach can actually slow down product delivery. To conduct an effective enterprise agile transformation, some teams may need to unlearn what they’ve been doing in order to adopt a more uniform approach.
If you have a mix of agile team practices throughout the organisation, you can get all your teams on the same page by providing uniform agile training:
- Provide the same agile training to all teams.
- Break up existing teams and form new teams. Keep in mind that newly formed (or re-formed) teams require time to adjust and achieve a new performing equilibrium. Team stability (the “stable teams” pattern) is widely regarded as a major precondition for higher-performing teams.
- Spread team members across different training sessions to further reduce the risk of confirmation bias and to minimize the impact of training sessions on the teams’ daily work.
8. Nobody has a plan to measure improvements
Prior to embarking on your enterprise agile transformation, you should have metrics in place to measure progress and a system in place for gathering and analyzing relevant data. Otherwise, your organisation may have no way of knowing whether the transformation is having the desired results.
If you decide to use your own system, first figure out how you’re going to measure enterprise agility success and the type of data you need to collect, such as the following:
- Customer satisfaction
- Team output
- Workflow optimization
- Waste reduction
- Number of defects/bugs
What’s more difficult to measure are overall process improvement and team collaboration. You can give your team questionnaires, but the results may not provide an accurate assessment. After all, with questionnaires, team members are grading their own progress.
9. The functional areas are too deeply entrenched
When functional areas, such as analysis, coding, and testing, are deeply entrenched, team members may struggle to transition to cross-functional teams even after they’ve received cross-training. Many team members have trouble accepting the cross-functional approach as a legitimate way to work. They’re accustomed to the traditional model: “When you finish your task, I start my task.” They need to make a conscious effort to change their mindset; otherwise, they just fall back to that way of working. What often happens is that mini silos form within a team with each team member focusing on certain tasks.
Where possible, co-locate the cross-functional team members, so they aren’t living in a functional “camp” based on their primary technical expertise. Within a team, try various approaches to “pairing” and “swarming” around work items in progress, to get people more used to collaborative development.
If you have any questions you can mail us at [email protected]
