Traditionally, software teams are allowed to develop software in a large timeframe. They can read the entire list of features at the beginning of the project. They then usually start designing and developing a generic framework to support all those features. It is not uncommon that developing the generic framework takes more than half of the total project time. The justification is that “once we have the framework, slapping on the features is dead simple”.
As soon as they start “slapping on features”, it turns out to go slower than initially thought.
And as soon as the customer gets a sneak preview of his product, the changes keep coming, which leads to inevitable changes to the generic framework.
Damn.
One of the key concepts in lean/agile software development is to develop software in small, usable pieces. Scrum calls this “potentially shippable”, meaning that a customer may decide to deploy a piece of software and monetize its value. Obviously, such a small piece of software can’t contain all the features the customer ever dreamt of.
But because the customer didn’t ask those features now, doesn’t mean he won’t ask them in the future. Some of those features are even very likely to be implemented in the future! What to do now? Should you build those features anyway? Or maybe partially, just to make it easier to implement them fully in the future? How can we make a generic framework for all features if we are only allowed to build a few? How can we make a generic framework if we don’t know all the features anyway?
The answer is: you can’t.
This is a difficult paradigm shift for teams starting out with lean and agile. Just make the features the customer asked for in this small piece. No more, no less. Experience taught us an important lesson: once you start delivering pieces to your customer, the list of features changes. And keeps changing. Until the end of the project, and even after that. The solution is to make your solutions adaptable.
Adaptable is not the same as generic, although I have met quite a few developers that use these terms interchangeably. Generic means “applicable to all specific situations”, a one-size-fits-all solution. Adaptable means “able to adapt to a certain situation”. Those things are related, but not the same. I have seen too many “generic solutions” that weren’t generic enough to support a new feature (“gosh, we didn’t think of that”). And they weren’t quickly adaptable, because they were designed to be… generic, right? It is not necessary to change a generic solution, so adaptability has never been a design criterion.
On the other hand, if you have an adaptable solution, you just… adapt it to support a new feature. Think about it for a while. It doesn’t matter when you didn’t think of a new feature upfront, because you designed the software to be adaptable in the first place.
Next time when you’re working on a new design, make sure it’s adaptable, not generic. You’ll do your customer (and yourself!) a big favor.
User Stories are a nifty concept to convey “what needs to be done” in an agile environment, where not all analysis and design activities have been done before coding has started.
