Agile methodologies, like most flexible yet powerful systems, rely on knowing exactly where things stand. You may not know exactly what’s coming in the future, but you know what you’ve already got, and roughly how close work in process is to done. This is one of the many reasons short iterations are a good idea. Not only do you know on a frequent basis (the end of each iteration) where you stand, but if what was done is acceptable to the stakeholders (and QA) and can really be considered done. The product backlog tells you what needs to be done in the future (based on current knowledge, which may change, and that’s OK) and the iteration backlog tells you what’s done and what needs to be done now. The burndown chart shows how things are going inside the iteration.
It’s often said that a broken watch is right twice a day (the joke presumes a mechanical analog watch). With a complex processes involving lots of parties like software development, misinformation can be much worse than no information at all, because you don’t know what you don’t know, so you make plans based on lies. Here are some bad practices to watch out for:
- The list of requirements must be complete when the iteration begins. Significant changes to requirements inside an iteration invalidates all the planning that went into it. In my current day job, we’re trying to prevent this by having the UI team develop mock-ups and have them approved the sprint before the work is to be done.
- The list of tasks for a story must be complete and fully described. I have seen iterations destroyed just because the planners forgot to task out creation of test data. I’ve also personally experienced work stoppage because a task was insufficiently defined, and the stakeholder with the details was out of town.
- Done has to mean done. And Done has to include the code being checked into source control, QA testing what’s in source control, and ideally integration tests. The mindset of “It compiles, so let’s ship it” creates the worst kind of technical debt.
When I compare Agile to Waterfall to people with no Agile knowledge at all, I often compare a torpedo to a boat. A torpedo will usually get to where it’s going quickly, but if the target moves (market changes, company changes focus, customer changes focus), or if anything does go wrong (available resources change, regulatory changes), the torpedo is most likely not going to be very effective. It’s pretty “fire and forget”, so there’s no way to change course, or even tell that it’s no longer heading towards where the target now is. A boat, on the other hand, moves slower than a torpedo, but is steerable and even stoppable. It may (or may not) take more time to get where it’s going, but when it’s done it’s much more likely to be where you need it (the product does what the customer currently needs, whether that matches what the original goal or not).
If the pilot of the boat doesn’t know where the boat is or how fast it’s going, it can end up anywhere, and just like the torpedo, the pilot won’t know until it’s too late to correct the boat’s course.
I’ll leave you with a real-world example I experienced. A previous employer of mine developed a very large product that was really a platform to build applications from. Each customer needed very heavy customization to make it suit their needs. The product was designed to be that flexible. The problem was that this process could take seven months or more before the system could pass user acceptance and we could get paid. The company decided the solution was to develop several application templates for different target markets to use as a starting point to greatly speed up deployment. That sounds like a sensible solution, right? The problem is they spent more than $600,000 and close to a year to decide what those templates should be (you read that right, that’s just the market research to figure out what they should be, not the coding to develop them). In that time, the market had totally changed, and their results no longer matched what their potential customers would need.