There are many challenges when adopting Agile, at all stages of the process, from introducing it to trying to apply it successfully. Through my conversations with professionals around the world, I have developed a deep understanding of the main obstacles that companies of all sizes face when incorporating this new way of working. So, I wanted to share some of the most prominent problems you are likely to face, and how to address them or think about them in a different way. One important thing to realise is that these challenges are not unique, they are universal.

In a recent webinar I outlined four ways that Agile was being applied. I talked about how Agile itself was being applied at the enterprise, department, team, or individual level who was championing Agile in the organisation. The challenges I have identified are not unique. In fact, they are very common among the majority of people I spoke to which included members of our Agile Ideas meet up group. Some of them are more familiar than others depending on the way in which Agile is being applied in an organisation.

There are plenty of challenges that I could cover, but we do not have all day. So, I am going to focus on the 10 most prominent Agile challenges for you to think about and evaluate whether they are impacting your organization. See if you can notice recurring themes among some of these challenges as we talk through them.

1. Getting people to understand the Agile mindset

What is Agile mindset? How do I get it? This is around getting stakeholder buy-in. Your stakeholders might be executives, colleagues, or customers, and getting buy-in from them for systemic change to be made possible is necessary. It is about helping people understand that Agile mindset is not just about having stand-ups or having a Kanban wall. It is much more than that. It’s a cultural way of working that needs to be implemented across the whole organisation and in the minds of the teams.

Often when an organization says to me that want to be more Agile and are interested in applying it, I often start with a couple of key questions:

  • What is the definition of Agile to you?
  • Why do you want it?

Now, when I ask what the definition of Agile is, I’m not expecting them to tell me about all the different methodologies that exist that relate to Agile delivery or to explain that Agile was initiated from the software development world. Instead, I am looking to understand what it is to be Agile and what their specific understanding of it is, particularly if I am dealing with an executive who is the one that is sponsoring the change. I need to know this, because often there is a misconception about what “Agile” really is.

One of the things to think about is the fact that, depending on the size of the organization, the history of its operations, projects, maturity, and culture, there are so many factors to consider when trying to introduce any change, let alone adopting an Agile way of working and mindset. You need to do so incrementally, as opposed to expecting change to happen overnight. I want people to think about why and what Agile means to them, because if you can’t explain what it means to you, you may be trying to implement something that is doomed to fail. For example, some people like to tell me they want to do things faster. They do not realize that having an abundance of legacy processes can make it harder to do this.

Therefore, no matter how many Agile concepts you introduce, if the delivery teams are held back by old-fashioned, outdated PMO models, or departments and teams impacting delivery, you’re not going to move very fast at all.

2. Trying to apply Agile principles during a hybrid Agile waterfall delivery

How do you apply Agile principles during a hybrid / Agile / waterfall delivery environment? Well I’ve yet to see an organisation that is truly Agile! I am sure they exist somewhere but, like unicorns, they’re rare. Every time I have gone into an organization who says that they are ‘fully’ Agile, then you delve into, for example, the way that they run their prioritisation or their financial budgeting processes, they are actually run entirely waterfall and still heavily controlled at the top. So, there is always something that is partially waterfall regardless of how Agile organizations say they are, and that is okay. There is no reason why that cannot be the case. It is just acknowledging it.

I think the challenge around applying Agile principles constitutes with firstly understanding how your current delivery works. If you have not documented and understood the current delivery landscape for your teams today, I would start by doing this in a framework that provides consistency and information centrally with a single point of truth. Doing so can provide some immediate clarity on your gaps.

If you don’t have something of the sort that helps people, anybody coming into the organization or anyone existing in what exactly is your delivery approach or your model, regardless of how much Agile and waterfall it is, they are going to struggle to apply Agile principles to it. I like to think about making sure that there’s clarity on what is there today before you start trying to change it. If you try to change something without knowing what is there today, it is going to be hard to measure whether your change was effective or not. Think about what it is that is there today. If you don’t have that defined, well, then you’re going to probably have to spend some time upfront doing that before you can address that can address that challenge at all applying Agile principles. Once you have your delivery framework defined, it becomes a central point of knowledge, like your own knowledge bank for your delivery teams and anyone else that they are collaborating with. Once you have something like that in place, you can then start looking at how do we apply Agile principles to our current framework? You can incrementally tailor that so that it is more Agile and less wasteful.

3. Cost of initiatives is unknown

