Lack of Product Owners: the problem with Directionless Agile

I’m back again and this time and in contrast to my positive "falling in love" confession about Agile I also want to balance the argument and write about a reoccurring problem I have seen in large enterprises during their Agile Cloud Adoption programmes.

The Problem: Enterprises saying they will implement an "Agile" way of working but in practice failing to follow through with the transition.

What we are commonly seeing in large enterprises is that the reality of their organisation can hamper the implementation and adoption of both Agile and  cloud. Often senior management like the idea of implementing Agile but they haven’t considered the necessary changes they’ll need to make to their business and organisational practices in order to facilitate their teams to work in an Agile manner.

These common mistakes include;

  • Not changing the tooling their teams use
  • Not changing the environment within which their teams are working (which doesn’t encourage collaboration)
  • Keeping a regimented control mindset which still focuses on reporting and tracking, hampering their teams from adapting to the flexible Agile mindset

As the title of this blog suggested, I want to dedicate the majority of this post to a specific common problem we see in organisations failing to adopt Agile, which is either the entire lack of a product ownership or not empowering the product owner adequately to do the job as per the Agile Principles. The Product Owner is a critical part of a Scrum-based Agile adoption, as they are a single point of contact that prioritises work and ensures value is maximised for a product during its development. (For more detailed explanation see the scrumguide online.)

In large enterprises where both the cloud and Agile are new, this lack of – or underpowered – product owners has created a few common trends and behaviours. Customers struggle organisationally with this and their programme suffers:

  • They define everything as important
  • They give everything the same critical end date (Q2 this year)
  • Nothing gets deferred or re-prioritised just added to the list

Effectively they struggle to perform true prioritisation. From what I’ve seen, this can be caused by two main factors. One is that the product owner type role has not got the "buy-in" from all the stakeholders and therefore they struggle to make decisions resulting in "directionless Agile".

The second is that there is an organisational view that the product is too complicated for one person to make decisions and council type committees are set up where decisions are rarely made as consensuses are hard to achieve.  With the cloud we believe you can empower one individual whose responsibility is to achieve maximum business value and they will make and enforce decisions. I don’t expect them to make these decisions unilaterally, they should make informed decisions after consulting with the wider team but, ultimately, it is their job to make decisions and maximise the value for the organisation.

In this situation I see the benefits of making decisions far outweighing the potential cost of wrong decisions. One of the tenets and benefits of Agile is that, if you make the wrong decision, you can fail fast and adapt in the next iteration. As a result, enterprises can limit the cost of decision making to a 2 week regret cost of an iteration, which is far lower than the ongoing cost of delayed delivery – be that through the opportunity cost of keeping resource on a project longer than required or the lost opportunity to start other projects earlier, deferring the receipt of future value.

Additionally in these types of organisations, I have tended to see a lot of senior managers in large enterprises interfering with the development teams with last minute important tasks that defer tasks in the product road map or "goal" of what the development team is trying to achieve.

So, great – I hear you say – you’ve pointed out all the problems, but how have you helped organisations with this?

Well firstly, with some customers Cloudreach has been specifically hired to act as a product owner for the organisation, and remove that ambiguity and enterprise politics in order to make the best decisions for the business. This, again, is not a ‘one size fits all’ approach and is totally dependent on the engagement. It is also dependent on Cloudreach being sponsored by someone with the correct authority in the organisation so that the Cloudreach representative acting as product owner can authoritatively push back.

In cases where this is not possible, we have tried to coach organisations and assist their prioritisation with targeted questions and project mantras we have created. An example would be: when dealing with the issue of last minute requests from senior stakeholders we would respond with "yes we can do that additional item, but in the place of what?" Naturally this kickstarts prioritisation and educates individuals that in Agile you cannot do more – instead you can alter the priorities or change to focus the team. The team needs to understand relative priorities to make the best product for the business.

Lastly, when dealing with requests where everything has the same end date, I have found burn up charts forecasting dates beyond the target date to be very powerful tools. (A burn up chart is effectively a graph showing the amount of backlog stories points or effort, against time. It gives forecasts with ‘optimistic’, ‘most likely’ and ‘pessimistic’ amounts of story points covered per iteration, known as the velocity of the sprint).

The image below is an example. It shows the 3 diagonal lines of the ‘optimistic’, ‘pessimistic’ and ‘most likely’ burn ups of backlog story points, and the estimated time of the backlog being completed.

This tool allowed the development team to articulate the scale of work and issue with everything ending at once, and this naturally allowed us to force prioritisation. Here the customer can prioritise and ensure the backlog items in y are delivered first by Q2 and then the other items totaling x can be delivered somewhere between Q3 and later based on our forecasts. Visual tools can really aid with discussion and assist with showing the problems of the lack of prioritisation that can occur in a "Directionless Agile" environment.

In summary there are a lot of things that can misdirect enterprises attempting Agile delivery, particularly when embarking on Cloud Adoption programmes. This can normally be avoided by enterprises if they consider the organisational and transformational impacts of their Cloud Adoption programme at the beginning; that way they can plan to support the cultural changes required to adopt Agile and deliver cloud projects and programmes successfully. Although ideally this would be captured at the beginning of a cloud project or programme, there are a few tools I have found successful in aiding organisations in providing direction mid-flight.Thanks and reach out to me if you have found any other methods to re-direct an Agile or cloud programme.