10 Ways to Help Your Agile Initiative Succeed

BLUF: This post outlines 10 Ways You Can Help Your Agile Initiative Succeed whether that is adopting Kanban or Scrum or taking on an enterprise agile transformation. 

I recently wrote a post about the 10 ways that Agile Transformations will fail. The article, along with a sharp-looking infographic, was well received. But it also sounded fairly negative.

It turns out that people don’t want to hear about failures, they want to learn how to make agile succeed!

So let’s turn that frown upside down!

This post is the countermeasure to that transformation failure post. In this post, we will explore the 10 Ways that you can promote business agility and help your agile initiative succeed.

And we have also produced this sharp-looking download: 10 Ways to Help Your Agile Initiative Succeed

Let’s get to it!

#1 – Take the Long View of Your Initiative

While implementing Kanban or Scrum can be pretty quick, an Agile Transformation is not a quick fix. Most experts agree that an agile transformation takes three to five years and it may never end.

I know it sounds trite but it really is about the journey and not the destination. You never really arrive. Instead, you are on a journey of continuous improvement.

It would be a disservice to the organization to characterize your agile adoption or transformation as the pursuit of a goal. You are very unlikely to experience a peak mountaintop moment of Zen at having arrived.

It may actually be best to avoid calling your initiative an agile transformation. Or making some splashy announcement about transforming the organization. Rather, start small and focus on a journey of discovery and improvement.

At best you are going to have some quick wins to build on. You will be thrilled to see the lightbulbs go on for people as they “get it”.

And just as frequently you will have setbacks. Sometimes it can feel like pushing a boulder up a hill by yourself. You feel like you cannot let up the pressure.

#2 – Focus on Values, Principles, and Mindset

Most people who undertake a transition or transformation focus on the process. You might hear something like “we want to use Scrum as our project management approach”.

That is actually not the best way to help agile succeed.

Why so? Well first, Scrum is not a project management approach. It is an organizing framework for solving complex problems.

Second, the focus on the process will divert you from the true value of agile ways of working – mindset and culture.

So don’t focus on process.

That sounds easy enough. The challenge is that it is relatively easy to change process and it is extremely difficult to change culture and mindset. Karim Harbott in his excellent book The 6 Enablers of Business Agility points out that most organizations start with process (Agile Ways of Working) and ignore the other key enablers of organizational change.

In my experience, all but the last enabler, Ways of Working, tend to be largely ignored during agile transformations. Thqt is why the transformation success rate, however one defines success, is unacceptably and stubbornly low.

— Karim Harbott, The 6 Enablers of Business Agility; How to Thrive in an Uncertain World

Changing the mindset and culture is difficult. As Harbott points out in his book, the VersionOne Annual State of Agile Report consistently lists culture as a top challenge to adopting agile. In the most recent survey, 43% of respondents reported that “Organizational culture at odds with agile values” was a significant barrier to adopting agile.

How do you change the culture? One way is to focus on the 4 Agile Values, 12 Agile Principles and the Mindset needed for business agility. These are typically covered in an agile training session but are frequently overshadowed by the mechanics of Scrum or Kanban.

Take a look at the Agile Principles, Scrum Values, and Kanban Principles below. These should be studied and internalized in your organization so that people know why they are following the process steps.

A Summary of the 12 Agile Principles:

1. Satisfy the Customer
2. Welcome Changing Requirements
3. Deliver Frequently
4. Collaborate with Customers Daily
5. Empower and Trust the Team
6. Face-to-Face Communications
7. Measure Progress by Customer Delivery
8. Work at a Sustainable Pace
9. Strive for Technical Excellence
10. Eliminate Unnecessary Work
11. Use Self-Managing Teams
12. Periodically Pause, Reflect and Improve

The 5 Scrum Values are outlined in the Scrum Guide. In short, they are Courage, Focus, Commitment, Respect, and Openness. The 2020 version of the Scrum Guide says this about the values:

