Are your experts up for the agile challenge?

Are the Subject Matter Experts in your organisation ready for the agile challenge?

To be clear (because clarity is critical in all-things-agile), I don’t mean “are your experts ready for the challenge of agile”… I mean “are your experts ready to be challenged, as they certainly will be if they work in an agile environment?”

Most people in corporate Organizations defer to the advice of experts:

“Well, Legal said we have to do this, so it’s not my fault if they’re wrong”.

Actually, it is. It’s everyone’s fault. Product stakeholders (i.e. everyone involved in defining and developing a Product) should be prepared – and actively encouraged – to challenge all opinions from any expert in any role. Conversely, SMEs asked for their advice need to be open to being challenged on their advice.

Why?

Their advice might be wrong (Shock! Horror!).

Even the best Technical Architect in the role can’t keep up with every new development and every Technology in the world. Even the best Legal & Compliance expert might not be aware of some obscure regulation or loophole. Even the best Operations expert might be blind to different processes used in different environments.

But, much more importantly, challenge is an opportunity to learn:

• If the original advice is correct, it is an opportunity for the SME to help the Product stakeholders understand why, and learn from that process.
• If the original advice is not correct, it is an opportunity for the SME to learn.

In other words, whenever anyone is challenged to support, explain or even rethink their expert position, it is guaranteed that at least some stakeholders will learn something. That is always a good thing.

In agile, because the goalposts are always shifting, everything & everyone should be open to challenge at every step along the way. What might have been right 5 minutes before a Sprint started might be different 5 minutes later. For example, the sudden Russian invasion of Ukraine resulted in a lot of new restrictions on sales. If an eCommerce platform was in the process of developing support for Russian customers, that changed overnight.

Most Organisations have ‘experts’ in a variety of fields. Some Organisations have teams of experts. Some even have whole departments full of experts. The most obvious and perhaps most common include:

• Legal & Compliance experts
• Experts in the relevant sector or domain
• Technical experts, especially in Organisations with complex technical environments.
• Customer and User Experience experts.
• Operational or Process experts.

Generally, in agile environments or where products are developed in an agile manner, experts may expect to be consulted at any time throughout the Product lifecycle (which, in case it isn’t clear, begins with Product or Service ideation and continues through to Product or Service retirement).

⁃ It could be asking Legal & Compliance if the proposed Product or Feature could potentially fall foul of Regulations that have been announced but not yet even come into force.

⁃ It could be asking the Marketing, Customer Success or User Experience experts if the proposed Product or Feature is likely to make sense for customers and users, even if the Product is already in the process of being developed.

⁃ It could be asking the Technical experts how to implement the proposed Product or Feature with the current technical stack, what changes might be required and what their wider impact might be.

⁃ It could be asking an Operations or Process expert if the proposed Product or Feature creates a gap in Organisational processes or could cause problems with existing processes (e.g. Support, Billing etc).

⁃ It could be asking the Executive stakeholders if the proposed Product or Feature fits in with Corporate Strategy and is more, or less, potentially valuable than something else on the roadmap.

Only by taking all relevant advice from all relevant experts into account, can the best Product be developed. Some advice will be taken and followed. Some advice will be heard but not followed. Some advice will be partially followed. Some advice will lead to more iterations of questions and answers.

That’s what agile Product development requires.

⁃ Legal and Compliance experts don’t define the Product. They interpret the rules and regulations a Product must abide by and what will happen if it doesn’t. Product stakeholders use this to decide if a Product or feature should go ahead.

⁃ Customer and User Experience experts don’t define the Product. They provide an expert opinion on how the Product could be best realised for User and Customers.

⁃ Technical Architecture experts don’t define the Product. They specify how a Product can be technically implemented within the current technical capabilities, or what needs to be changed to realize the Product.

⁃ Operations or Process experts don’t define the Product. They provide an expert opinion on what impact the Product will have on operational processes.

⁃ Product stakeholders define a Product. Everyone else makes it the best Product it can be in the circumstances.

In an agile Product environment, experts will often be challenged to find a way for the proposed Product to be defined, realised, implemented and supported even if that means rethinking their initial reluctance (i.e. “disagree, then deliver”).

It is not acceptable for an agile Product development team to say “Well, Legal and Compliance said we have to do this, so it’s not my fault if they’re wrong”.

Equally, it is not acceptable for any Expert to say “You can’t do that” and not expect to be challenged to say “Here’s what you could do”.

In reality, the right Product is to everyone’s credit and the wrong Product is everyone’s fault.