Random Thoughts on Software

A lot of teams have trouble deciding whether a task should be declared as a technical task or a story. The simple answer here is that if a customer can ask for it, it should be a story.

For example, the following should be stories:
- Creating an installer - “As a customer, I want an easier way to install the application”
- Supporting an incremental DB tool (such as Liquibase) - “As a customer, I want an easier way to the application database when upgrading software releases”
- Supporting a new deployment environment - “As a customer, I want to be able to run on a 64-bit HP box”
- Improving the system performance - “As a customer, I want to run WizBang transactions faster (i.e. denormalize WizBangFoo and WizBangBar database tables)”

The following should be technical tasks:
- Refactor the new domain objects to eliminate duplication
- Make sure that PMD and Clover are running with the nightly build
- Run a continuous integration build
- Test integration between FooServer and BarWebService

Just because something sounds technical (like improving performance or supporting a new DB tool) doesn’t mean that it can’t be captured as a story. The problem with not capturing customer requirements as stories is that it becomes unclear when they should be prioritized. Who gets to decide? The team lead? The product manager? The architecture team? The project manager? The team? The receptionist?

The other problem is that you don’t get credit for the work and effectively devalue the stories that you are working on in the iteration in which you take on the (miscategorized) technical task.

Take a closer look at the tasks that you have sitting on a punch list or task board somewhere and see if it could be asked for by a customer. If so, write it up as a story and hand it over to your product manager.

If you’ve ever been to a vineyard, you’ve probably seen that they plant rose bushes at the end of each row of grape vines. These rose bushes indicate if there is going to be a problem with the grape vines because the roses are generally weaker than the grape vines, yet have almost the same genetic make-up. The roses will die first if there is a pH-imbalance, insufficient water, too much water, too much sun, or other issues with the environment. The viticulturalists can then react before the problem grows out of proportion. The roses are “indicator plants” that help the vineyard achieve the highest value, by reducing the unnecessary cost of damaged vines.

One of the things that attracts me so much to Agile processes, is that they have so many things that act as indicators to help the company prevent lost time and effort, similar to how the roses help the vineyard prevent lost grape vines. Continuous customer feedback, tells us if we’re building the wrong thing. Burndown charts give us an indication that we’ve taken on too much work for an iteration, or that we need to rethink our release date or scope. Daily stand-up meetings let us know if something is blocking a developer and provide information to all team members so that problems can get rectified as early as possible. TDD leads our design, but the unit tests also remain as a regression to indicate a defect before it gets checked in to the repository. Retrospectives provide indicators of problems in our process and our teamwork. The list goes on and on..

Like viticulturalists, successful agile teams are continually looking for more indicators to help steer them to the direction of value by reducing the cost of mistakes. But this extends farther than just vineyards and software development; every organization needs to find ways to quickly detect problems and resolve them before they grow.