How to Make Your Agile Transformation a Success

Traditional organizations and managers follow a command-and-control approach. Power and direction trickle from the top down, as “big leaders appoint little leaders” and people work in a system that’s designed for them to “be quiet, take orders, and do their jobs in a repetitive way.”

Agile gets rid of this command-and-control approach for managing projects, teams, or entire organizations. Instead, it prioritizes self-managing teams and puts a focus on delivering value to customers early and often.

The road to that new way of working is an Agile transformation. But before embarking on an agile journey, you might want to consider why you’d want to make it and what it involves.

Many teams and organizations want to “go Agile” for the wrong reasons. A middle manager thinks Scrum – the most popular Agile framework – is a shortcut to making programmers work faster. A startup team has heard Agile leads to egalitarian heaven without processes, deadlines, or bosses. And a corporate executive gets sold on Agile by one of the “Big Four” consultancy firms.

None of these are valid enough reasons to start implementing one of the many flavors of Agile available to you.

But an Agile implementation might be for you if:

An overview of the different Agile frameworks and when they’re useful from this Parabol resource.

One CEO explained their Agile implementation to consultancy McKinsey by saying:

Your Agile implementation journey is about transforming your organization from one that operates a cruise ship to one that is more like a fleet of sailboats.

The analogy is apt for another reason. Because Agile implementations are about transforming people’s mindsets and learning new ways of working and collaborating (e.g. how to sail many small boats instead of steering one big one). It’s much less about specific tools and processes, like which boat to buy.

The following steps are designed to help you build a roadmap to change how your teams work, collaborate, and organize themselves.

Unless you’re doing a small implementation and have prior experience with Agile, you’ll probably need help. Usually, such assistance takes the form of at least one Agile coach that supports the team and their managers through an agile transformation. Larger organizations will need multiple coaches or even a consultancy. Larger companies may also find it helpful to visit other companies that have done Agile implementations to learn from their experiences.

⚠️ Beware of coaches who stick around forever. Agile teams need to become self-managed, so, as Agile coach Rebecca Sassine put it:

There are many Agile approaches. To pick the right one, you first need a detailed understanding of all the outcomes you want to achieve from an Agile implementation. As Agile coach Chris Wolff said:

You can use retrospective meetings to help you pick the right approach. This agile meeting type helps uncover learnings from the past to improve the future, at all levels of the company, drilling down from the top and up from the bottom. Think about what’s working with your current processes and where you’re stuck. Then discuss as a team or a board what elements of your work you need to fix.

By running retrospectives with people from across an organization, Agile Coach Murray Robinson says that:

Parabol streamlines retrospectives for teams and allows you to do them remotely and asynchronously.

Ultimately, your goal is not to pick the perfect Agile approach (there is no such thing) but to find the most suitable one to get started. You’ll want to consider your retrospective learnings, team size, company culture, management style, and any existing agile practices people are already familiar with.

Often, Scrum is the easiest way for teams to get started, because it gives plenty of structure to work. But you’ll no doubt evolve into or pick elements from other agile approaches over time.

For more details on different agile frameworks and picking the most suitable for your situation, check out our complete overview of Agile frameworks.

An Agile implementation needs support from a company’s “final boss” for two reasons.

First, as Agile spreads through the organization, it will challenge traditional values and processes. Suppose folks at the top don’t understand or support the full implications of Agile. In that case, they can wield their power to kill your Agile implementation or refuse to help you overcome resistance at lower levels.

A second, more subtle challenge for your Agile implementation is when the end boss keeps asking direct reports for metrics that don’t fit the new way of working. Questions like “What’s your utilization rate?” or “Are you on schedule?” have little to do with Agile’s relentless focus on iterative development and delivering customer value. Chris Wolff says:

These challenges are more relevant at larger organizations than with small teams, but they still play a role at a smaller scale too. You can’t truly implement Agile even at a small startup if the founder or CEO isn’t on board with it.

If you’re thinking “I’m just a manager in a developer team. How can I possible get buy-in from our CEO?”, here’s a fantastic resource that might help.

While consensus on many topics is hard to come by in the Agile community, there is consensus on how to start an Agile implementation. It has to be small. Agile Coach Murray Robinson says:

When done right, Agile will start spreading organically, as other non-agile teams notice the improved speed and performance of the agile teams and want to get involved.

After all, Agile is about making small incremental changes, testing them, and iterating. So starting small and testing how it works is in itself an agile approach!

Here are some steps to help you start small with a couple of teams:

When doing a small Agile implementation, you can hold one retrospective with the team and stakeholders looking back over how the experience with Agile is going so far and finding improvements.

At large organizations, you might have team retrospectives focused on how the Sprint went for each team and a separate “Agile implementation” retrospective to look at the progress and learnings of the overall implementation itself.

The key is that both large and small implementations rely on teams reflecting on progress, identifying what’s working and what’s not, and then debugging and improving any issues.

Agile processes are iterative by nature and geared towards continuous improvement. That means you can use Agile to implement Agile. Start with a two-week Sprint and reflect on what works and what doesn’t about your new processes. Then make changes accordingly for the next Sprint so it’s better. Next Sprint, observe how things feel and reflect on that improved Sprint to see what else needs fine-tuning.

