A friend of mine sent me a graph showing his product's build time over the last month. It looked roughly like this:
Is this a problem? Well, yes, and no. There are a lot of very good reasons the build is now taking longer:
- More features (hooray!)
- More tests (hooray!)
Of course, there are some downsides to this as well:
- Longer turnaround time before you get feedback
- More thumb twiddling waiting for a build means more multitasking, which means less zoned-in oh-boy-is-this-productive time
There are things that the team can do to make the build shorter without giving up features or tests. They can optimize the code they have (faster faster!). They can optimize the tests, or more closely target the test to meet their needs. They can make the build multi-stage (a build/quick test cycle and a more full test cycle). Is this the most urgent thing they can be doing? Nope. There are plenty of new features to add, bugs to fix, and tests to write.
This is an example of a non-urgent task. It's something that you can do. It's something that you should do before it becomes a big problem. It's not the most important thing to do, however.
Non-urgent tasks like these are ideal for those days when you just can't or won't work on the product. These are the tasks you do the day before a major holiday when half the office is on vacation already anyway. You do them in the first morning after a release, while you're still trying to figure out exactly what's going into the next release (or sprint) and you haven't yet divided the work among teams. You do them when that two day task turned out to be easier than you thought and it only took one day. There are pockets of found time in software. Use the found time to address the non-urgent problems.... before they become urgent.