Finding Time for Software Design in Scrum

One of the principles of the Agile Manifesto says, “continuous attention to technical excellence and good design enhances agility.” In his book “Implementing Domain-Driven Design“, Vaughn Vernon complains however that adopting Scrum has often led to spend less or no time on good software design practices and he is not the only one in this case.

First of all, and sad to say, I think there has been a general abandonment of good design and development practices in the Java community. These days it may be difficult to find a clean, explicit domain model in most Java-based projects. It seems to me that Scrum and other agile techniques are being used as substitutes for careful modeling, where a product backlog is thrust at developers as if it serves as a set of designs. Most agile practitioners will leave their daily stand-up without giving a second thought to how their backlog tasks will affect the underlying model of the business. Although I assume this is needless to say, I must assert that Scrum, for example, was never meant to stand in place of design. No matter how many project and product managers would like to keep you marching on a relentless path of continuous delivery, Scrum was not meant only as a means to keep Gantt chart enthusiasts happy. Yet, it has become that in so many cases.

I consider this a big problem, and a major theme I have is to inspire the Java community to return to domain modeling by giving a reasonable amount of thought to how sound, yet agile and rapid, design techniques can benefit their work.

Source: Implementing Domain-Driven Design, Vaughn Vernon, Addison-Wesley

Software Design Patterns. Source: http://vis.stanford.edu/papers/infovis-design-patterns

There are no simple answers when you walk the fine line between doing just enough for current iteration and performing activities that need to have a global vision of the developed application like software architecture, security, user interface or design. One of the first issues targeted by Agile was the Big Up-Front Design (BUFD) syndrome where people spend endless time designing the software solution… before coding something (almost) completely different.

In some areas like design or documentation, some people thought that they should completely ignore the old practices and that delivering only working software was fine. This might be true for the customer at the moment of delivery but could then prevent the product to evolve in a healthy way because it lacks good design or the basic documentation needed to maintain it. Bad software design is a major factor of creation of technical debt during Scrum projects. The “responding to change” value of the Agile Manifesto is a continuous challenge of Agile teams and good design is a tool that help to achieve this goal.

Further reading

* Scrum’s Product Backlog – Agile Requirements Management
* The Decline and Fall of Agile
* Coconut Headphones: Why Agile Has Failed