Articles Thoughts on agile and design processes

Fitting Agile into a wider Design process

Originally published on Linkedin 16/11/2024

Robert C. Martin posed a great topic in the video What happened to the agile movement? Uncle Bob. He ponders over how Agile, an inherently engineering-driven methodology, has been "taken over" by business people like product managers.

He wants to reboot Agile back to the engineering craft method it originally was.

But while it's roots in engineering, Agile has been pulled down over other competences like Research and Design as the only truth.

It is not.

It is a great tactical delivery method, but it is one cog in a bigger system and you spot this immediately when you look at it through the lens of other competencies.

Agile through the lens of the Design process

When looking how Agile fit into any design process, it quickly becomes clear Agile only really fit in the latter part, the design production phase when things need to get done.

Think of Agile in terms of car manufacturing.

Agile is the assembly line where each part of the car is assembled individually and brought together to form the finished car.

But where did the overall blueprint come from?

Somebody had to design the actual car from idea, to sketch, to prototype, to testing (and failing and testing again), to documentation and other reference materials.

Without this, each part of the car might work fine on its own, but can you imagine the car they would become? A blue car door trice the size of the red door frame. Wheels too big for the wheel hubs, A perfectly formed engine.. that is smurf-size compared to the rest of the car.

This is ofcourse utterly nonsense, yet this is often what we as a digital industry do.

Upfront, top-down design

Scary headline. Very anti-Agile.

Not really.

We can see it is not a zero sum game as soon as we accept Agile isn't the the only truth and that it is in fact a single cog in a system.

Drivers don't care which team did what part of the car, they care about getting from point A to point B.

And all end-users are like that. They don't care who created what part of a solution or how good it is on its own. They care about the over all experience:

Those are not my words by the way. It is the ISO 9241 definition of Usability.

The time and resources need to be planned and invested in crafting the blueprint, the overview, the end-to-end experience, before the Agile delivery machine starts to run.

Not investing in this upfront, top-down design and research work leads slower delivery (due to lack of clarity) and lower quality product (due to lack of single model to reference).

Don't wait for the next iteration of Agile

The value of doing design right is not new. Yet when pressure is on, we cut corners only to make things more difficult for us in the medium to long run. It is a vicious circle.

While Dr. Susan Weinschenk talks about how the cost of fixing an error after development is 100x, I'd argue in many cases they cannot be fixed or will not be fixed as unfortunately as soon as it is live, the next feature is knocking on the door to be developed and released.

But the good thing is that the digital industry is still very young industry where nothing is set in stone yet. We are not bound to methods formed over 100s of years.

You can change it. You, your colleagues, your team, your company can change how you do things.

Stop for a second.

Think about it.

Be smarter.

Do what we as humans do best: Evolve.


Latest articles

See older articles