Why the subject is no longer to adopt agility but to change product culture

I recently had to fill out a questionnaire on our project management methods at Malt.

I found myself being stupidly annoyed by the questions, questions whose philosophy seemed to me to date from another age.

The goal was to know if we were really agile, and to find out, each question related to a specific practice of Scrum and Kanban methods.

The question today is no longer whether we are agile or not, a term very widely misused everywhere.

Agility is proclaimed everywhere but is often confined to the delivery leaving the rest of the company in a more archaic way.

We must go further now, Agile is supposed to have been understood. It is time to really talk about how we make the product from the phases of discovery to delivery. And we have to get out of the logic of inflexible anti-agile roadmaps to move towards strategies by objectives and key results (OKR).

Agile is dead

consulting firms in the face of the changing hype

Like all buzzwords, agility has been the universal answer to all problems. Agile was the new 42. And like every buzzword, it ended up being misled, exploited, overexploited to the core by armies of consultants to sell agile transformation all over the place.

Hi SAFe and certified trainings !

I could also mention some implementation drifts where agility was the pretext to set up people monitoring(daily meetings, time tracking on tickets).

But on that I would only say one thing, that is related to your company. When a company is toxic, any good method can turn bad.

The hype has fallen a bit and now, conversely, the hype could be to assassinate Agile.

But, even if Agile bothered me in the recent years, it would be a shame to throw the baby out with the bathwater.

Agility is not reduced to its formalism

In the famous questionnaire I was talking about above, I noted that the questions were mainly about formalism:

• the presence or not of user stories
• how to write them
• story point costing methodologies
• the definition of done and what it included
• monitoring of burndown charts

etc ...

As if agility, the manifesto of which was signed 20 years ago, had not changed. These methods have remained set in stone (or immersed in mothballs) even as these original authors insisted on adaptability and continuous improvement .

Adopting "by the book" methods without taking a step back from the substance does not bring much, except obtaining the "agile" label which then allows it to be put everywhere in your corporate communication. Except that, one can be perfect on the formalism and yet be very bad in practice at making the product.

You would think I have a grudge against agility and that would be wrong.

I have been practicing agility since 2007. I even was an agile coach for 1 year on a company of 120 people in 2010, even if it was not the best experience of my career.

But today I saturate ad nauseam with topics around agility that only focus on formalism without understanding these principles and without talking about key results.

I also saturate on serious games, or conferences that only scratch the surface of things led by certified consultants with no product success .

Let's take out what can be

I am far from throwing everything away. Many agile methods give tools to adopt and adapt for your own organization and some methods are very effective.

However, now:

- Is the topic still on the adoption of agility?

**No.**Everyone claims to be agile. Companies are agile, teams are agile, communication is agile.

We have certified trainings, announcements for Scrum master (a role originally, not a job). Agile is adopted and you no longer see a company saying it is not.

- Is the subject to always have more process to bring agility into the business world?

Not . Agility is satisfied with minimal formalism and must be constantly adapted. The more we let the consulting firms do it, the more it drifts and we end up with frameworks like SAFe (Shitty agile framework for enterprise as Martin Fowler would say)

In short, the vast majority of product teams know about agility. It has now been taught in school for at least 10 years. The majority of large companies have armies of agile coaches practicing in their teams.

The subject is to refocus on the essential, the product that we deliver.

Most product teams are well aware that agility is often confined to delivery, the phase at the end of the chain.

Measure what matters

Agility as a development framework for delivery, ok, I take it for granted. We must stop excessively formalism and let the dev teams put it in place and adapt it to their needs. It is their responsibility.

Do you want to measure your level of maturity? Ask yourself questions about your visible results.

If we're talking about a platform, here's an example of a success metric from "Accelerate":

• Frequency of production deployment
• lead time for changes
• average incident resolution time
• change failure rate

It is then up to the teams to introduce and modify the practices necessary to improve. If a team puts into production every quarter, it is not agile. Challenge it to do better and it should manage to put in place the necessary good practices on its own.

