Agile With a Capital A Might not be Best by Morag McClaren [Mind the Product]

Often our role as Product Managers is to be a translator between the business and delivery teams. Here Morag McLaren looks at a few things she’s learned through this process when it comes to Agile.

Don’t Forget the Other Parts of the Agile Manifesto

Most people’s perception of the agile manifesto is that it tells us to do things fast and regularly. Whilst to some degree true, what is often forgotten is the final sentence. The group of people that came up with this way of working weren’t saying that there was no value in how things had been run before. They were simply saying that, for their context and roles, the newer approaches delivered benefits quicker.

The Highest Priority is to Satisfy the Customer

Underneath the often-quoted manifesto is a set of principles that were important context for the creation of these new ways of working. The first of these is that, for developers, the highest priority is to satisfy the customer through the release of software. This principle is often missed.

It is assumed that the understanding of users and how to solve their problems is the sole role of UX or the product manager. Good developers know this isn’t the case and get just as involved in user research and problem solving as they do working out how they’re going to build a product.

As Teams Change, so Should Your Ways of Working

In the same way that our products develop based on changes in their market, so do our teams. When people rotate or the business context changes, we need to be comfortable with responding through our ways of working. Just because something worked in the past doesn’t meant that it’ll work in the future, and it shouldn’t be clung to dogmatically.

Have the confidence to change your ceremonies, artefacts, and behaviours constantly.

Don’t Assume Everybody Understands or Agrees With why You’re Moving to Agile

If people don’t understand the needs behind a change, then they can’t possibly be committed to it. Even in existing ‘agile’ teams, the reasons for adopting such a process are often misunderstood.

Additionally, if people can’t explain the alternatives to a way of working, then they probably don’t understand the available options well enough. As such, take the time to discuss why agile might work but, just as importantly, look at the alternatives.

Ask People About the Crap Bits of Their Jobs

If you just go ahead and implement agile ways of working, people will see it as adding more processes & workload added to their plates. They won’t understand the reasons behind it or see the benefits of doing so.

If you start by asking people what frustrates them about their roles, and look to solve these issues, then you’re much more likely to bring people with you. By taking this approach, you’ll end up being able to bring in agile practices without necessarily ‘doing agile’ – but it’ll be much more effective and stable in the long term.

Keep Communicating and Assume Nothing

No matter how well established you and your team are, you need to keep talking. Sometimes you’ll be tempted to slip into shorthand or assume that things are working as they need to, but try and avoid this.

Constantly ask for feedback about how things are going. Ask yourself whether a new member of a team would understand the conversation that’s currently being had. Make time to discuss as a group where further improvements can be made, and remember to keep iterating.

The post Agile With a Capital A Might not be Best by Morag McClaren appeared first on Mind the Product.

Source: Mind the Product http://www.mindtheproduct.com/2018/08/agile-with-a-capital-a-might-not-be-best-by-morag-mcclaren/