Projects are strange animals.  They get a lot of attention at the start and typically not much once they’re underway unless things have gone wrong.  When they do go wrong, there is a lot of disappointment and the machinery is generally blamed.   A bit like making toast, actually a lot like making toast.

So imagine if you could actually see project progress constantly?

Not just every month or week or whenever status reports are produced, but truly constantly.  That way, if the toast was burning you would be able to do something about it then, not at the end of the week when you had no option but to throw it away and start again.  And if the toast wasn’t cooking, you could take action, then, and increase the heat (add more resource).

Imagine too if you are the toast (project team).  You wouldn’t have to keep stopping the project for inspections so people can gauge how things are going.  Anyone interested can just see the progress at any time.

Less Inspections = Less Interruptions = Smoother Delivery

And having transaprency of progress is healthy too, it means that progress is more visible to those who perhaps would not have ordinarily taken an interest.  The more people involved, the more likely that issues will be spotted and addressed before they become problems.  Of course this means that people will see all our flaws and all our dirty laundry but so what?  The first step towards improvement is recognition of the problem.

Stop imagining, think Agile, think Scrum, think Task Boards, Backlogs and Burndown Charts.  There should never be another piece of burnt software development toast.

A question I was asked last week resulted in an interesting discussion that is worth sharing because I am sure you too will be asked it at some point if you haven’t already. It surrounds the issue of budgeting, specifically preliminary budgeting when attempting to outline likely initiatives that are to be worked on in some future period.

How are they to be accurately estimated using Scrum?

Its a good question, traditionally we planned work for the coming year and the budget was a function of the work to be done and the resources needed to do it. I’m grateful to Rowan Bunning for his input to this discussion. Check out his blog for some interesting related discussions.

Nowadays, as Rowan points out, Scrum projects benefit from estimation techniques that are aimed directly at enhancing the estimation process, including:

• Multi-disciplinary team estimation
• Accuracy over precision
• Relative complexity/size estimation techniques
• Continual review and re-estimation of requirements
• Budgeting is performed in short time-boxed sprints where variation in team size and structure is limited
  

If we wanted put these techniques into practice by establishing an initial, estimated Product Backlog covering the known objectives of the project it could be done in a day or two for most projects. This may be sufficient to appease those who need a budget for the next 12 months. If not, a provisional budget may be used to extend these 1-2 days in order to produce a Product Backlog with estimates, release plans and schedules for the entire project.

So what is the difference? Well, instead of a Project Manager producing a detailed Gantt Chart which identifies activity at an individual person day level, a small multi-disciplinary team applies the 5 techniques listed above to produce something at a much higher level but which they are comfortable with and can commit to. They do this in full knowledge that although what they work on will be aligned in some way with the project goals, the full detail will only become apparent in time.