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:
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 a nutshell, Agile is about getting things done instead of endlessly talking about how to progress.
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.
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:
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.
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:
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.
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:
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.
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.
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.
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.
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:
|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||
|Kanban||Any size, but ideal for small teams||For mature teams||
|Scrumban||Any size||Any experience level||
|Shape Up||Small teams||For mature teams||
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
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
A product review is the moment where you evaluate what the team created over the last development cycle and align on the next steps.
A knowledge base is a centralized location where information is stored in an organized and easy-to-access way.
Natalie Adams Barnes, VP of Product and Product Design at Zumba, pulls back the curtain on her approach to prioritization and the user research methods that help her team walk — or, perhaps, dance — in their customers’ shoes.
Subhayu Ghosh discusses getting to the core of the customers’ problem instead of needing to develop the most innovative solution.