Agile product management in a non agile “corporate” world

Most traditional businesses are either going through a digital transformation or standing up their own digital product teams. However, this isn’t an easy journey. Last year I did a talk @producttankmcr about this, which went down well, so I thought I’d condense it into a blog.

I’ve worked for the co-op for nearly 13 years (it’s a great place to work) with the last 15 months in co-op digital. I can honestly say that I feel like I have delivered more in these 15 months through agile product management than I did in all the previous years working in a non agile world.

I wrote a blog about the work I have been doing with our Funeralcare business which you can read about here and this blog is about comparing my experience of this against previous projects.

Context: The role of an agile Product Manager

There are hundreds of articles about this but for me there are two main parts to the role:

  1. The Product Owner

The product owner is all about setting the vision for the team, being obsessed with user needs and deciding what to tackle when by prioritising the back log. Saying NO 5 x more often than YES is also an essential skill.

2. Stakeholder Management

Just as important is stakeholder management. It is essential you speak the same language as the business to avoid misunderstandings. The same words can mean different things to different stakeholders such as this classic “Four candles” Two Ronnies sketch. Roadmap, backlog, user story even product manager can mean different things to different people.

Challenges of doing this within a corporate world

People in the corporate world are used to being in a hierarchy / chain of command. Decisions often have to go through governance forums and follow long established processes which aren’t compatible with agile projects.

These colleagues also have an ingrained understanding of the waterfall methodology from being part of numerous projects throughout their careers. They therefore expect to see detailed plans, hard timelines, Gantt charts, RAID logs, requirements documents etc. However, this doesn’t mean they aren’t frustrated by the lack of pace of change and won’t be open to different ways. The guys at the top love the progress, the guys at the bottom love getting more involved but it is the middle layer that is the hardest to crack.

Waterfall is still the right methodology in instances where it isn’t cheap to adapt (such as building a bridge) or where it isn’t safe to test (a space ship). However when it comes to creating something for humans then we need to be more insight led to truly understand what the best solutions are.

Source a tweet from swardley

We also need to appreciate colleagues experience of technology projects are reflective of this slide. Other than saying we need to learn from our mistakes they don’t know how to do this as they are hard wired to do projects in a set way.

Years of following a set approach isn’t easy to put aside. Defining outcomes, not outputs is a big change for many.

Source GDS and Matt Edgar

Agile is a big step change that many aren’t ready to take, unless we meet them halfway, as they have made a career out of traditional methodologies

Hippo syndrome is also well established in the corporate world. Most don’t even know they do this and are usually open to an informed challenge but chinese whispers of “MD said it would be great if we had 10,000 blue ones by month end” can rattle down the chain of command and go from a comment to a must have deliverable.

Hippo’s are dangerous and don’t even know it.

There is a huge gulf in the use of insight when making decisions. Again this isn’t deliberate.

The corporate world often has commercial and operational pressures which drive reactive / tactical actions — which can then blur into strategies. There is also a lack of understanding about how much insight is available if you just know how to harvest it.

Agile is set up to do this as part of the team, the corporate world isn’t. This means experience fills the gap on insight and therefore Hippos naturally takes over when it comes to the crunch.

Conclusions and examples

In previous roles I’ve had a bit of budget for research in discovery and then based all decisions on that insight, usually by creating personas and getting a bit myopic. I’d often become the Hippo and at times a bit of an arse because I knew the most about the research.

However, it has been a revelation having a user research as part of a multidisciplinary team. Ongoing insight has shown time and time again that our assumptions weren’t always right and that we have made a better thing by experimenting, learning and iterating. The cost of research has been paid back several times over by not wasting effort on the wrong thing.

On our journey with Funeralcare we have had a great sponsor. He was tough on us to start with and often treated us like a supplier. However after seeing the progress through delivery of real things he quickly became an advocate of agile and user centred design. At the end of the Alpha we did a big show and tell and got asked why we had gone wide but shallow instead of going deep on one thing by the uber Hippo in the room.

Tough question from someone who was new to this way of working but our sponsor quickly stood up and answered the question for us. This gave the answer a lot more credibility as it wasn’t just the digital guys saying it and it showed why it is essential to bring people, at all levels, on the journey to ensure success.

Big corporate beasts like to be fed and this is usually via numerous reports, forums, meetings, plans, working groups, RAID logs etc. However, I have found by showing the thing in fortnightly demos, writing week notes in an open and conversational style, being open about being wrong and sticking things on the wall in our workspace (such as service outcomes, roadmap, user research findings, user story maps and sprint plans) that our stakeholders are loving the transparency — especially internal audit!

Thanks for reading and I hope you found it useful? It would be great to hear any other stories or examples of trying to establish agile in a non agile traditional corporate business.