You said agile ?

The latest success stories of the new economy are often the result of small companies that started in a “garage” environment, relying on highly agile processes. “Small is beautiful” was their guiding principle.

The question that interests us is whether these companies are simply exceptions driven by visionary founders, or whether broader lessons can be applied to the organisation of larger enterprises.

It is interesting to observe that companies such as Google, Facebook or even Amazon have remained flexible and innovative despite their significant scale (respectively 32,000, 3,000 and 22,000 employees at the time).

At a time when both “offshore” and “lean” approaches are highly popular, how should organisations and processes evolve to achieve maximum efficiency ?

When 1 is better than 10

The famous operating system behind the iPhone was developed by only 60 developers, while Motorola failed to create a competing system despite assigning 1,500 people to the project.

This demonstrates that developer quality cannot be compensated for by quantity ; on the contrary, oversized teams often become counterproductive. We have seen projects delayed by several months because of only 15 man days of development work.

Why ?

At the most fundamental level, the developer remains the key unit :

“One good developer is worth ten mediocre ones”
— Study by Sackman, Erickson and Grant

Strong developers produce higher quality code more rapidly. Code quality subsequently impacts testing, debugging, maintenance and upgrade phases.

At the team level, actions are not parallel but interdependent. Skills — or weaknesses — therefore multiply rather than simply add up, and one mistake can slow down the entire chain.

In reality, these dynamics reflect long standing principles found across many industries whenever work extends beyond pure execution : craftsmanship, creative work, analysis and design.

A developer is fundamentally a creator of code, not a simple operator endlessly repeating the same task.

From this perspective, management approaches must evolve accordingly by encouraging initiative and avoiding purely “military style” management based on top down executable orders. While such approaches may work for repetitive execution tasks, they are far less effective when initiative and problem solving are required.

This applies not only to management, but also to technical teams and more broadly to all employees involved in complex projects where creativity and autonomy matter.

Simplicity and lightness

Returning to software development helps explain the success of highly efficient teams.

For many years, software projects were structured around a strict separation between functional specifications and development.

However, describing (“specifying”) software can be almost as complex as building it. Furthermore, specifications are always open to interpretation and are therefore inherently imperfect.

Based on this observation, modern development methodologies aim to minimise the specification phase and merge it more closely with development itself.

This does not mean “building first and thinking later”, but rather limiting upfront planning to overall architecture and interfaces while dividing the project into coherent and manageable sub components.

Thanks to these approaches :

• Facebook releases new versions every week
• Mozilla Firefox shifted to six week release cycles instead of waiting several months or even years between releases

Which organisational tools support this model ?

Teams are intentionally lightweight and accountable, typically composed of :

• A Product Owner, acting as the sole business representative
• A Scrum Master, responsible for supporting the team, managing external interactions and resolving non technical issues
• A small, skilled and empowered development team with a global understanding of the project and the ability to actively contribute ideas

This stands in stark contrast to projects where there are more decision makers, project managers and validators than actual contributors.

We have even seen projects allocating €35,000 to project management for only €5,000 of actual development work.

‍

Embracing flexibility

Specifications should therefore remain lightweight and evolutive, adapting both to development constraints and to inevitable changes in business requirements : they are merely one tool among others in the software production process.

They must be reduced to the strict minimum necessary in order not to paralyse development, while remaining flexible enough to evolve throughout the project based on contributions from all stakeholders.

This means moving away from highly detailed “contract specifications” : reassuring perhaps, but rigid by nature. Since specifications are never perfect, they often become a burden and a major source of the classic client supplier conflicts surrounding delivery timelines.

Specifications should instead support dialogue and help communicate the product vision to developers. That dialogue should continue until delivery itself.

Detailing everything does not guarantee success

This lesson extends far beyond software development.

How many ultra detailed project plans fail from day one ?
How many fifty page contracts are barely read and ultimately become useless once a fundamental misunderstanding emerges ?

Detail creates reassurance, but also increases the risk of losing sight of what truly matters.

Is the 25th decimal of π correct ?

π = 31.41592653589793238462643383279502884197169399375105820974944592307816406286208998628034825342117067 ???

I will let you verify it…

The culture of simplicity is extremely difficult to achieve. Simplicity is highly complex.

[
\frac{1}{2}gt^2
]

\frac{1}{2}gt^2

You may remember this formula describing falling bodies. It took both Galileo Galilei and Isaac Newton to formulate something so simple : imperfect because it ignores air resistance, yet sufficiently accurate in the general case.

Not everyone is Newton. But by seeking simple and concise results instead of producing two hundred page documents, organisations are far more likely to move in the right direction.

The client supplier culture

