Incremental design

How does Scrum cope with design?

I got asked that a couple of times last week . So this is an answer that I can point to in future.

Let’s get some ground rules out of the way. Some definitions.

Design is solving problems in the defined solution domain. Here’s a list of domains:

  • hardware,
  • software,
  • systems,
  • integration,
  • network,
  • processes,
  • training.

Architecture opens up the domain to areas that your design doesn’t go. For example regulatory, environmental and ethical considerations. You don’t design in those domains, you consider them. They are part of the overall architectural vision.

So, bearing in mind that I’m referencing other writers here, they may use the terms design and architecture in different ways from me.

The Scrum world talks about ‘horizon’ when it looks at features. If something is over the horizon then you don’t need to spend too much time on it. The requirement goes on the backlog and will be discussed by the team when it gets closer.

That worries people. Does that mean the design is short sighted?

Perhaps it does, but who is to say that a design that is ‘grown’ as features are implemented rather than ‘planned’ by months of theoretical work is less coherent, or less appropriate?

The important point about scrum is that it doesn’t concern itself with how something is implemented; that’s up to the team.

Scrum is about keeping track of any project so carefully, with such an eagle eye, that any delay, any backlog, gets the immediate attention it deserves. In a smoothly running project, the first delay is the most important.

Let’s get back to design. This is more an agile development issue, however it is related to controlling a project.

It’s important to allay people’s fears that they are getting a ‘less good’ product if they don’t take great care in the initial design of their product; if they leave the team to ‘Just F***ing Do It’ (JFDI).

The article I always cite is by Martin Fowler, chief scientist at Thoughtworks . It’s called ‘Is Design Dead?’ and the basic premise is that design can be incremental, if sufficient tests cover all the parts that may change when a new feature is added.

That means test driven development goes hand in hand with incremental design. You cannot use incremental design as an excuse for less work. You take the hit on having tests for every function in your design. And more.

Today I found another reference; it’s a video at the server side . It is an hour long and haven’t watched it yet, when I have, I may update this posting.


Commenting is closed for this article.