Another big challenge is that costs of initiatives are unknown in Agile. This is an interesting one because I find I have seen multiple times where vendors have tried to get away with not providing any form of quotation because ‘they are Agile’. They cannot give any estimates as to what it is going to cost. There is often a list of excuses. That is not effective.

There is still a necessity to understand the costs of initiatives even in Agile, or at least knowing what your allocated budget for delivery is. Most organizations are still doing that in a waterfall way. What gets even more challenging is traditional project management; you are planning a lot of that, (effectively guessing a lot of that up front). Whereas in Agile, you develop that bit by bit as you go throughout.

Having to know the entire cost up front is hard when you are building as you go. This is where some organizations I have seen have instituted an approach that provides a source of funding, a bucket of funding by team/division/department. It provides the funding allocation based on a pre-determined wish list that those teams effectively come up with at the beginning of a new funding year. It means that they must provide an estimate of what they think they will need to deliver based on predetermined objectives and results also known as OKRs. You may then choose to allocate funding based on OKRs, time (such as quarterly) or by initiative.

There are many ways to apply it, but, saying that cost of initiatives are unknown just means that you do not have an effective financial modeling management process, investment governance process or prioritization process in place. You need one of these to ensure you stay on track with your budgets!

4. Being able to deliver to the breadth of the problem/solution options

This one is closely following cost of initiatives, because despite wanting to deliver a specific solution, you do not always know the cost of it as the scope may change throughout delivery. In this instance you need to ensure you apply techniques such as the MoSCoW technique where you can prioritize with your customer, the Must Haves, Should Haves and Could Haves. I have talked about the MoSCoW technique in my recent webinar on planning using project management techniques. You can learn more about the detail of MoSCoW in more detail. Fundamentally, it is sitting with your customers and prioritizing what they absolutely must have versus what is not as vital. Doing that means you are more likely to deliver to the pre-determined customer requirements in the priority order that is most relevant to them. You want to make sure your customers are happy, that is one way to ensure that.

5. Changes are quick but processes and systems hold you back

This is one of my favorites, because its precisely why Agile Management Office exists! To help by removing roadblocks and hurdles in consultation with other departments and executives and the like. So, delivery, being frustrated with the fact that they are unable to move as fast as they would like, is most often because processes and systems are holding them back. This is a big problem. Many organizations run what I call a project tools monopoly, where there are so many different tools and there is no actual visibility on what each of those tools are going to be doing.

Thinking about looking at your processes and your systems, and how they are intertwined with your delivery teams, and how your delivery teams might be hindered or supported by them is important. If you remember I mentioned at the beginning around frameworks, well, this is where if you have a consistent approach to your framework, then it should help you to identify where your process gaps are. In order to ensure that you have the right processes and systems in place, you need to have some sort of framework that you can review regularly and make sure so that not everyone is doing something in a hundred different ways.

6. Working with leaders who do not understand Agile but think they do

Working with leaders who do not understand Agile but think they do, ties very closely with education for executives and board members. Executives and board members’ education about Agile is something that is necessary for them, especially if they are the ones who are requesting the change. If you remember at the beginning, I said that when wanting to introduce Agile, you typically ask executives a couple of questions. Well, at this point, those questions lead to what happens next and what it is that our executives or their team actually need to apply from a perspective of upskilling and uplifting the knowledge and awareness of what Agile is.

It is important that you understand how much of your executive team and your board members are aware. More specifically, how Agile applies within your organization. If that is not well understood and determined up front, then you are going to have inconsistencies with that knowledge across the board. You do not want your executives and your board members to be confused.

One of the things that is important when we think about executives, and board members effectively, is they are typically responsible for monitoring and making sure that everyone is meeting their organization’s strategic objectives and minimizing risk. Typically, in a traditional delivery environment, you might have a framework or you might have an approach that is quite clear for board members and executives around how we run projects, how we deliver how we’re going to meet our strategic objectives, how we’re going to make the things meet the results that we promised you with, you know, the millions of dollars that you’ve given us. It is important to make sure that you still have a way of communicating and providing an updated view on what that looks like for executives and board members.

If you are going to introduce new ways of delivery, such as with Agile, and so you need to think about how you can do that. And each organization is going to be different. It is important to always consider applying that very early to make sure they are on the same page so that information can flow down the line.

7. Adapting changes to available resources

