Scrum teaches us: ”No big bang design!”
We’re supposed to discover the design as we keep developing. Sure, that’s probably ok in a small project. It’s like building a small medieval village. Another villager moves in and just patches his house on the outside of the village. And after a while, we have a jumble of streets and houses.
Try scaling up that to a big city!
As soon as any software starts getting useful… eh… I mean bigger, we have to know what we are constructing. We have to take the time to sit down and think about what we are doing. We have to understand the problem we are solving. Or else, we’re going to end up with code that reminds us of that village.
Now, isn’t there a word for this in software development? Anybody heard of architecture? And isn’t understanding the problem, the first thing any architect does? Whether it is you, the lonesome developer, or the professional architect at a big corporation? The big companies have figured this out a long time.
In Scrum we try to understand the problem when we gather user stories. Interviewing the customer to understand what she wants. But I think many Scrum practitioners don’t understand that these stories contain a lot of metainformation, and they move directly from gathering stories to coding them, without taking a moment to look at them and actually see what story they are saying.
Because, all the user stories together are telling a bigger story. The story of the finished product.
And it is up to you to find the patterns in the details.