The Scrum Team commits to achieving its goals and to supporting each other. Their primary focus is on the work of the Sprint to make the best possible progress toward these goals. The Scrum Team and its stakeholders are open about the work and the challenges. Scrum Team members respect each other to be capable, independent people, and are respected as such by the people with whom they work. The Scrum Team members have the courage to do the right thing, to work on tough problems.

— Schwaber, Ken and Sutherland, Jeff, 2020. The Scrum Guide.

#3 – Leaders Should go First to Help Agile Succeed

Lack of leadership is one of the top causes of failure in a transformation. It is not enough to give tacit approval to agile ways of working; leaders need to engage in, learn about, and lead any business agility initiatives. See Agile Leader Role During an Agile Transformation.

It has been my experience that leaders pay lip service to agile and stop short of leaning in (no pun intended) and understanding business agility deeply. They often view agility as just one more priority of the organization. Or worse, they view this as something the team does that does not involve them.

#4 – To Succeed with Agile, Understand What It Really Means

Sounds like a slam dunk but it may be challenging for people to understand what agile really means. As noted above, many people think of agile practices or frameworks as agile. They think agile and Scrum are the same thing.

What does agile really mean?

A quick Google search for “what is agile” will turn up the following potentially conflicting explanations as the top 5 best responses:

#1 Result – Agile is an iterative approach to project management and software development that helps teams deliver value to their customers faster and with fewer headaches.  (source: https://www.atlassian.com/agile)

Hmmm…so Atlassian says that agile is an approach to project management and software development. Does that mean it doesn’t apply outside “projects” and “software development”? WRONG

#2 Result – Agile is the ability to create and respond to change. It is a way of dealing with, and ultimately succeeding in, an uncertain and turbulent environment. (source: https://www.agilealliance.org/agile101/)

This is actually the definition on this list that I most agree with.

#3 Result – Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. (https://www.cprime.com/resources/what-is-agile-what-is-scrum/)

OK, back to software development methodologies.

#4 Result – Agile is an approach to project management that leans heavily on short time frames, adaptability, and iteration. (source: https://www.coursera.org/articles/what-is-agile-a-beginners-guide)

Back to project management when in fact, many or most agile teams adopt a product view rather than the problematic project management paradigm.

[</rant on> Seeing the world through a project lens means that each initiative is unique and has a defined start and finish. Project success is measured by on time, on budget and on scope delivery which ignores customer value and satisfaction. Enough already with the projects! </rant off>.]

#6 Result – (the #5 result was a YouTube Video) – Agile enables organizations to master continuous change. It permits firms to flourish in a world that is increasingly volatile, uncertain, complex and ambiguous. (source: https://www.forbes.com/sites/stevedenning/2016/08/13/what-is-agile/?sh=530d3dbb26e3)

This page doesn’t really define agile so much as explain it. And not briefly.

The fact that there are 5 very unique definitions of agile in the top 5 Google results highlights the difficulty of getting people to a common understanding of what agile is.

I have tried to help with my own writing – my 2019 blog post titled What is Agile defines agile in this way:

“Agile is a mindset and way of working that puts people first, promotes collaboration, and uses adaptive approaches to deliver value in a changing environment.”

The key to mastering agile is simple to say but may be difficult to do – Make Learning the Focus! A great way to do that is to run your own experiments.

#5 – Run Your Own Experiments

Most organizations launch a transformation with a vague idea of agile and a splashy announcement about what they are going to do and what it will accomplish. They make large and vague promises of improvement when they know the least about agile ways of working.

Even worse, some organizations simply copy over what they believe they understand about how other organizations have succeeded with agile. My stomach churns every time a client asks me about the Spotify Model or told me they were forming squads and tribes. [Read more about the Spotify agile approach here: There is No Spotify Model]

Don’t copy others. What worked best for others may work for you. Or it may not. Chances are it won’t because first, your context is different and second, you don’t learn anything from copying others.

Organizations need to run their own experiments rather than copy others.