My question in response to that is why are your resources changing? What is the cause of the change? Are you introducing an approach? Are you introducing squads by domains? How will you coordinate and bring your resources together and why are those resources changing? You need to understand and have a plan in place for when resources do change. That might be resources changing between squads, for example, because they are knowledge sharing, and they are bringing them through so they can take knowledge from one squad to another. It might be that domain experts are not available as much as we would like, and you are constantly replacing them. It might be that you have a revolving door of governance people, which is something that happens in the PMO world. Understanding what the problem is, why it is a problem, you will then be able to address that.

8. Breaking out from siloed groups

Traditional organizations are very hierarchical and very siloed. In some instances, in Agile organizations as well, there are still silos. Those silos may be there for different reasons. So again, this is one that you need to work out why it is a problem, where is the problem and what can you do about it? By understanding those two questions. First, you will be able to address that, you need to think about why there is a need for siloed groups or why they why there is a belief that it is needed. For example, silos are often there because there is someone leading it that believes it needs to be run in a way. Have they maybe not caught up with the way that you are approaching Agile? They may be not on board with the collaboration techniques or the methodologies or the approaches that you are taking?

It is important to understand why it is a problem where the problem exists, and then work out how to address it. And remember, when you’re applying Agile to your organization, you don’t always apply Agile at every single department in every silo and try to attack everything at once, you actually do need to break that off over a period of time, and it’s effectively a journey. So, keep that in mind.

9. Consistent understanding of Agile concepts

This will continue to happen unless you have defined up front what Agile is to your organisation. A framework will help you with that, as will specific induction materials and onboarding materials that you could use when bringing on new team members into the organization or even from other departments. Often many of the people that I have spoken to have said that the definition and philosophies of Agile are unclear to them or to their peers or to their management. team. Likely because Agile has started in a department or with an individual that might be an absolute champion of Agile but has done so in isolation. Starting in one area and it is therefore proliferating across the organization, but not in a consistent manner.

Again, I take this back to having an effective framework to define what that that Agile looks like for your organization and how it is being rolled out. When you are organically growing Agile within an organization and you are not clearly defining that upfront, it is likely that you are going to get inconsistency across the board. I have seen organizations who have introduced Agile using a particular methodology like Scaled Agile. Other parts of the organization might be using Scrum, other parts of the organization might be using something else and also not only using those techniques or those methods but actually training of your staff on so many variations. There is over 42 different methods out there! If you can imagine your team are getting trained on possibly, you know, a quarter of those, or you’ve got one team training on one and another train training on the other, that’s going to be enough certifications to basically play cards with.

You want to make sure that there is a consistent approach for how Agile is being applied, do not just ignore the rest of the organization because Agile is all about collaboration. If you do not have the philosophies, and the definition of Agile, clear upfront, well, you are unlikely going to be able to collaborate as effectively as you would like.

10. Application for organisations who are not ready for Agile

It is okay to not be ready. Are there several things you can consider before introducing Agile? Yes. There are also several things to consider when your organization is not ready for Agile. There are so many that I could go into that will probably be a topic for another day. Some of the things to consider are your current delivery maturity, your current change capacity, your current culture. How big is your team? How much legacy do you have? How many teams are on board with it? How many people must you train? How many people will be champions of it? Ultimately, there are organizations that are not ready for Agile. And the way to find that out, one of many ways, is to ask those questions at the beginning… why Agile? What does it mean to you, depending on the response you get, it may help you to realize that, for some people, Agile is just the term that they’re hearing that they think is going to make them more effective. They think by applying the Spotify model or another technique like the way Barclays Bank applied Agile is going to make them just as successful.

If you have a lot of underlying challenges, if you have some maturity gaps, you have capability gaps, you have resource gaps, and you’ve got lots of legacy, it’s going to be a lot harder to move to Agile, or effectively move to Agile in the way that you maybe envision. It is going to cost you a lot more and it is going to take a lot longer. So, it is better to break down the must haves the should haves and they could have for your ideology.

Final thoughts

Before embarking on one, making sure the Agile philosophies clear up front, and that you have got champions who are not only supportive, but understand Agile and have practically introduced or applied in other organizations themselves. They can tell you, not just the good stuff, but also some of the learnings, some of the challenges and some of the hurdles that they faced as well.

So, there you have it, they are the top 10 challenges that we are seeing currently in and around all things to Agile. You may have seen those or experienced those in your organization, you possibly may be familiar with more than one of them. They are by no means an exhaustive list, but they are the list that I think is the most current based on conversations globally with professionals who are looking to introduce or are firsthand seeing the implications of Agile being applied into their organizations.

If you would like any further information on what I have shared or assistance in framework building or help with your Agile journey, do not forget to reach out to me and my team.