by Jordan Golding, Delivery Principal at Automation Logic

There is some confusion around agile and prioritisation. When you identify and select the priorities for a project, a common misconception — that “proper” prioritisation goes against the grain of agile — often arises. Sure, there are things that you start with first, but too many self-professed agile projects suffer from a lack of clear priorities. This is a problem in and of itself, let alone the future chaos it leads to. 

The 15th Annual State of Agile Survey tell us that the main reason people decide to adopt agile for their projects is to help them manage their priorities. However, our own research indicates that the main issue that our clients’ stakeholders face, even after they adopt agile ways of working, is conflicting priorities (or lack thereof). And while the vast majority of our interviewees recognised that they need to retrain their people to be successful, only 3.4% mentioned the creation of a CCoE. 

So, the challenge is well-understood, but the steps to fix it are not. 

How mindset affects success 

Direction is possible without agreed-upon priorities: I have been involved in multiple projects tasked with “migrating X service to Y platform within Z months”. The team will perform the work in sprints, hoping to migrate said service by the required deadline. However, the people involved don’t necessarily know what they are doing or even where to start — guaranteeing, in most cases, that nothing gets delivered.  

Conflicting stakeholder Interests is normal and unavoidable: The lack of clear, well-communicated priorities leads to conflicting opinions. Especially in larger programmes, there is a common issue of senior stakeholders signing off on the project without caring about how the teams get from A to B — they are just wanting to see that the MVP is signed off as soon as possible. The absence of prioritisation leads teams to believe that their project is the most important one.  

Failure is not acceptable: Leading nicely to yet another risk — careerism. I was once involved in a very large programme with multiple projects, one of which proved near-impossible to get resources for. It was not seen as a priority since it was not due for six months, and everybody else was too busy trying to save their own project. They ignored other projects, leading to a knock-on effect that impacted everything.  

What are some real-world examples of these problems? 

The word agile in any context conveys the ability to move. Even if you have priorities embedded at the start of a project, this does not mean that you cannot be flexible. A report on the impact of agile showed that there was a 2:1 correlation between those who were dedicated to agile being successful and those who were not. If we were to look at dedication as truly understanding and following through with agile principles, it is easy to see how confusion can look like a lack of dedication.  

One of our clients knew that they had to migrate their infrastructure to AWS by a specific deadline. This was not just a lift-and-shift project — the platform needed to be refactored. The team struggled to get velocity due to a backlog of engineering notes, with no clear milestones or release points of where they should be at any given time. Our team arrived without understanding the current set up or what work had already been achieved. This led us to not initially understanding where to focus our efforts and add value, and we were told to just ‘work the backlog’ — not the best use of highly skilled consulting engineers.  

To ensure value for money, our team pushed back to understand the client’s priorities. When they found that the client had no answer, we suggested installing high-level milestones, outlining what needed to be delivered and by when. (e.g., within two months, the applications must be containerised, and a new platform built). They then worked with the client’s key stakeholders to create six clear, detailed milestones. 

Your top two priorities for successful prioritisation  

The first thing you need is strong product ownership. It does not even have to be a bona fide product owner role — just someone to facilitate discussions and make priority calls. At Automation Logic, we use delivery managers to help facilitate those conversations. They consider working with senior stakeholders from both the client’s side and internally to get to the right decisions and, therefore, the right priorities.  

To build a team that can prioritise effectively yet flexibly, you need the right culture. An open, transparent culture, where everyone feels safe to share their opinion and explain why their specific priority(ies) may need to change. Being able to suggest a point and get it across in the right way is invaluable to getting the full picture of the project. This can be condensed to saying a culture of respecting and understanding agile, because agile comes down to being respectful and open to change.  

The consultancy perspective 

Culture can be a seemingly difficult topic for a consultancy to place so much weight on — we are entering their world, and their culture.   There are three things you need for a successful project: People, Tools, and Process. Normally, organisations either bring in suppliers 

because they don’t have the right skills or the right tools and the supplier can help. The thing often missed is the process part. The thing often missed is the process part. And what working in a certain way does is shine a light on process — It shows what does and doesn’t work. 

On the projects I run, I always begin by trying to work with stakeholders to justify our work and any change in priorities. Bringing our processes in means facilitating discussions with senior (client) sponsors about how to measure that a project is on track. The key is to influence at the right level, demonstrating the value in what you want to do assists and getting buy-in. We implement our way of doing project delivery, while always showing the client the value they will get back. 

In our next briefing paper, we will share our insights on agile being a mindset, not a methodology.

< Back