Fast delivery

In a world where the unexpected is a daily occurrence, speed of execution is a vital key. It allows us to access the real lockers of a digital project more quickly. The challenge is to provide the training needed to make the trade-offs and find the way of working that makes this speed possible.

Why is it urgent to deliver?

Fast delivery means providing customers with their products or services in a minimal amount of time. It’s a term often used in the context of e-commerce, catering, logistics and other industries where speed of delivery is a key factor in satisfying customers. Whether your digital products and services are aimed at B2B or B2C, your users have instantaneous consumption habits. Between the moment when they express a need and the moment when that need is confirmed, it is crucial to react to their desires and activate a process that will enable them to quickly fulfil their need, because otherwise it may well be your competitor who fulfils their need!

Fast delivery means being able to keep pace with changes in the market by:

• rapidly testing new business opportunities
• building customer loyalty by taking into account customer feedback and enhancing your product very quickly.

How can you involve your sponsors?

Fast delivery means responding quickly to user needs. Therefore, it is quite natural to design using product design methods. Experience has taught us that when these product design phases are carried out too remotely from the sponsors (those responsible for the business vision and the budget), the projects have an unfortunate tendency of getting out of hand because of the following biases:

• reinterpretation of the original vision (we’re not talking about a pivot here, but an error in assessing the target vision),
• difficulty in selecting drastic priorities and making choices,
• wasting time and energy costing out functionalities with a priority level lower than the MVP (Minimum Viable Product) in order to “get the big picture”,
• refusal to accept the simplification of certain functions in order to meet deadlines and budgets,
• deprioritisation of technical tasks or the quality process in order to deliver more functionality,
• administrative slowness, in particular the slow involvement of service providers or slow procurement of software solutions that would speed up product development.

Keeping the sponsor at arm’s length can significantly upset the balance needed to build a user-centric product, within budget and on time.

These shortcomings are often overcome by involving sponsors in strategic workshops and short frequent project reviews. In effect, the project manager and sponsors now have a similar level of information about the project, and responsibilities and decisions are shared, not distorted, and therefore much more pragmatic. Sponsors are invited to become much more involved in development constraints, which means that they can better accept choices and make trade-offs because they have a better understanding of what is involved.

What skills and organisation should your team have?

If you want to deliver value quickly, the technology should not be a problem. Like a musician playing in an orchestra, each member of the team needs to master their own subject: be able to sight-read the score, identify design errors, be able to make input proposals and know how to improvise when the score is incomplete. It’s not out of the question (indeed, it’s a good idea) to form a team with a few juniors, but the shorter the project timescale, the more certain the actions need to be and the wiser the choices. This cannot be achieved without out a certain level of experience in the team.

Why you need to accept technical debt (debt that will have to be repaid as soon as the product is launched)

It’s better to work on technical improvements to existing functionalities than to over-engineer a product that you don’t know will be used. This amounts to creating technical debt.

Designing a technically perfect product from the outset means:

• accepting the risk of endless refactoring of the architecture without any functionality being developed because the improvement of a technology stack is endless;
• accepting the risk of potentially working on the wrong priorities (only in the final weeks will detailed design and implementation have been completed);
• not being able to use a “fail first” approach with which it is possible to test a large number of subjects very quickly and see where the real technical lockers are.

Nothing is possible without a truly agile technological platform

In production cycles spanning several months/years, the following methodology can be observed:

• Draw up a list of requirements
• Identify “off-the-shelf” software packages that fulfil the requirements
• Adapt the requirements to fit the tool
• In the long term: adapt the tool whose use did not correspond so well to the need

In the age of “I want it all, I want it now” and “seamless”, these 4 different stages can be compacted into a timeframe of less than 4 months. That’s why it’s essential to think in terms of a composable architecture.

Conclusion

Key to delivering value quickly are:

• involving sponsors to speed up decision-making and instil product vision in the team,
• having a composable architecture that enables rapid adaptation to product evolution,
• working with an experienced team capable of challenging the scope and proposing the correct trade-offs,
• accepting the creation of a technical debt that can be reabsorbed at a later stage.