No need to fear Design Reviews — Learn to do them the Agile way

Have you ever experienced the disappointment of realizing you could have avoided a bug in your code had you known something earlier? I am guessing you have. We all have.

Bugs are an inherent part of software development, but you can avoid some of them through the practice of Design Reviewing. Recently it seems that people are doing less design reviews. So perhaps it’s time to explore, What is your relationship with design reviews? Are you doing enough of them?

For many, design reviews lost appeal with the emergence of Agile — in their eyes a design review is something archaic, of the long gone Waterfall era. I would argue they are still as relevant as ever, we only need to learn how to adapt them to current times — do them the Agile way.

My team at AppsFlyer owns the process of ingesting billions of data records daily into AppsFlyer’s data warehouse. We are also responsible for enabling customers to export their data safely 24/7. We use design reviews regularly to meet our challenges. Done properly, they can boost both the team’s and the individual’s effectiveness. They allow faster delivery with lower risks.

In this post I will describe an Agile approach to design reviewing, its benefits and some practical tips on how to apply them in your projects.

Let’s start with understanding the importance of Design Reviews.

The Benefits of Design Reviews

Design reviews are a part of the classic development life cycle for good reason — they are valuable. Here are the main reasons why we are interested in design reviews:

Find bugs sooner (when they are still cheaper to fix)

It is a well known fact that the cost of fixing a bug increases exponentially with detection time. In other words, fixing a bug in production is much harder than fixing it when detected earlier in the process, before customers could be impacted.

When we choose to skip the design review, we’re actually passing up on the opportunity to find design bugs that will become expensive to fix once detected during the code review, or much worse, if detected later than that.

So for the same reasons you wouldn’t skip code reviewing, or writing tests, you shouldn’t skip design reviewing. They are an effective way to get quicker feedback on your design and reduce overall risk.

Create a better designed solution

Having a preparation step before implementation is worthwhile: it’s a chance to organize your thoughts. Reflect on the business requirements and on the non-functional requirements (e.g. resilience, scalability, extendibility, security, etc). Come up with multiple ways to solve the problem and consider the trade-offs. These, and more, are benefits of designing in general.

Then knowing your design will be subjected to review, will encourage you to consider others’ points of view too.

Finally the review itself is likely to produce insights that will enhance the design as well. The result will be a superior design, one that is more comprehensive and also takes into account the overall architecture.

Agile Design Reviews

We’ve just covered some great reasons to do design reviews, but still for many people they just don’t seem valuable enough. Maybe it’s because they see them as a bureaucratic and tedious hassle.

I believe we can enjoy the benefits of design reviews, while keeping the practice light and focused. Doing it the Agile way!

So what is this Agile way of doing Design Reviews?

It is about doing design reviews in a style that represents the spirit of the Agile principles. Without getting into it too deep, this means we want our design reviews to enable early and continuous delivery, and shift attention to technical excellence and good design.

A key characteristic of the Agile Design Review is that it’s driven by the team (and not by external parties: “Ivory tower architects”…). The review isn’t imposed on us, instead we are the ones proactively welcoming our design to be reviewed. This is an empowering tool at our disposal, since it helps us find our flaws earlier, reduces our risks and helps us learn and grow.

We are also happy to review others’ designs, to reciprocate and grow ourselves in the process — Win-Win!

Now that we’ve grasped what Agile Design Reviews are, let’s cover a few practical tips…

Practical Tips for Effective Agile Design Reviews

There is no one kind of design review that is best for all purposes, instead it’s better to tailor it to your context. Take into consideration aspects such as, the feature at hand, how risky it is, the business urgency and availability of reviewers. Here are some tips to help you out:

1. Do Design Reviews when they make sense

Design reviews aren’t cost free, there is more than one person’s time at stake. So, don’t default to performing a review for every task.

You should have a design review when it’s risky not to have one. The greater the task’s uncertainty and impact are, the more likely you’ll want a design review to mitigate some of the risks.

2. Keep Design Reviews as short and focused as possible

To allow quick rollout and support changes, try the following techniques to keep your reviews concise:

• Divide a large design review into smaller ones
• Pinpoint a reviewer to a certain section of the design if other areas are less relevant for them (respect the reviewer’s time)
• Stress the risky parts: if you have specific concerns, then describe them clearly . Vagueness makes it more likely a reviewer will miss your point

3. Don’t over invest in documentation — it’s a means, not an end!

There are good reasons to put your design down in words. Many times it is the best way to communicate your design to your reviewers, allowing them to prepare for the review. But sometimes there just isn’t any need, e.g. if a peer tackled something similar in the past, just consult them verbally.

Other times, you might need documentation but you can do fine with “lightweight” methods. These might include: a comment in the source code or your repository’s readme, a paragraph in Jira or a short writeup in a Slack channel.

Another way to optimize your documentation is through the use of visualizations. Often a simple visualization or diagram can express a complex idea quicker and clearer than text.

4. Consider Offline Reviews

Covid taught us all that many processes can be done just as well virtually, and even offline. Conducting design reviews this way allows people to provide their feedback whenever’s convenient to them.

You can also go “hybrid” with your reviews. Holding a live session for a subset of the reviewers, and collecting feedback from the rest in offline written comments.

Consider the option of recording review sessions, besides speeding up the review (you won’t be holding back everyone while you write down comments), you’ll be able to share the recordings with others that are interested but might not have direct contribution.

5. Create an environment of safety and openness in the review process

Whether you’re conducting a review session face-to-face or offline, you want people to speak their minds freely. You don’t want your reviewers to feel judged or not impactful, so it’s important to be open and appreciative of all feedback. If it’s valuable, praise and give credit to the reviewer. If not, explain your decision to leave it out (it’s still a growth opportunity for both sides).

In addition, only invite people if you think they will be relevant, be selective and avoid huge review forums. People aren’t engaged when the forum is too big. Avoid inviting reviewers that might compromise the collaboration vibe.

6. Clearly communicate the process and it’s deadline

Whatever process of reviewing you’re going with, be sure to sync everyone involved in advance. Provide them with a description of a clear timeline, allowing them, for instance, to come prepared to a review session.

Also remember it’s important not to drag out a review longer than needed. You will typically identify this when there is no new input coming in. For offline reviews don’t forget to communicate a deadline for reviewers to give their comments.

Final thoughts

To sum things up, there is no one right way for doing design reviews. It’s all about assessing the context and choosing the best option. As with any other Agile practice, evaluate the design review and improve it with time.

Now that you are better aware of Design Reviews and their ability to boost productivity and lower risks — Go create something great!