Agile transformation: Roadmap, challenges, and frameworks

Businesses everywhere have undergone a massive transformation. What worked in the past doesn’t work anymore — at least, not fast enough.

To help guide you through your agile transformation journey, we will:

• Look at examples of companies that achieved noteworthy success by embracing agile values
• Explore what it means to have an agile mindset
• Walk through a five-step roadmap for implementing agile ways of working on your team and, over time, throughout your organization

Embracing the agile mindset

Agile isn’t a process that bears fruit overnight; it’s a mindset, and it often runs counter to how companies are used to operating.

The key to successfully implementing agile methodologies is getting comfortable with the unknown and accelerating learning. It’s not about having a process to speed up output.

In 2002, the Agile Manifesto was born, leading to a rash of agile transformations. The values and principles described therein are still highly relevant. The four Agile Manifesto values are:

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

In a nutshell, Agile is about getting things done instead of endlessly talking about how to progress.

Agile transformation examples

Startups constantly emerge and disrupt traditional businesses. For example, Airbnb and Booking.com transformed how people find accommodations. Uber disrupted how to get from point A to point B, and Spotify revolutionized how we listen to music. You could also talk about Paypal, LinkedIn, Netflix — the list goes on and on.

How did these companies reach exponential growth in such a short time? The answer isn’t straightforward, but it comes down to how they work. Instead of taking traditional business approaches that focus on processes and risk avoidance, they strived to experiment and learn as fast as possible.

These companies are all agile, but they don’t claim to be agile per se. If you read books like No Rules Rules, That Will Never Work, and Working Backwards, curiously, you won’t find the word agile or any mention of agile frameworks. That’s because these companies were born agile.

Traditional companies must catch up or risk getting disrupted. For organizations that weren’t “born agile,” undergoing an agile transformation is no longer optional but critical to remain in the game.

Of course, nothing worth doing is ever easy.

Common antipatterns

Becoming agile is a journey that might take years, but high rewards will make the efforts worthwhile.

One of the most common mistakes companies make early on is using agile frameworks with a fixed mindset. This invariably leads to watered-down results. Unfortunately, that’s what most companies do anyway.

Neither scrum, nor Kanban, nor Shape Up, nor any other agile framework can make a company agile on its own. These frameworks create room for valuable collaboration, but you need to develop a growth mindset first.

The following techniques will not help you get closer to agility:

• Velocity sets an output mindset and strongly connects to predictability and project management
• Burndown charts create pressure to deliver the output and micromanages team members instead of empowering them
• Story points lead to many abstract conversations instead of getting hands-on and learn from experience
• Definitions of ready hinder collaboration by requiring upfront work from a small group of people

I’ve used these techniques for years and felt trapped but didn’t know why. Once we ditched them, I felt free to fly, and the result was more value delivered to businesses and end users.

By forgoing velocity as a key success metric, we simplified our sprint planning because we no longer invested time into abstract conversations. Instead, we clarified the goal and committed to it.

When we first removed the burndown chart, I noticed the team discussing opportunities to reach the sprint goal in more detail.

Then came the use of story points for velocity estimation. We realized that we were better off without it because our energy went into understanding problems instead of shooting numbers.

Finally, by removing the definitions of ready, our collaboration improved. Instead of complaining about what was missing regarding the DoR, we helped each other clarify the key aspects and progress.

5-step agile transformation roadmap

Most companies would start an Agile transformation by hiring an agile coach or scrum master. That can work, but it depends on how you start doing it. Agile transformations will fail without leadership support.

To kickstart your agile transformation, I recommend taking the following steps:

1. Remove clutter
2. Create alignment
3. Run experiments
4. Learn and grow
5. Rinse and repeat

1. Remove clutter

Most often, teams commit to outputs and deadlines and follow strict, prescriptive roadmaps and processes. Start by removing them.

Instead of being tied to an inflexible roadmap, leadership needs to define what to focus on next — e.g., customer growth, retention, profitability, etc.

For the most part, artifacts that require detailed, upfront thinking without the team — for example, roadmaps set without team involvement or highly detailed user stories — will get in the way of becoming agile.

Another key consideration is how collaboration happens. For example, if you have frequent meetings to talk about progress, that might be more distracting than helpful. It’s better to keep meetings to a bare minimum and focus on results instead of micromanaging teams.

The product backlog probably has a high chance of being cluttered. You may have items untouched for months or items unrelated to your goals. Archive or delete them whenever you can.

2. Create alignment

Leadership must provide the context and direction instead of defining what needs to be delivered by when. Once that happens, teams can work toward a goal instead of focusing on building features. This way, they become achievers instead of simply executors.

Let me give you an example:

• Output — Implement a member-get-member engine
• Outcome — Create a new customer acquisition channel representing 50 percent of our current costs and generating 10 percent of our new customers

The output forces the team to deliver a solution without knowing the problem they’re solving while the outcome lets the team imagine different solutions to reach clearly defined results. Doers will do what they are told, and this will limit their creativity and potential. Achievers will use their sharp minds to solve problems by creating valuable solutions.

3. Run experiments

Virtually no organization will completely revolutionize its ways of working without at least a bit of kicking and screaming. That’s why it’s important to get everybody comfortable with the unknown.

