Wednesday, August 09, 2006
The value of time boxing
Our internal IT department has recently started splitting iterations of customer-valued work in boxes of a couple of weeks instead of using a full-blown waterfall methodology.
Under the old model, the customer received dates commitments and estimates of work. However, priorities changed quickly and the team needed to spend more time re-estimating and keeping the documentation uptodate than producing the software the customer actually valued. As a result, the development team was rarely able to deliver on useful software on time, and had to spend even more time communicating the delays. A vicious circle ensued. When software was eventually delivered, the business had moved on and the requirements were out of date (despite being signed off).
Now, the customer gets regular supplies of fresh software. The software is guaranteed fresh because requirements are only analysed in much detail at all for the next iteration. He knows that his latest priorities will be pretty quickly converted into working software every couple of weeks. He also sees something like a cumulative flow diagram showing a steady stream of working features being delivered to him. His need for time and date planning, for estimations and documentation goes down.
Under the old model, the customer received dates commitments and estimates of work. However, priorities changed quickly and the team needed to spend more time re-estimating and keeping the documentation uptodate than producing the software the customer actually valued. As a result, the development team was rarely able to deliver on useful software on time, and had to spend even more time communicating the delays. A vicious circle ensued. When software was eventually delivered, the business had moved on and the requirements were out of date (despite being signed off).
Now, the customer gets regular supplies of fresh software. The software is guaranteed fresh because requirements are only analysed in much detail at all for the next iteration. He knows that his latest priorities will be pretty quickly converted into working software every couple of weeks. He also sees something like a cumulative flow diagram showing a steady stream of working features being delivered to him. His need for time and date planning, for estimations and documentation goes down.
Tuesday, August 08, 2006
Effective status meetings
Have you ever been to a long drawn out status meeting where it seems the sole purpose is for the project manager to drag you through his MS Project Plan, line by excruciating line? This is how not to do a status meeting.
There are some simple guidelines for status meetings and they generally boil down to what you want to achieve. If the idea is to get a status update for each member of a project team, that can be better done one-on-one, although it will take more time from the PM. Instead, try to make effective use of the whole team being in one place to discuss constraints that affect them all.
My agenda for a useful meeting:
- What we have achieved (keep this brief)
- Our focus (again, keep this brief)
- What is stopping us -- where possible, invite comment to resolve constraints that affect the whole team or can only be resolved with a significant part of the team
If these meetings are held daily, standing meetings can be very effective in keeping people brief and to the point.
There are some simple guidelines for status meetings and they generally boil down to what you want to achieve. If the idea is to get a status update for each member of a project team, that can be better done one-on-one, although it will take more time from the PM. Instead, try to make effective use of the whole team being in one place to discuss constraints that affect them all.
My agenda for a useful meeting:
- What we have achieved (keep this brief)
- Our focus (again, keep this brief)
- What is stopping us -- where possible, invite comment to resolve constraints that affect the whole team or can only be resolved with a significant part of the team
If these meetings are held daily, standing meetings can be very effective in keeping people brief and to the point.
Timeboxing
I was impressed again today by the simple idea of time boxing. This is a great first stage of iterative development. Instead of the classical waterfall approach, which overemphasises perfect requirements and detailed analysis, time boxing can allow a software development team a great 80-20 implementation. Most importantly, it focusses both the team and the customer on getting a good flow of valued software.
Our internal IT department, once the source of much scorn and complaint has moved from a very well documented (but rarely well executed) waterfall methodology to timeboxed bi-monthly iterations for one programme of work. Scope is agreed, but flexible. As the deadline of each iteration approaches, the development team is able and happy to push in some last-minute changes. However, the customer is happier to defer scope since he knows that there'll be another piping hot delivery of working software in just a couple of week's time.
Our internal IT department, once the source of much scorn and complaint has moved from a very well documented (but rarely well executed) waterfall methodology to timeboxed bi-monthly iterations for one programme of work. Scope is agreed, but flexible. As the deadline of each iteration approaches, the development team is able and happy to push in some last-minute changes. However, the customer is happier to defer scope since he knows that there'll be another piping hot delivery of working software in just a couple of week's time.
Sunday, August 06, 2006
Fresh requirements and fresh software
I often use the analogy of baking when talking about software delivery. Eliciting requirements and then developing software is often like baking bread.
The customer and the development team have a good common understanding of the domain they are working in. White or brown, baguette or bloomer, both mean just about the same thing to the customer and to the bakers. The bread is baked that morning, and then it sits on the shelf. Once the bread is made, the clock is ticking. It needs to be eaten quickly. Once the requirements have been elicited, the software needs to be developed promptly. Otherwise, the business needs will change, or the technology landscape will change, or the user representatives or user base itself will change, or the competition will change. Whatever happens, change is the constant. Change in any of these and the piping fresh requirements will have gone cold and then stale.
That's one important reason agile development places such an emphasis on moving requirements through analysis (when this happens) to design to code to tested code, feature by feature as quickly as possible. The more this happens, the more time a software development team spends dedicating itself to adding value to a customer through working software and the less time it spends on wasteful activities.
The customer and the development team have a good common understanding of the domain they are working in. White or brown, baguette or bloomer, both mean just about the same thing to the customer and to the bakers. The bread is baked that morning, and then it sits on the shelf. Once the bread is made, the clock is ticking. It needs to be eaten quickly. Once the requirements have been elicited, the software needs to be developed promptly. Otherwise, the business needs will change, or the technology landscape will change, or the user representatives or user base itself will change, or the competition will change. Whatever happens, change is the constant. Change in any of these and the piping fresh requirements will have gone cold and then stale.
That's one important reason agile development places such an emphasis on moving requirements through analysis (when this happens) to design to code to tested code, feature by feature as quickly as possible. The more this happens, the more time a software development team spends dedicating itself to adding value to a customer through working software and the less time it spends on wasteful activities.
