Design Validation

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.

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:

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.

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 that I use, and an example 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!

---

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/