Sure it may be helpful to benchmark others or to rely on external help when you are just starting out. Site visits to other companies and external benchmarking can be extremely helpful. Hiring outside consultants can infuse the organization with much-needed expertise.

Longer term each organization needs to build its own internal expertise by running those experiments.

#6 – Focus On Why You Are Pursuing Agility

This is really important and in hindsight, perhaps I should have listed it first.

Overlooking the “why” you are changing to agile is a big mistake that will undermine agile ways of working.

In the Certified Agile Leadership Course I took from Michael Sahota in 2017, he did an interesting exercise related to the Why. He facilitated a discussion of why people were pursuing agile and business agility. We brainstormed a number of ideas together as a group. Then Sahota teased the ideas into the categories of What, How, and finally Why.

The challenge in most organizations is that they don’t understand the why behind the initiative. They are focused on the What (e.g. deliver faster) or the How (e.g. Install Scrum) and not the underlying Why that is going to be compelling.

It is a great exercise and one that I hope you will consider if you want your initiative to succeed. Your vision and compelling why should pull people in and motivate them to help.

#7 – You Need an Agile Champions Team to Succeed

Agile is a team sport. Improving the business agility in your organization, whether you call it adoption or transformation or something else, is going to require a team.

Harvard Professor John Kotter is the king of change. In his popular 8-step model for organizational change, his #2 step is to build a guiding coalition:

A volunteer network needs a coalition of committed people – born of its own ranks – to guide it, coordinate it, and communicate its activities.

— John Kotter, 8 Steps for Leading Change

I have seen a number of names for these change organizations. I think I learned Agile Champions from Sally Elatta of Agile Training and AgilityHealth fame. Another popular term is the Agile Working Group, a term I first heard from Jorgen Hesselberg about his work at Navteq / Nokia. In his book Unlocking Agility, Hesselberg defines the Agile Working Group as:

A dedicated team of change agents whose purpose is to remove impediments to agility across the enterprise.

— Hesselberg, Jorgen. Unlocking Agility 

What we call this team is less important than the characteristics of the team members. I would argue that participants in this team need to have three characteristics. The first is the power to lead change. That includes the power to get shit done and remove the impediments that Hesselberg mentioned.

The second characteristic is to be passionate about agile ways of working. Agile works best when you are attracting others rather than making other people change. You need people in your coalition that get it and are invested in learning and improving.

The final characteristic is that they are dedicated. In an ideal world, your Agile Champions would be 100% available and focused on agile. They would be using agile ways of working including leveraging a prioritized backlog of work, transparent information radiators, and regular short meetings.

What doesn’t work is to assign people who are already allocated 100% to other work to lead the change. As you can imagine, people who are already busy don’t have the bandwidth to really make an impact.

An equally poor choice that I see organizations make is that they push forward the wrong people to be part of that change team. I don’t know if they are consciously trying to undermine agility or not but frequently they make poor choices when they put forward people to be on the change team. These random people may be chosen simply because they are available and they are “voluntold” to be part of the agile team.

Consider the difference between these two approaches:

Get those who are motivated on the team and they will attract like-minded individuals. They can cast the vision for why the change is important. Some of the ways that they can do this include:

• Frequent Leadership Updates
• Hosting Town Hall Meetings
• Providing visibility to team progress by supporting joint Sprint Reviews
• Sponsoring Brown Bag Lunches for learning from internal and external experts
• Dropping in on the events of each agile team
• Celebrating wins!

#8 – Choose the Best Approach Based on Your Context

Agile is great. I love it. But I don’t think it is the tool for every situation or context.

When all you have is a hammer, every situation may look like a nail.

Using agile everywhere is one of the mistakes called out by Daryl Rigby and his co-authors for Doing Agile Right. They argue for the application of agile where it makes sense and for more traditional approaches, including bureaucracy, where agile doesn’t fit:

The challenge in short is not to replace bureaucracy with agile everywhere but to find the right balance between the two.

