It’s been about 12 years that I’ve been working in “agile” environments. Currently being open to work (feel free to reach out), I’m getting the chance of discussing with multiple teams from multiple companies, and to try and understand how they work, and where they struggle. One thing especially seems to worry people, funnily enough: words.
Why we’re doing product management
Product management, even though the likes of Marty Cagan (author of “Inspired“) have practiced it since the early ’90s, is still a rather new thing. In France, in 2011 I remember a “chef de produit” (product manager) could be right what we’re talking about, just as well as someone managing a retail store’s area. And today, we still see many companies struggling to adopt product management. Small teams and start-ups aren’t sure when they should start having a dedicated role for that. Scaling teams wonder how that initial person in charge of it all can be “split” into many more, with more and more specialized missions.
Product management is here to supposedly help and find the product/market fit, from understanding user problems to developing solutions with engineering, and “going to market”. All of that needing extensive internal communication and alignment of everybody involved in the product. That is to say, actually everybody in the company.
A key pain point to heal
Now where we probably overlook far too often the interactions of product management with marketing and sales (hence the growing “go-to-market” product roles), one key interaction has always been between product and engineering.
No matter what’s the background and education of product managers, I define them as being engineers in the broad sense of the term. It doesn’t mean that they should belong to the engineering departments (else we wouldn’t see this role growing separately over the last decade). They’re engineers in the sense that their role is to deeply understand a problem, and its root causes, envision and sometimes build, a solution with the support of a wide variety of skills (not only theirs).
This is often the source of misunderstandings and deficient collaboration between product and engineering. Who’s “in charge” of building the product? Where do we draw the line in the definition of what should be built, by who? Product should give enough briefing so that engineering can do the work, but not too much to avoid drowning them in details. Product should give guidance as to what should be built next but should avoid overloading engineers, and even sometimes should plainly avoid taking any assumptions on how much of that load engineers can take.
Methodologies to the rescue, or not
(Spoilers) That’s where we all fail (end of spoilers).
Methodologies are here to help us fix those problems. The great thing is: there are plenty of them, which have been developed for years by very clever people. You can name the old-fashioned ones like Waterfall, Extreme Programming, Scrum, BDD, SAFe, and more recent and holistic ones such as Shape Up, and the famous model of Spotify.
Each of these methods defines roles, responsibilities, workflows, and tools. Many even have their semantics, up to a full dictionary. They provide a framework that the team can rely on so they don’t get lost and become inefficient while trying to build something together.
Methodologies cannot solve human problems
There’s one thing that all of those have in common. They’re like Jira. Some will love it. Many will hate it. They’re like a tool. A tool never solves anything on its own, if you pick the wrong one, or use it incorrectly.
The problem that we’re trying to solve here is a human problem. It takes humans to solve it. Nothing else.
Did you know that the famous Spotify model wasn’t even fully adopted by Spotify?
Somewhat of an ellipsis, but I see this as rather close to all of the companies who openly publish their “values”. While I love the intent, and strongly believe there’s a need/problem that needs to be solved here, I’m pretty sure such values are most of the time an objective that companies set for themselves, rather than an achieved culture.
Both the methodologies and the cultures should not be seen as absolute truth. They can be something you want to get close to. And very often, because they’re imperfect, you should avoid embracing them fully.
My own experience with it
I’ll be honest and transparent. When I started working at SensioLabs/Blackfire, I tried to introduce Scrum, with which I experienced amazing success at Traveldoo. It was a huge failure. For many reasons, there’s been a lot of pushback, and not only from the engineering team. For a while, we went back to the “Méthode à l’arrache” (©fabpot), which is something probably close to Extreme Programming. With much pragmatism.
It worked extremely quite well when we were a very small team. And as soon as we started hiring again, the usual issues arose. Progressively, we started introducing Scrum elements. We never dared to call it “Scrum”, as the simple name of it, as some of the team members would instantly go through the roof, but it was somewhat close to it.
We had built our methodology.🍾
I even started considering writing about it and naming it the Blackfire Shuffle. For no other reason than giving it a fancy name, and because I’m a fan of the Kansas City Shuffle technique (Lucky Number Slevin).
Enough with the fancy words
But what value would it have brought?
First of all: I haven’t checked extensively, but I’m confident many other people have also published their own “secret sauce’s” recipe (not so secret anymore, right). So there’s a high chance nobody would care about ours. And if by hazard we would have had readers and adopters, they would be juggling with something that was not built for them.
Second: words! It would have been just new words, on the same core issues, and a very similar solution. Just using fancy words over it give the impression that a new dogma was born, to be followed by the book. And that the book should be blamed for when other teams wouldn’t be able to make sense of it!
Blaming the book is very often the easy thing to do. In the end, someone or something must carry the blame, right?
There’s one thing that I find rather disturbing: how few people know the very root of Agile.
Stop trying to reinvent the wheel
Oh yes, “Agile” is a fancy word. And the root is a “book” or a “dogma”.
But contrary to any of the famous methods we’re all hearing about those days, that book isn’t hundreds of pages long. Not even tens of pages. It has 4 core values and 12 principles. Nothing more.
Let me put the URL in plain right here, not as a hyperlink over some text: https://agilemanifesto.org/.
For many years, I’ve seen countless complaints that “agile is flawed”, “agile doesn’t work for us”, etc. I’m pretty sure that most of the time, people referred to an agile methodology, which they tried to adopt while it wasn’t built for them.
What finally made us successful with Scrum at Blackfire is to not call it Scrum. It is to avoid adopting each and every line of the Scrum Guide. It is to be agile in how we adopted an agile methodology. We fully embraced the first Agile principle: “Individuals and interactions over processes and tools”.
Dump the rest?
Don’t get me wrong. I’m not pretending that Shape Up, Spotify’s model, or any of the famous ones are worthless. They’re great to read and learn about: there are always tons of great ideas you can take inspiration from.
But they should be read as an essay, a post-mortem, or a philosophy, not like a pastry recipe that will fail if you miss a gram.
Most of the time, you should end up adapting it, rather than blindly adopting it.
Christophe Dujarric 