Initially, you’re probably best off following the Agile approach you’ve picked to the letter. If that’s Scrum, there are very clear agile meetings and processes to follow. After a few Sprints, when you’ve mastered how to work with your framework you can start making small changes to suit your needs better. Eventually, you’ll end up with an approach that’s completely tailored to your context and can’t be categorized in a specific Agile box anymore.

When you follow an Agile framework like Scrum, you’ll naturally keep improving and evolving your approach as you go through each cycle.

A natural direction for Agile – especially in larger organizations – is to organize teams around so-called value streams instead of traditional job functions, where all marketers are in one team, programmers in another, and so on. When you organize for value streams, you look at the different products and services you deliver to your customers.

Each of those is a value stream, and you then start to organize teams around that stream, pulling in the people who can help deliver that value to the customer. This often makes agile teams multi-disciplinary with designers, marketers, and developers working side by side in a single team.

One Agile framework, the Spotify Model, is especially useful for structuring larger organizations around value streams. You can read more about it in our complete overview of Agile frameworks. 

Organizational change is hard. Two of every three change initiatives fail, according to Harvard Business Review. Launching an Agile transformation is arguably even harder. You might face a range of formidable agile implementation challenges:

Traditionally, managers create things like metrics, budgets, projects, career paths, and goals for their departments. Now, because of your Agile implementation, they need to delegate their authority down to teams, so they become *self-managed. *What role does that leave managers?

With the help of an Agile coach, managers can evolve their roles to resemble one of a coach rather than a traditional boss. They should unlearn giving orders and making decisions for the team. Instead, managers should start asking questions and throwing out challenges, through which they can:

Teams often resist an Agile implementation when it’s pushed from the top, and they don’t understand why it’s helpful for them. Or, they fear – often rightly so – that things will fundamentally stay the same, and “agile” is just another thing they need to learn.

When teams aren’t keen to adopt Agile, you’ll need to demonstrate the benefits for them in practice. That begins with building trust by showing they’re truly going to be self-managed, and experimentation and failure are ok. And you’ll need to make sure impediments thrown up by other, non-Agile parts of the organization get resolved quickly. Chris Wolff says:

For teams that don’t want to change their ways of working, Agile’s promise of fewer meetings combined with plenty of time protected for deep work are powerful selling points that you can and should communicate.

While getting started might seem relatively easy, implementing Agile will involve setbacks and time. In larger organizations like Microsoft, an agile transformation might take years. Throughout such a journey, there’s a real chance key stakeholders get cold feet, pull out, and return to their traditional way of managing the company.

The status quo can hinder your Agile implementation when key stakeholders do not see results fast enough. You can address this by managing expectations on the required timeline at the start of your journey. When implementing an entirely new way of working, things are initially going to feel worse before they feel better. So be prepared for that.

The clearest sign of progress might be at your Sprint Review or Sprint Demo meeting. Invite stakeholders along so they can see a working product increment every Sprint, rather than what they’re used to – a big product reveal after a quarter, six months, or even a year of working.

Bringing in the right Agile coach or consultant for your organization can be tricky. Often, they have mastered or productized one particular approach, and, surprise, surprise, that’s the Agile flavor they’ll recommend, whether it fits you or not.

Agile Coach Jonas Lidman says:

To counter this problem, get references for the coaches or consultancies you’re thinking of working with. Check their track records to see if they’re constantly peddling a specific approach or use frameworks as a bag of tools to prepare a customized Agile solution for each client.

Agile teams need to deliver working product updates to customers often to receive feedback quickly and regularly. Sometimes – especially in larger organizations – quick and frequent releases are impossible because of incompatible IT processes or equipment.

Chris Wolff recalls one organization he worked with where the development teams had to send their work to a separate team.

To counter such delays, releasing software should not fall under a separate (IT) department but become a skill and responsibility within each team. Such a structure is in the spirit of Agile, as teams need to be cross-functional and stay in close proximity to the work they do. So instead of a conveyor belt, you have a multi-disciplinary and self-sufficient team unit.

If releasing software is part of what’s necessary to get frequent updates to customers, it should also be part of the team’s capabilities.

If you want to experience all the benefits of going Agile, then you need to go all in. But many companies make only 25% of their teams Agile (usually just software engineering teams) while the rest stick to a command-and-control approach.

While agile teams might go faster in this scenario, they may still be slowed down or struggle to put customer value first once they need approval, a legal review, or design from a team that’s not Agile.

Implementing Agile is a journey of continuous improvement and iteration that, when done well, touches and changes everything in an organization – its goals, values, systems, processes, people, and even outside partners. The ultimate purpose? To generate as much value as possible for customers and eliminate anything that doesn’t.

Getting to such a state takes commitment, determination, patience, and, above all, the courage of those leading the change to experiment and iterate continuously. As you push through the changes and experiments necessary, take along the mantra “ask for forgiveness, not permission” from leaders and other stakeholders who get cold feet as you boldly chart a path forward on your agile journey.