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.
Understand why you’re implementing Agile
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:
- You need to deliver unpredictable work because requirements for your teams change often, at short notice, or both.
- You want to shorten feedback loops between your teams and customers to reduce mismatches between what you create and what your customer needs.
- You believe good ideas come from people close to the customer rather than from more distant and senior managers and executives.
- ️ You see a lot of waste in your company in the form of bureaucracy and overhead, and you’re looking for ways to streamline work.
- Your current approach to planning and execution doesn’t bring the expected results, often signalled by projects or products that take forever to complete.
- You’ve seen one or more teams initiate Agile practices, and their results have inspired you and others in the organization.
An overview of the different Agile frameworks and when they’re useful from this Parabol resource.
Create an Agile transformation roadmap (in 5 steps)
One CEO explained their Agile implementation to consultancy McKinsey by saying:
“We are 3,000 people on a giant cruise ship. But what we need to be is 3,000 people in a few hundred yachts. So, how do I get my people safely into those smaller boats?”
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.
1. ⛑️ Get the right help in place
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:
“You generally want the coaching to stop. The whole thing you’re doing is making yourself redundant because that means you’ve created a self-sufficient team.”
2. Pick the right approach
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:
“‘To be more Agile’ isn’t really a valid goal. Do they want improved customer engagement? Or more effective teamwork? Or more predictability? It could be a whole range of things.”
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:
“[You will] frequently end up with a long list of things that are outside the scope of the team’s ability to change, that are actually management issues. So, you learn a great deal from retrospectives.”
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.
3. ✅ Get “final boss” commitment and define new metrics
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:
“In today’s world, customers can vote with their feet and walk away from your business in seconds. Utilization rates and schedules cannot prevent that… We talk about Net Promoter Score and how happy our customers are.”
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.
4. Start small and let Agile spread
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:
“Big bang agile rollouts are much more likely to fail. It’s best to start with something simple like Scrum and Kanban on a few teams and then to scale up through experimentation.”
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:
- Prioritize the list of issues you identified during your exploratory retrospectives with Agile implementation stakeholders.
- Pick the team or teams that are most enthusiastic about trying agile or have the most pressing needs that agile can solve.
- Provide some basic training to the first couple of teams.
- Start your first Sprint or another type of work cycle if you’re not using Scrum.
- Hold a retrospective after your Sprint and keep repeating this cycle of Sprints followed by a sprint review and sprint retrospective.
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.
5. Reflect, iterate, repeat
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.
Agile implementation challenges to prepare for
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:
- Bosses worry about losing their power or jobs.
- ️ Teams lack the motivation to change their way of working.
- ⛔ Stakeholders pull out when there’s no urgency to change the status quo.
- ️ Consultants are tied to their tools and processes, not your success.
- IT systems and processes need a complete makeover.
Bosses worry about losing their power or jobs
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:
- Help teams work through problems so they can find their own solutions.
- Remove significant obstacles that the teams themselves can’t.
- Identify the right Agile metrics that empower and motivate teams while giving higher-level managers the information they need.
️ Teams lack the motivation to change their way of working
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:
“It is really about the ability to pass challenges to the right person quickly and effectively. You don’t want it to take three weeks to come back with a solution.”
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.
⛔ Stakeholders pull out when there’s no urgency to change the status quo
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.
“Most organizations would probably go bankrupt before seriously changing the way they’re structured. You’re asking managers to change their roles, and responsibilities, and authority, and they’re not going to do that unless there’s a strong commitment from high up… When they really change is when they’ve got themselves into serious trouble”, says Agile Coach Murray Robinson.
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.
️ Consultants are tied to their tools and processes, not your success
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:
“I’ve worked with a couple of the big telcos here in Scandinavia, and they have bought the Spotify model from certain big consultancy houses… You get this super slick, nice playbook, 130 slides, and everything explained… But, they’re very different from a company called Spotify that has existed for, what is it? Maybe 15, 20 years, and a telephone company that’s existed for 100 or 135 years… It will clash in certain ways.”
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.
IT systems and processes need a complete makeover
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.
“[That team] had to test it. They then had to release it, and eventually, it made it live… The development teams had the capability to release software every two Sprints. But the release didn’t go live for another two Sprints after that.”
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.
You need to go all-in on Agile
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.
In a bureaucracy, serving the internal systems and processes takes precedence over serving customers… In Agile organizations, everyone in the organization has a clear line of sight to the ultimate customer or user and can see how work is adding value to that customer or user—or not.
Stephen Denning – Agile’s Ten Implementation Challenges
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.