The internal “client supplier” culture undoubtedly brings benefits. It can improve process visibility and enable the breakdown of projects into intermediate deliverables.

However, in many cases, it also generates additional costs through the accumulation of requirements and poor understanding of other teams’ constraints. This is what we call technical complexity.

“The product is too expensive because the procurement department failed to negotiate the right price. They didn’t respect their SLA !”

Of course, what was forgotten is that the requested 3 metre length was only approximate, and that the standard 3.02 metre format would have worked perfectly well.

“I specified one column for the month and another for the date. It wasn’t exactly what I wanted, it delayed my project by a month and now I can no longer change it.”

Does this sound familiar ?

Co creation between marketing and development teams is fundamental to overall project efficiency. Discussions around interfaces — whether software or physical — should always be negotiated collaboratively rather than rigidly specified.

Iterations

Alongside flexible specifications, iterative processes adapted to change become essential.

Software is therefore developed through successive and periodic increments known as sprints.

At the end of each sprint :

• A validation phase takes place
• Something tangible and deliverable exists
• New functionalities may be introduced
• Existing code is optimised through re engineering
• Sprint reviews help prepare training, improve processes and facilitate internal knowledge transfer

Sprints typically last around fifteen days, although duration may vary depending on the project :

• Two hours for preparing a presentation
• Several weeks for a large industrial project

The right duration balances the ability to quickly produce something concrete with the stability of requirements and the flexibility available for interpretation.

‍

These methods can genuinely inspire projects as diverse as preparing a seminar or launching a new product.

We have seen clients requesting half hour detailed schedules for a three day seminar, even though it was obvious that the programme would need to adapt continuously to participant reactions.

Estimates are always wrong

At the start of a project, estimates are absolutely necessary, but inevitably inaccurate :

• The project scope is not yet fully defined
• Difficulties are not yet visible
• Estimates are often produced by management or marketing rather than operational teams
• Results from one project or team are transposed onto another without accounting for their specific characteristics

Project uncertainties challenge both our rational thinking and our natural optimism. Yet technical challenges, changes, delays and mistakes are unavoidable.

If none occur, one might legitimately question whether the project is creating any real value at all.

Unpredictability must therefore be accepted and managed by estimating smaller project portions and regularly revising forecasts.

Right first time

The question of quality then becomes central.

“Right first time” is always far superior to “statistical quality”.

If a shampoo bottle is immediately removed from the production line because a simple sensor detects that the cap is not properly sealed, the issue can be corrected instantly, guaranteeing near perfect quality at low cost. Achieving the same result through retrospective quality control would be impossible.

How can this be operationalised ?

First, through culture :

• Avoid the mindset of “we’ll fix it later”
• Whether it concerns a spelling mistake supposedly caught by spell checkers or a critical bug expected to be identified during testing

Teams must also be protected from “crunch mode” : intense work phases aimed solely at meeting deadlines. Increased pace inevitably leads to lower quality, which itself creates additional delays and rework.

Immediate controls should be implemented :

• Consistency checks
• Validation of iterations by the client
• Continuous review mechanisms

Tools must also remain clean and readable. Software code should be as clean as the workstations inside Toyota factories.

Peer reviews — whether for designs, code, presentations or business cases — remain highly effective. People naturally pay more attention when they know their work will be reviewed by others. Out of respect for colleagues, they deliver cleaner, clearer and better structured material.

The return on investment is usually immediate.

Monitoring and investment

Finally, one of the core principles repeatedly highlighted in management and personal organisation literature : prioritise what is important over what is merely urgent.

If we once again take inspiration from software developers, those who remain ahead are the ones constantly monitoring advances in the state of the art. This enables them to select the right model, tool, language or framework depending on the specific problem to solve.

It is often more reassuring to spend time addressing daily operational issues, while monitoring and long term investment may appear more uncertain. Yet it is generally far more effective to permanently solve a problem — by identifying an existing solution, automating it or delegating it.

“Teach a man to fish and you feed him for a lifetime.”

Even if identifying a sustainable solution initially takes two or three times longer than simply fixing the immediate issue, the return on investment is usually extremely rapid.

Ultimately, the apparent “agile revolution” in software development offers valuable lessons for the management of many different types of projects.

One could argue that it extends the continuity of “quality” methodologies that emerged during the 1970s. However, these quality approaches were so often misunderstood — generating countless reassuring binders and manuals quietly sitting untouched in cupboards — that we felt it useful to revisit these more “disruptive” methods capable of bringing a new product to market every week instead of every year, and all without additional cost.

— Morand Studer

[1] The 25th decimal is indeed correct, but of course you noticed that the decimal separator itself was misplaced.

‍