Daryl Rigby et al, Doing Agile Right.

I recall making this mistake myself at a small financial services firm a few years back. We held training for teams and leaders and shortly after, we asked for volunteers to join the Agile Champions team. We didn’t have representatives from technology but we had plenty of interest from Human Resources, Finance, and Legal.

The team members from HR, Finance, and Legal struggled. They kept asking, “How can we apply Scrum to our work?”

Don’t get me wrong, those areas of the business can benefit from Agile ways of working. But they are not the first place to start. Plus, we emphasized the Scrum Framework and those teams found Scrum unwieldy for their context.

I’ve learned from that experience. Start with agile ways of working in those areas where you have the best fit. Run experiments to see where else you may adopt it. Leverage the thinking behind the practices (e.g. eliminate handoffs, identify and resolve bottlenecks, organize around teams) without necessarily trying to force fit a standard approach to every area of the business.

#9 – Promote True Change

One of the failure points I mentioned in my related article was those that do Agile in Name Only. That is, they simply rename what they are doing today with agile terms. The most common ways to do this are to rename thing that you have always done with new agile terminology. Your Project Managers become Scrum Masters, your status meetings become standup meetings (though you don’t stand up), and your project phases become Sprints.

It happens pretty frequently as a way to make change easier or to give the illusion of change when you don’t really change.

Obviously, renaming things to be what you are doing today is not a change, it is the opposite of change. It is simply doubling down on what you are doing today and reinforcing the status quo.

Instead, promote true change.

Be clear about the current state of affairs and the proposed new state of affairs. Be mindful of those that want to diminish or undermine the change effort.

This doesn’t require making what was happening in the past bad. That will only trigger more resistance as people feel attached and they dig in to defend. Plus, some of those previous ways of working actually provided business results. For example, I’ve used waterfall before and made it work to deliver on large initiatives. There had to be some redeeming qualities!

#10 – Finally, Embrace Uncertainty

This may be the single biggest hurdle to succeed with agile – that is overcoming the need for certainty and control.

It surfaces in many ways but two that I see quite frequently include:

1. Leaders require a step-by-step plan for the agile transformation. This is called waterfalling your agile transformation and I don’t think I need to explain why such an approach would be counterproductive. See How to Develop Your Agile Transformation Plan.
2. Requiring that any agile initiatives have a fixed scope, timeline, and budget. Yes, we can use agile but we just need to know exactly what it will cost. This happens a lot. There is almost a kneejerk reaction if you say that you are going to work in 2-week sprints and you cannot describe exactly what will be in every sprint. Leaders have become hard-wired to guard against any type of “scope creep”. Letting a team work against a prioritized backlog can be threatening.

I had that second scenario play out recently at a client. There were discussing a pilot agile project that would improve on an existing feature with external users. When I suggested that the team would pivot based on feedback from users, they were aghast. They feared that not only would the users lead the development astray with scope creep, they worried that the developers would gold-plate the solution and wind up spending more than what they wanted to spend.

If you are familiar with agile ways of working, you probably know that this is not usually something to worry about. Sure you might have the occasional delivery of an extra feature. But Scope Creep in agile is complete bullshit as I’ve stated elsewhere.

The first Agile Principle is about satisfying the customer. It is not about delivering on time or with planned scope. In fact, those concepts are not included in the Agile Principles.

Scope creep and gold-plating are red herrings at best; boogeymen to frighten us. Agile teams that collaborate closely with their customers and deliver in sprints rarely err on the side of over-delivering. These are just not problems to worry about.

What should be worrying is the push for certainty and the need to control. There simply is no certainty in complex development environments. That is the best reason for using agile.

Summing it Up – 10 Ways to Succeed with Agile

I hope this list of 10 Ways to Help Your Agile Initiatives Succeed has been helpful to you. And I hope that they counterbalance the despair of my Top 10 Reasons Agile Fail post.

I’d love to hear about your experiences and feedback. Where did I get it wrong in this post?