Incremental development

One of the harder things to adjust to in Agile development is attacking things incrementally. There are a few problems people run into. First, they can't see how to break a feature into increments. Second, they try to break it into the wrong kind of increments. Third, they don't stay releasable. Finally, they sometimes go too far (too many increments).

Just about anything can be broken up (though many times it is hard to see it and requires some brainstorming to do so). For example, say you want to provide Enterprise Reporting for your application. Product Management says that you must be able to report off of your data in Business Objects. It has to be able to scale to report on anything that you can hold in your product. That's pretty big. If you accept that it is all or nothing, you fall back to waterfall. But is it really? You can make your first step exposing the data so that it is possible to report on it in the first place. This might be creating some Oracle views (since you don't want users to be tied to your implementation details). Now a user could do reporting (but it would require quite a bit of effort). Once you have that, you could create a Business Objects Universe which does a straight translation. Now its easier for users. But a user still has to go create the report. That's your next step. Etc. Scalability? At first, you assess what it can do. At that point, you have a documented level of what is supported. If not good enough, you can make incremental steps to getting it to where it needs to be.

Notice one thing about how I broke things up. Each step had customer value. Another way you could have broken it up is by the development life cycle. First iteration, you do some analysis of the problem. Then you design a solution. Then you develop it. Then you QA it. Now you've fallen back to waterfall. You don't get the immediate feedback that you get from smaller increments. You could go way down the wrong path before you realized it. That's not to say that it doesn't make sense to occasionally put a research card in that doesn't directly add customer value. You'd do this typically if you don't know enough about what you're trying to do to break it into chunks. This can be very valuable (some call it building architectural runway). Don't overuse it though because the tie from this work to customer value (our focus for everything) is weaker. Similarly, try to avoid work which can't be used by users (where things are coded but not exposed).

Another problem with breaking up development and QA is that you lose your releasability. Between development and QA, it isn't releasable. It is hard to say how much time it will take to wrap it up. You're better off breaking it into smaller chunks so that development and QA can occur in the same iteration. This helps to avoid unpredictable release cycles at the end. There are other ways to lose releasability in your increments. Generally, you want to avoid scenarios where you add things in the UI that aren't used until later iterations. At the end of every iteration, the product should make sense as is. Some features might not be far enough along that people use them, but they could. And if they don't, you'll get that feedback and next release you'll enhance it.

You might argue that breaking things into increments adds cost. You do things in one iteration and then redo them in the next. That's true. One of the challenges is to try to break things up in such a way that you achieve the above principles with minimal rework. But I'd argue the rework is worth it. By allowing feedback at every step along the way, you'll head off steps in the wrong direction (saving more than the increments cost you). The predictability gained by staying releasable has a lot of value too. People measure an Engineering organization by how predictably it hits its targets.

Don't go too far though. Keep a feature simple (down to its essence). Release it that way. Let the users' feedback help you identify which features to go deeper on. Worst case, they won't use a feature until next release. If you go too deep, you're stuck with it forever (unless you pull the advanced capabilities which is painful; someone is probably using it even though most aren't).

So to sum things up:

• Add customer value with every increment
• Avoid increments which aren't exposed to the customer
• Stay releasable
• Keep the increment within the iteration
• Make sure the product doesn't have any non-functional features at the end of an iteration
• Keep it simple