10 Ways to Make Agile Design More Effective

“Design is not just what it looks like and feels like. Design is how it works.” – Steve Jobs

The key shift with Agile Design is to deliver quickly while handling changes smoothly.

Stop doing long requirements phases, and heavy documentation up front.

With Agile Design you focus on incremental and iterative delivery, going from low-fidelity to high-fidelity, while getting feedback and improving your design along the way.

With that in mind, here are 10 ways to make Agile Design more effective:

1. Avoid BUFD (Big Up-Front Design)

Big Up-front Design.

Avoid it.

Whenever there is a big lag time between designing it, developing it, and using it, you’re introducing more risk.

You’re breaking feedback loops.  You’re falling into the pit of analysis paralysis.   Focus on “just enough design” so that you can test what works and what doesn’t, and respond accordingly.

2. Avoid YAGNI (You Aren’t Gonna Need It)

You Aren’t Gonna Need It.

Avoid bloat.

At the same time, avoid scope creep.

“Keep the system uncluttered with extra stuff you guess will be used later. Only 10% of that extra stuff will ever get used, so you are wasting 90% of your time.” – Extreme Programming.org

3. Embrace Occam’s Razor and KISS (Keep It Simple Stupid).

Use the simplest solution.  Simplicity always win in the long run.

This will help you stay in the game before bogging your solution down and crippling it’s ability to keep up with evolving requirements.

4. “Test-First.”

If you don’t know the criteria for what good looks like, you’ll have a hard time finishing.

You’ll also get lost among your designs, unless you clarify what your actual test-cases are.

If you keep a small set of useful tests, you can parse through a variety of designs, and find the diamonds in the rough.

5. Deliver iterative and incremental solutions.

An iterative solution would be decorating the living room.

An incremental solution would be adding a porch to the house.

Deliver useful and usable increments, and then iterate on them to improve them based on real feedback.

6. Cycle through alternatives.

Fail fast and fail often.  This is another good argument for being able to do rapid prototypes, and low-fidelity prototypes.

You need to cycle through competing solutions.

Do A/B testing.  Do the Toyota Way and create 3 alternative solutions.   Don’t get wrapped up in finding the “best solution.”

In many cases, your best solution will be found by “satisficing.”  This will keep you ahead of the game, and ready to respond to emerging requirements.

7. Stay customer-connected.

Stay connected with the users who will actually use what you’re making.

Get 5 customers to stand behind it.

Don’t just throw it over the wall down the line, and hope it sticks.  Invite your customers to your side of the wall.

8. Think Big Picture First.

Put the scaffolding in place.

Focus on the plumbing before the interior decorating.

Solve the big challenges first.

Get the big picture, before getting lost in the details.

Optimize the maxima before the minima.

9. Get cross-discipline feedback early and often.

The better you can balance cross-discipline feedback, the more reliable your solution will be.

During the design process, it is important to seek feedback from people with different backgrounds and areas of expertise, and to do so as early and frequently as possible.

This approach helps to identify potential issues and improve the design before it becomes too late or costly to make changes. It also helps to ensure that the design is suitable for all stakeholders and that it meets the requirements of the project.

By involving people with diverse backgrounds and expertise, the design team can gather a broader range of perspectives, insights, and ideas, which can lead to a better overall design.

10. Spike early and often.

Use technical spikes, functional spikes, and user experience spikes to get the risk out.

In software development, an architecture spike is a time-boxed investigation or exploration of a specific technical challenge or risk that may impact the design of the software architecture.

“Spike early and often” means that it is important to conduct these architecture spikes as early and frequently as possible during the development process. This approach helps to identify potential issues or risks early on, before the development work has progressed too far.

By conducting spikes early and often, the development team can gain a better understanding of the technical feasibility and viability of a solution, which can inform subsequent design and development work. This approach can also help to reduce the risk of major issues arising later in the development process, which can be costly and time-consuming to address.

I want to include a few additional lessons I’ve learned at Microsoft over the years, that really support Agile design…

Don’t Throw a Solution Over the Wall

“Don’t Throw a Solution Over the Wall” is a metaphor used in software development to describe the practice of handing off a software design or implementation to another team or department without adequate communication or collaboration.

This approach can result in misunderstandings, misinterpretations, or errors, as the receiving team may not fully understand the intent or requirements of the original design or implementation.

Throwing solutions over the wall can also lead to delays, rework, or increased costs, as the receiving team may need to make significant changes to the design or implementation to make it work for their needs.

The last thing you want to do is throw a solution over the wall, and nobody wants it, or you missed the basic scenarios.

That’s why delivering early helps get the risk out, and helps validate your path.

If you’ve ever watched people argue over how they “satisfied the requirements”, but nobody wants to use it, you know exactly what I mean.

Embrace Show and Shares

People don’t always know exactly what they want, or, even if they do, it’s hard to articulate in a way, that everybody gets it.

But people are way better at recognizing what they like, and knowing whether or not they like something when they actually use it.

Embrace it.

That’s what Agile Design does – it embraces the reality that people get more clarity over time of what good really looks like.

Creating an early feedback loop also forces you to keep your solution easy to maintain and easy to evolve.  Otherwise, it’s very easy to cement your design, and no longer respond to emerging needs.

Design for Change

Design for change is a design approach that emphasizes creating flexible and adaptable products or systems that can evolve over time to meet changing needs or requirements.

The key to lasting solutions is they are built to change.

It’s a process of continuous learning and continuous delivery.

This approach recognizes that change is a constant factor in many industries and that products or systems need to be able to adapt and evolve to remain relevant and useful.

Design for change involves designing products or systems that can be easily modified or updated, using modular components or flexible architectures that can be reconfigured or extended as needed.

It also involves anticipating potential changes and designing solutions that can accommodate them, such as using open standards or interfaces that can be integrated with new technologies or systems.

By designing for change, companies can future-proof their products or systems, reduce the need for costly and time-consuming redesigns or replacements, and stay ahead of the competition by remaining agile and responsive to changing market conditions or customer needs.

You Might Also Like

What is Agile?
Agile vs. Waterfall
10 Ways to Make Agile Design More Effective
Don’t Push Agile, Pull It
Kanban for High Performance Teams
What I Learned About Agile Project Management at Microsoft