You are here

(Common Mistakes) Underestimating the amount of work outside a product feature.

Take a look at the following
• Working software is the primary measure of progress.
• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

You should recognise them as three of the principles behind the agile manifesto and key to the success of any Agile project.

What often happens when estimating work and committing to the work to be executed an iteration the team does not include all the work needed to support these principles.

The biggest culprit here is normally the Continuous integration environment. Yes it is true that you probably already have your continuous integration environment set up, you may have already even pushed a few pieces for work through it, but there is no doubt it will need fine tuning, the team will need to become familiar with what it is, what it does and how it does it. It may still need to be extended. Engineering practices around if may need finalising. These all take time and always take a lot more time than you initially think they will.

Another large time eater that is often underestimated is the testing and technical excellence overhead. Developers have the mindset that once the initial coding is it is done, that is the end of it. Getting them out of that mindset and into one where they need to think about what it is the team needs to do to complete a piece of work is something that needs to be actively worked on and takes time. You will also often find that even people who are traditionally testers also underestimate then amount of effort they need to provide. Developers and testers, especially the good ones are all optimists. It is also often the case that the team forgets that what they are building is complete potentially deployable product increments. These need to include all agreed features, error trapping, logging fail-safes (best practice) and should ideally not need to be touched again. It is far to easy to leave behind little pieces of technical debt that gain interest and grow and grow until something blows up. We then end up in the situation where we have to waste an entire iteration addressing built up debt. This is a really good way to destroy the trust the product owner and the rest of the business has built up.

Also remember that the team is leaning at the same time as doing getting into the good habits required for any agile implementation takes discipline and is not easy. The team will need to be continuously coached, coaxed and cajoled into doing the right things for the right reasons.

Make sure that you take all these things into account when you size your work and plan your iteration. The single worst thing the team can do, is commit to delivering and then not do it.

This is likely to mean that the first few iteration s do not deliver a lot of visible business benefit (they will deliver some though), but what they will do it make sure you address at least part of another agile principle. “Continuous attention to technical excellence and good design enhances agility”. It will however make sure that you have a good stable base to work from and have a team that are doing the rights things and know why they are doing them. The result of this is that you will very quickly will start to increase your throughput and not have a large technical debt, along with interest, to pay back in future iterations.

Above all you will be delivering product and gaining the trust and respect of the rest of the organisation, something money can’t buy.