Design Validation
Tags: agile, leadership, devops
Published: 2021-05-03 01:26:02

---
slug: 'design-validation'
title: 'Design Validation'
series: 'Agile Software Development'
description: 'How design documents can make junior team members more successful.'
publishedAt: '2020-04-30T09:00:00.000Z'
cover_image: 'https://dev-to-uploads.s3.amazonaws.com/uploads/articles/873h17c79aaftk9wg3w3.png'
tags: 'agile, leadership, devops'
published: true
---

## Introduction

Software teams have a broad range of skill levels.

This can be due to familiarity with the tools, a push for mentorship from engineering managers, or just general software engineering .

In short, we shouldn't expect, nor assume, a level playing field across the team.

![A team constructing a web page design together](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4yxz8pmu3agrd3nws6vb.png)

In the journey to give team members independence, you may find running out-of-scope in implementation. 

This can lead to a range of issues, including undesired functionality and conflict with other work items. Product owners put a lot of effort into keeping the backlog well-defined, and we need to stick to what's required!  

Further, these issues will almost always be identified **after** implementation, when time and development costs have already been spent.

We need a way to keep our team members on the right path, while still promoting autonomy through asynchronous development practises.

### Enriching the Agile Lifecycle

I've found that a good solution is the inclusion of just a single, extra step in the agile process.

You're probably familiar with the **design document**. Before implementation starts, the developer whips up an outline of how they intend for the work item to be to completed.

This is nicely expanded upon by [reqexperts.com](https://reqexperts.com/resources/requirements-articles/articles-what-is-the-difference/):

> The Design Specification should state how the design will meet the requirements. Design is not a one-to-one response to requirements. Design requires discipline knowledge and integration of disciplines in most cases.

At this stage, a senior team member can approve of the documented strategy, *before* a week or two is spent on the implementation. 

More often than not, a quick read will result in an all-clear. However, if there's an issue, then specific changes can be requested.

![Senior developer looking through tasks](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/u91rtb1x2bls6nkszdr0.png)

Of course, your organisation may implement agile in a different way. 

What's valuable is the core idea of documenting and validating a feature's design **before** its implementation.

I've provided the [template](https://docs.google.com/document/d/1Lxd5JkrKguPrbO6hXFENf5UPMe7jaPXScKa3AQYVsNc/) that I use, and an [example](https://docs.google.com/document/d/1UDV1kNEByRWje3oj7fgkYYkWUo5MYbKLewU245aLEGg/) of a completed document.

### The Junior Agile Lifecycle

We've now identified this extra step. 

Using this, we can outline our **junior-friendly agile lifecycle**.

1. **Concept:** Stakeholder discusses feature request with Product Owner.
2. **Requirements:** Product Owner documents feature requirements, and adds work item to backlog.
3. **Design:** Developer picks up work item, and documents their implementation strategy.
4. **Design validation:** Design document is reviewed and approved by Senior Developer.
5. **Implementation:** Developer implements work item based on documented design.
6. **Evaluation:** Feature branch is reviewed, tested and merged.

Hopefully, this results in a great, cohesive team!

![A team playing with tools together](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/u8829wceqig2o6j0fxzo.png)

---

Hey, guys! Thank you for reading. I hope that you enjoyed this.

Keep up to date with me:

- DEV: https://dev.to/tao/
- Twitter: https://twitter.com/LloydTao
- GitHub: https://github.com/LloydTao
- LinkedIn: https://www.linkedin.com/in/LloydTao/