Value analysis and technical dive-ins

Over the years, I encountered Agile methodologies or their different implementations in as many teams.

With time passing, it's interesting to live, hear and read about success and failures and the (often) inevitable push-pull between "business" and "engineering" when those are seen as different and in opposition.

So this week, I decided to dig into the topic, partly motivated by a couple of meetings with old friends and the random encounters I had with posts on the subject.

This was originally posted on our parent company's blog: https://blog.imfiny.com/value-analysis-technical-dive-ins/

Tweets to start

As often every week, I encountered a few tweets by A. Holub, including this :

A. Holub has an excellent way of always bringing us back to the core of our work: talk. It's evident in many other of his tweets and writings.

There are many to pick from, but this one is a good example.

The ideas I want to keep from those two are the following: talk, get a good idea of what your users actually need now. Or, as he pointed out in another tweet :

Agile:

• work small
• talk to each other
• make people's lives better

This is a great, succinct way to explain what Agile is in the end.

Taking a step back

As a Tech Lead, I often talk with both engineers and non-engineers and try to help proper agile dynamics appear and evolve in teams.

Developers tend to lose most interest and ownership in anything they do as they become cogs in a chain whose role is to get through a wishlist named "Backlog". It's often tough as many don't really have a being Agile (as described above). Instead, teams tend to fall back on extensive Backlogs with their refinements, sprints, sprint retrospectives, etc.

A shame as Agile and Extreme Programming aimed to avoid this by keeping everybody involved in building the product aware and responsible for what the product is doing for the users.

Thankfully many of us are aware of this issue, and we are pushing and doing things differently. Mr. Holub is an example, as are so many others.

Talking with an old friend who recently joined Qonto, I discovered an exciting take on how to actually bring an approach that values both business and engineering time and effort.

From a bank

Chatting about Product Management, he told me about how they work and how it's documented online for all to see.

Among several posts, I found What makes great product managers: the case for learning, Value analysis: starting development later to deliver sooner, and Value Engineering: designing products that sell.

These are, in a way, an elaborated description of how to build features that matter. I can't be helped but to hear a dilated echo of A. Holub's words in there. That is :

"Talk, get a good idea of what problem exists for your users, figure out the value of solving it for your product, figure out how to solve and what it will cost to do so, and if it's worth it."

That does sound good. Yet, this is mainly from the Product Management perspective. I was wondering about how this translates for the engineering side of things.

Their CPO chimed in through another post: Reintroducing engineering thinking in the development world.

And the engineering approach is indeed complementary to the product management one. M.A. Lacroix covers quite some ground and starts by striking down Scrum, reminding us that the "early" Agile methodologies and approaches were more about communication and engineering thinking than pure management and output.

But the central part is the one about the Technical Dive-in :

What we call a dive-in at Qonto is a phase in our feature development process between the specification phase (what is the product problem we are trying to solve and what is the functional solution we propose) and the development phase (where we slice the work in small tasks and start coding).

This phase is mandatory and is a time when developers only dive into the code base, think about the way they want to technically conceive the feature, about the implications of what they are going to do, answer all the problems they might face, go talk to other stack teams, do a POC if needed…

Once the conception is done, the devs then push a merge request to the team explaining what they want to implement with diagrams, schema, images, pseudo-code or concrete examples of what modifications they want to implement (e.g which fields I am adding to a database with corresponding types). This solution then needs to be validated by the members of the team. Only once this process is done, then the developer starts coding.

Summing it up

This approach from Qonto, interestingly worded in those posts, is certainly not unique.

If not "natural" for some, it's undoubtedly ingrained and a deep wish. Yet, rare are the companies and individuals courageous enough to go against decades of formatting and habits that have rendered ubiquitous a tasteless approach to product and engineering.

We could sum up the approach to the following points:

• talk with your users, with your team
• figure out what is the problem of your users
• figure out what could solve that problem and what value this would add to your product
• lookup and prepare an overview of what the technical solution would look like
• evaluate the cost of the presented solution and decide if it's worth it now
• implement, release

It's fascinating to note that part of what is considered in the cost is the time needed to implement the solution, and if it fits within the time frame, we want to give ourselves to do it. It's not a matter of setting a deadline. It's a matter of checking if the work will fit within an allotted (time) budget or not.

Epilogue

I really enjoyed reading and pondering those few articles. It's refreshing and recharging to read about such an approach and that it's actually bearing fruits at Qonto and other companies.

I would recommend many from Senior Engineering roles to CTO, CPO, and CEO to read those articles and reflect on the difference in their current approach.

Books to read

Soon to be added to my pile of books possibly:

• Learning to Scale by Regis Medina