How Value Engineering helps us ship predictably

What Software Engineer hasn’t experienced the frustration of rework and the stress of delay? I know I have!

When I joined Qonto a year ago as a Frontend Engineer, I discovered that two of the company’s core principles are right-first-time (no rework) and just-in-time (no delay). I was eager to find out how Qonto translated these two principles into tangible methods and tools.

Recently, I helped create a feature that allows our customers to manage their suppliers’ invoices in one place. Through this example, I will explain what Value Engineering is, how it is conducted and how it reduces the risk of rework and delay.

The purpose of Value Engineering

We start the development of new features by analyzing the users’ needs. This phase is called Value Analysis. Value Engineering comes right after and prepares the next phase, the Delivery, which contains specifications, development, QA and release.

During Value Engineering (or “VE”), we follow the principle of “fixed time, variable scope”. We ask ourselves: “how much time are we willing to invest in this feature?” or, since time is the most precious resource for an engineering team: “how much do we want it to cost?“.

So the input and the output are reversed compared to the ordinary engineering experience:

With this in mind, let’s start the VE!

First step of VE: preparation

Think about the last time a Product Manager came to you with an idea for a new feature. How did it make you feel? You probably thought that the idea was way too blurry for you to start any type of work on it, or even estimate how much of it you can build in the given timeframe.

The goal of the preparation phase is to list all the questions that pop into your mind and to investigate each of them with the rest of the team during workshops.

We did this exercise on a slice of the Supplier Invoices feature: the “manual upload” experience. Only for this specific part of the feature — which was one amongst seven! — we found eight questions that required clarification:

The trick in this phase is to uncover all questions that can significantly impact the design of the feature and its implementation cost. Miss one, and you will pay the bill down the road in the form of delay, rework… and stress for the whole team!

Imagine that we forgot to deal with questions 4 and 5 above. Then we wouldn’t have thought about the user experience when trying to upload a file heavier than 15MB. If we had not identified this point during VE, we would have realized only during QA or, even worse, after the release that this scenario generated an error invisible to the user!

Second step of VE: design

Once you have listed all the questions… time to answer them! You can think of it as a sort of puzzle:

There are several pitfalls in this design phase:

• Not being “divergent” enough (i.e. missing a possible solution that is “out-of-the-box”)
• Making inconsistent choices in each workshop, leading to a solution that doesn’t make sense overall
• Making choices that are inconsistent with the patterns already existing in our product. For example, we have a feature very similar in terms of user experience to Supplier invoices, called “Receivable invoices” (the invoices that our customers create for their own customers). In both cases, clicking on an invoice opened a screen with detailed information. For Supplier invoices, a fullscreen modal with an animation opens. For Receivable Invoices it was a page without any animation, which is not consistent.

Some scope choices generate intense discussions with the Product team. For instance, the possibility of uploading an invoice via drag-and-drop in the page was too time-consuming, so by mutual agreement with the Product team, we revised the scope of the upload experience to focus only on the normal upload button. Drag-and-drop has been identified as a future improvement.

At the end of this stage, we all agreed on a stable design for the solution:

The final step of VE: planning

Once we found the optimal solution, the next question is: “how do we organize as a team to build it?”.

Take a look at this pit stop by the Red Bull Formula 1 team:

Does it look like anyone improvised the role they were going to play? Of course not.

Remember our two core objectives at Qonto: ship with zero defect at the target date. That requires impeccable coordination between all teams involved in the delivery, meaning a shared representation of who will do what, and when. We call this representation a “pull schedule”. It maps out the inputs that each team will provide to the next as delivery progresses.

For example, there is a dependency between the UX Writing team and the Web team. The Web team will only start development when the UX Writing team has provided the necessary translations:

We monitor the feature’s pull schedule during delivery to determine whether we are on-track to meet our launch date and how to react if we are not.

To conclude

This framework sounds pretty solid and our ambition is to finish a Value Engineering in five days for a typical feature. But things don’t always go according to plan! Last week, my newly-arrived office mate told me she had been engaged in her very first VE at Qonto for almost two weeks. She had just become aware of our standards and she is already facing the gap between our ambition and reality!

At Qonto, we define ambitious standards of quality and speed, and strive to draw learnings from situations where we failed to meet them. If you’re interested in using standards to drive learning within your team, you can refer to this article by our Product Principal Thomas.

And if you want to be part of a team that consciously defines its quality standards and strives to attain them relentlessly, consider joining us!