Start by running experiments with one or two small teams and expand gradually from there. Give a team a goal and let them figure out how to achieve it. Don’t tell them how to do the job; let them discover the path. The experiment will help leaders and teams get comfortable with the unknown.

Don’t rush. It’s important to get used to the new way of thinking. If you move too fast, you will end up doing more or less the same things as in the past but a bit differently. That’s not agile.

4. Learn and grow

Evaluate the results of your experiments and strive to uncover opportunities to do it better next time. You’ll quickly realize there are countless opportunities to make things better.

That’s the power of agile; it helps you see the world from different lenses.

In traditional methodologies, we follow plans, implement requirements, and deliver what was promised. Agile keeps us busy in the problem space; we don’t make detailed plans, write extensive requirements, or make output promises. Instead, we continuously evaluate how we could best solve problems by creating reasonable solutions.

As you learn, you can improve how you work and scale that up to more and more teams. As this cycle repeats itself, the company will gradually become more agile.

Starting with a single team is easier because you can quickly understand the differences between the old and new worlds. When it comes to scaling, I recommend doing it gradually. Suppose you have 10 teams. Start with one, then move to three, five, seven, and, ultimately, all 10. This should take between six months to a year.
Patience is vital to scale teams up successfully.

5. Rinse and repeat

Repeat these steps several times. Each cycle will take three to six weeks. In the process, you develop the experience you need to become truly agile.

You don’t just say you’re agile; when you act with an agile mindset, eventually, you become agile. It’s about your attitude, not the frameworks or techniques you use.

Choosing the right agile framework

The first step many organizations take toward agile transformation is to select an agile framework to implement. In my experience, that’s a mistake because you’ll quickly start to focus on the how and miss the why.

Don’t get me wrong; I’m not saying frameworks are bad. I love working with scrum, but it’s not a good starting point for an agile transformation. Eventually, you will start using a framework, but first, you’ve got to develop the mindset behind it.

My favorite approach is to start by learning about different frameworks, evaluating the team’s challenges, and gradually introducing aspects of the framework based on those observations. In short, you want to start by solving problems you can actually see instead of wrestling with hypothetical problems.

The following table compares four of the most common agile frameworks — scrum, Kanban, scrumban, and Shape Up, and their characteristics:

Attributes	Scrum	Kanban	Scrumban	Shape Up
Ideology	Solve complex problems while delivering value	Use visuals to improve flows and processes	Agile approach to product delivery (a hybrid of scrum and Kanban)	Transform ideas into valuable solutions while reducing risk
Practices	Sprint planning, daily scrum, sprint review, retrospective	Visual flow of work, limit WIP, make processes explicit	Visual workflow, limit WIP, trigger planning, no estimate	Shape, bet, build
Roles	Product owner, scrum master, developers	None	None	Shapers and builders
Artifacts	Product backlog, sprint backlog, increment	Product backlog, Kanban board	Product backlog, kanban board	No backlogs; only bets
Flow	1–4 week cycles	Continuous	Continuous	6 weeks of building, 2 weeks of cool-down

You might notice that the Scaled Agile Framework (SAFe) is conspicuously absent from this list. To be honest with you, SAFe is an undercover waterfall agent, not a true agile framework. The roots of this framework come from the Rational Unified Process (RUP), a heavy project management framework.

SAFe is a set of processes that tries to solve everything. If you want to get full support on a process, SAFe is the best choice because it’s highly prescriptive. But if you want to become agile, SAFe is by far the worst choice you can make.

My advice is to keep it simple. Address problems you have and ignore the ones you don’t.

The table below contains some additional insights about each framework mentioned above, including recommendations around org size and team maturity as well as pros and cons associated with each approach:

Framework	Org size	Team maturity	Advantages	Disadvantages
Scrum	Any size	Any experience level	Continuous improvement Easier to manage short-term goals and focus on value	No WIP limit Focus more on scrum events than an agile mindset
Kanban	Any size, but ideal for small teams	For mature teams	Flexible Focus on work, waste less time on ops WIP limit	No short-term goals Requires high level of discipline
Scrumban	Any size	Any experience level	Continuous improvement WIP limit Flexible	Planning is full dependent on the team
Shape Up	Small teams	For mature teams	Short-term goals Team commitment Strict rules promote thinking and validating beforehand	For dynamic teams, difficult to improve over time For large teams, challenging to manage

Maintaining a high-performing agile team

Becoming agile is arduous and will take time, but that’s not enough. Teams need to evolve to remain agile continuously. When new team members arrive, stakeholders make demands, changes hit the organization or product, etc., it’s easy to fall back into traditional ways of working.

I recommend conducting a health check every quarter. A quick way to do it is to review the Agile Manifesto values and ask the team to rate how often they live up to them. Evaluate the results and talk about what the team can do differently.

When you step back from your busy routine, you allow yourself to reflect and improve your work. Stepping back allowed me to ditch definitions of ready, burndown charts, and velocity. Along with the team, I realized that such techniques got in the way of collaboration and hurt our agility.

The more courage you have to embrace the unknown, the more agile you can become. The faster you learn, the quicker you can create value.

Featured image source: IconScout