But overall on a product team, you have to measure its performance by its quantified successes.

I literally don't care if a team does 30 story points per sprint.

I don't care if a team always does 95% of its sprint with a burndown chart that fits perfectly to the theoretical curve.

Really.

This is the kind of stuff I want to hear / read:

• we increased step X of the funnel by 10%
• we allowed to do x3 on the traffic coming from SEO
• thanks to this functionality we have reduced by 30% the volume of support relating to these questions
• improved our NPS by 20 points

This is the real measure of your success in the end. Think about the key objective and outcome!

And for that we have to tackle the upstream side of the chain. And this is where the definition of objectives (OKRs), the management of discovery and its linkage with delivery come into play.

If you are new to OKRs, I highly recommend you take a look. I would undoubtedly write a dedicated post on the subject but to summarize, it is the definition of the strategy of the company to contribute to its mission over a given period.

The strategy is broken down into objectives, themselves measured by key results.

It's disarmingly simple and yet very powerful. OKRs make it possible to align the whole of a company with the right priorities, to give visibility to all when the OKRs are broken down by teams and to focus on the result rather than the projects. A project being only a means to achieve a result.

The traditional roadmaps focus on the release dates of a particular feature, the OKRs focus on the achievement of objectives, the problems to be solved.

A feature is an accomplishment in itself, it is an output.

OKRs focus on the bottom line. A feature is only a step and the work does not stop until the objective has been reached, the problem solved.

outcome vs output.

Product Managers vs Product Owners: what actually changed for us

The PO has often been seen as a simple proxy for the "stakeholders" and whose role is confined to administering a backlog while maintaining a balance between the priorities of each.

In short, a jira ticket manager.

He is sometimes also very involved in delivery by working with the Scrum master as a team proxy, but he remains the lead time manager and we often end up with a PO who "manages" a dev team.

The annual roadmaps filled with features are still well established, the PO finds itself in the best possible schizophrenic configuration. On the one hand, the so-called iterative delivery teams, on the other a frozen roadmap, in the middle the PO which taps.

Product management should not be confined to backlog management, stakeholders and project leadership.

The product manager should rely on the engineering team and the Product Designer to ensure delivery and do not deal with it directly. He/She has to focus on adding value, identifying issues to solve to contribute to your business goals, and identifying the solution space with the rest of the team.

You have 7 key skills to develop for this:

• Product Design
• Product Data
• Product Marketing
• Product Discovery
• Product Growth
• Product Ops (org process)
• Product Tech

And finally, review your roadmap process ...

Make way for Discovery

I am going to use a diagram by Marty Cagan which sums up the subject well. You have to go from that:

See conference https://www.mindtheproduct.com/video-the-root-causes-of-product-failure-by-marty-cagan/

to that :

from the same Marty Cagan: https://www.mindtheproduct.com/product-is-hard-by-marty-cagan/

On the product side, discovery is an important phase that allows you to start from these objectives and key results (OKRs) to work on solving problems that are posed.

Discovery consists of constantly identifying the space of problems and then identifying the space of solutions. It is therefore constantly the fact of testing hypotheses (AB Test, interviews, mock-up, prototypes, etc.).

Discovery corresponds to all the activities linked to the identification of initiatives that could contribute to a strategic objective and to the experiments carried out to find solutions.

Delivery then comes in order to industrialize and scale up these solutions. Solutions that will have been validated in discovery.

In short, it is for all these reasons that the questionnaire that I mentioned in the introduction annoyed me. He seemed to contribute to this dysfunctional vision of an ideal product team.

At Malt we have been there but we have constantly questioned our practices. We implemented OKRs 3 years ago now. I would qualify our practice as still young and I think we will make a lot of progress on it.

On the product side, we switched to impact team only a few months ago at the end of 2020, which was very well explained by Johan in his blog post and we are giving lot ot space to Discovery even if there too we still have a lot of progress to do.