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.

I’m back on the Agile Development topic again today, I’m absoutely loving Scrum as an approach but I am finding one problem that I suspect is not peculiar to UNE but is endemic in the higher education and perhaps even the entire public sector.
That problem relates to reactivity or delivery speed in the rest of the organisation. So while we’re all ramped up, focused and sprinting, unfortunately the rest of the organisation is not.

I need to tread carefully here but I do believe that in stark contrast to commercial organisations, universities in particular have a more thoughtful attitude to general operation and particularly to change.  Directives are generally rare and the consultative process seems to often result in compromise that supports the status quo rather than slapping it about and moving forward.

However, this is the world in which we live and operate and these are just hurdles that we need to deal with.  One way of dealing with this is transparent, up-to-date and accurate communication of progress and importantly, of those hurdles.  Previously this is where I would have reached for my Gantt chart and spent an hour a day tweaking things here and there and saving as images to paste into highlight and exception reports which I’d then email around to all and sundry to dutifully ignore.  By the way, as an aside, check out the ongoing discussion on Edward Tufte’s website about reporting project progress for big projects, I warn you though it is a long page.

Enter Scrumdesk I could write 5 articles just on this tool alone, it is without doubt the best application I’ve ever used for tracking and communicating development activity and totally appropriate for BI/DW and web development.  Incredibly it is also free (for up to 5 users).  You’ll need to learn about and practice Scrum to get the most out of it, but as an application it is crammed full of novel and very practical features that I just haven’t ever heard people talk about (like the use of Fibonacci Numbers for estimating), and importantly for this article a fabulous project overview report that is actually a dashboard.

Have a look at it and leave a comment here telling everyone what you think, it has already won a wealth of awards and is nominated for the European Software Conference Epsilon Award next month in Berlin.  I think the product is still in its infancy so there are a few amusing translation issues (the team are based in the Solvak Republic) but I just know this is going to make my life reporting progress to executives a whole lot easier and its fun.  Sorry Henry Laurence