How To Make a Success of Going Agile

In June 2020 Mind the Product published a post from New Zealander Anthony Marter that really struck a chord with our community: based on a talk he’d given to Agile Auckland, his post argued that product management in an Agile practice is in dire need of a rethink. It’s been one of our most-read articles this year, and Anthony is still contacted on social media about it from time to time. These contacts always spark interesting conversations, he says, so we thought it was time to explore the topic further with him.

Anthony has worked on tech products for a long time. A lead organiser for ProductTank Auckland, he now works as a product leadership consultant, but his career spans 20 years or so and has seen him tackle software developer, product owner, product manager and head of product roles. After jobs in software development post-university, he got his start in product management at the Auckland office of Fiserv, a global provider of financial services technology.

Organisations adopt Agile for lots of sensible and admirable reasons: such as to increase their speed to market, to increase team productivity, and to be more responsive to customers. But in practice, as Anthony explores in his blog post, ‘Why we Need to Rethink Product Management in an Agile Practice’, the anticipated transformation can fail to materialise. He thinks that the way in which organisations have adopted Agile practices is at the root of the issue, because they fail to address the cultural shift needed to implement Agile – as his post says: “The focus is on how the engineering team works… but this focus fails to speak to what the team is working on – the product or products they are responsible for, and the customers that the products affect.”

All About Process

Agile tends to first be adopted in the development function of an organisation after a poor experience with waterfall projects, Anthony says, and the usual procedure then is for the development team to bring in an Agile consultancy who tells them they need to do stand ups and so on. “They approach Agile from a process perspective, not really instilling an understanding of the theory, the thinking, or the principles.” And then, of course, product people are stuck in the middle because they have a leg in the development function and a leg in the rest of the business: “It’s a pain point I’ve really felt as a product person, when the development function was trying to be Agile and the rest of the organisation was not,” he says.

They approach Agile from a process perspective, not really instilling an understanding of the theory, the thinking, or the principles

Anthony believes that Agile consultancies are trying to do the right thing – but usually, they have been brought in by the organisation to solve the wrong problem. “The most common reason I hear for adopting Agile is to ‘go faster’ – organisations think that speed comes from better processes, but speed actually comes from getting the best outcomes for customers and not from building things that customers don’t use.”

How About a Fifth Agile Principle?

Anthony wishes there was a fifth Agile Principle – ‘We value outcomes over outputs’: “This principle would make the lives of product people so much easier as it’s at the heart of the culture that enables an Agile mindset,” he says. Changing company culture so that an Agile mindset runs right through the business is tough, and it’s something that Anthony is often asked to address in his consulting work. “Part of the problem with business transformations is that people don’t know what good can look like.” He starts by presenting his clients with a vision of a mission-driven team that has “completely bought into the problem and the outcomes they need to get for their users” and uses the brains of the entire team rather than depending on one individual to come up with ideas. “I present this vision and then give them some examples to work through,” he says.

One of these examples is taken from Anthony’s early experience as a product owner. What he had asked the development team to build looked like it was going to take longer and be more expensive than he’d first thought. He says the development team’s Agile coach saw his dismay and suggested that he leave the problem with the team to try and solve it for the outcome he wanted. A couple of days later he was presented with a solution that wasn’t quite as elegant as the one he had envisaged but did the job much more cheaply. “It was a real eye-opening moment for me,” he says, “it made me think ‘why am I prescribing the solution to the team, they’re way smarter than I am’. It made me think that I needed to really own the problems, and bring them to the team, and not just bring them bits of a roadmap.”

We Don’t Share Problems

It’s hard to do this, Anthony observes, because humans are driven to find solutions rather than share problems. There are no quick fixes to making the changes that let a team become autonomous, though he makes use of common frameworks like the 5 Whys to try to get people to think differently. He adds: “It’s very situational. You have to really drive home to stakeholders outside engineering that you don’t get as much out of the engineering team as you could if you just give them solutions. It means getting people to continuously think about whether they’re talking about a solution or talking about a problem.”

