Exploring Three Agile Principles - Design Excellence

This article explores three of the Agile Manifesto Principles that I have categorized as Design Excellence.

If we hope to maximize an agile approach we need to design and build excellent software solutions. These principles emphasize these points and allow us to accommodate change. Design excellence is not a once-and-done thing. Like most of agile it is a journey that requires vigilance and attention to changing events.

Continuous attention to technical excellence and good design enhances agility

We need to pay close attention to technical excellence and design as our product evolves. There is a balance between “Building the Right Thing” and “Building the Thing Right”.

We must also be wary of delivering fragile systems. If we make a few changes and our application falls apart like a house of cards we are not in a good place.

Extreme Programming and to some degree Scrum recommend Test Driven Development and automated builds as a way to avoid fragile solutions.

When we have a set of proper automated unit tests that are included in some sort of automated build, we see problems every time the build runs. The higher our code coverage is and the closer we get to continuous integration the better our solution will be. It is all about balance.

Over time, our solution will accumulate technical debt. As we weigh the tradeoffs between building it right and building the right thing, this is bound to happen. It is best to only include a few technical debt features in sprints when they are required so each sprint is delivering business value.

Simplicity--the art of maximizing the amount of work not done--is essential
Agile is all about doing the right amount of something at any given time and no more. We should author user stories with the detail necessary to get the job done and no more. We should build what we know we need now. We should not build some huge framework we think we may need someday.

It is critical to have a complete and thorough understanding of the software frameworks we use. Code is evil and we can eliminate quite a bit if we have a good understanding of our chosen frameworks.

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage
This principle will scare teams who are used to waterfall projects. It first glance, it seems crazy to welcome change late in the development process.

First, we must be successful at implementing the first two principles in this section. If this is not happening, welcoming change is impossible.

Late in development means late in the release of the complete product. Scrum delivers features in short sprints. We do not welcome changes in a sprint that has already begun. Because we are delivering features in short cycles, change is part of the whole process.

In scrum, the change is directed by the Product Owner. It is up to the Product Owner to understand what the competitive advantage is for the features in the backlog.

Learn More

·         Agile Product Ownership in a Nutshell

·         Coaching Agile Teams

Agile Estimating and Planning