Anthony is currently enjoying his work with a leader who’s working hard to adopt this mindset. Says Anthony: “He has a remarkable amount of self-awareness and is always asking me if he’s being a ‘HiPPO’. It’s this kind of awareness that you need to generate – to keep asking ‘am I just dictating things to the team or am I really bringing the team into the problem that I’m trying to solve, am I sharing the problem?’.”

He’s also working with an organisation that’s in the first stages of its path to Agile, and getting stakeholders to think about how their product is made up of both tech and non-tech components. “I’m asking them to consider letting people on the technology team have some influence over the non tech stuff, because the combination of both is what ultimately results in the outcome to the user.” Currently the tech and non-tech aspects are done by separate business areas with no visibility into the overall outcome. If all the teams gain an understanding of the outcome and the problems they’re trying to solve for their users, they’ll be much more effective and engaged than they can be when each just works on one piece of the solution.

As a product consultant in Auckland, Anthony is currently something of a rare breed. There are lots of Agile consultants in the area, he says, but only a handful of product consultants. “There’s no shortage of Agile consultants but there’s also not this realisation that there’s more to it than just Agile, that we need to look at product as well.”

Looking at Agile the Wrong Way

Perhaps this is part of the reason why Agile has been embraced by the C-suite without always being properly thought through. Anthony says: “In the Auckland community at least, if a company announces it’s going Agile and no one from the organisation has been to any of our ProductTank sessions that’s a red flag for me. It tells me that they’re looking at Agile from a process transformation viewpoint, not at how they can add value or get value from it. It’s like that line from The Princess Bride,” he jokes, “‘you keep using that word. I do not think it means what you think it means’.”

We’ve created a community of product people that understands what good looks like, but the trouble is they go back to their day-to-day and see that it can be so much better.

ProductTank Auckland is occasionally a victim of its own success, he adds. “We’ve created a community of product people that understands what good looks like, but the trouble is they go back to their day-to-day and see that it can be so much better. I regularly have frustrated product managers coming to ask me to help them.” His approach is to get them to think about the minimum they can start to address. Metrics often resonate strongly with the C-suite, so he suggests frustrated product managers start using them to change company thinking. “If you start to measure your outcomes and report those back then you can start to change the language of the business away from sprints and shipping and so on. The jump between problem and solution happens in a very small layer of the organisation, in the C-suite or business leadership areas. They typically respond strongly to metrics, and metrics can enable you to circle back and question what’s trying to be achieved with a solution.”

Dealing With Disillusionment

One common effect of a failure to instil Agile thinking throughout an organisation is that engineering teams become disillusioned feature factories, building features and products without any input or understanding into why they’re building them. How do you deal with such disillusionment? Says Anthony: “My conclusion here is that often engineering teams become disillusioned without knowing why. Some of the more mature engineering teams understand that if they had been able to buy into the outcome they were trying to create then they would have been more engaged. It’s about getting everyone to think in the same way so that there’s an understanding that everyone is interested in and cares about outcomes.”

After all, getting the best outcome for the user is what it’s all about, and it’s also the part of the product process that gives Anthony the greatest satisfaction. “For me the best part is seeing that the thing we did made a difference,” he says. “That’s why metrics and measurements are such a big thing for me, and I love getting teams as enthusiastic as I am about creating that ‘aha’ moment – the moment a user has when you change something that’s been a pain point for them, and suddenly it goes away.”

Tips for Meeting the Challenge of an Agile Implementation

Anthony’s top suggestions for product people dealing with challenges in the way their organisation has “implemented Agile” are:

• Shift the conversation to outcomes – just getting teams and stakeholders to use this language can move the culture
• Help teams to understand what they will measure and learn from shipping a thing – and get them the assistance they need to do this
• Find the point in the organisation where problems become solutions – and try to shift that point as close to the teams as possible
• Coach stakeholders on what a good problem statement looks like – and why staying out of the solution is important to engineering teams
• Don’t give up – find your local ProductTank meetup group and get support from other product people who are all having the same challenge