Scrum. It’s that point in the game where the guys all get together to discuss the finer points of ball management. They set a plan, huddle together and execute.
That’s not a million miles away from SCRUM, that agile software development framework that IT professionals use to execute and keep track of IT development projects. I like it, because its simple and the status of the project is clear at any point in the iterative cycles. There are little rules in SCRUM, but its a clear and to the point framework. The whole point of scrum is to ensure that regular iterative cycles called sprints are undertook and at any point in those cycles the state of the development is made clear, usually in meetings that have the team stand, which so far, I like because they last about 15 minutes max.
The general flow of a development project being conducted with the SCRUM framework applied would look like the following:
Set a SCRUM Master (basically the project manager / project leader). Work with your subject experts and business analysts to identify a worklist and set of features the product being developed is to include (normally based on the functional requirements). This work list is commonly known in SCRUM as the product backlog. Based on the finalized backlog, work with the development team to order the product backlog in priority order. In my experience, this happens following some work with general architecture design of the product, so lots of UML diagrams and talk of design principles and patterns by the lead Enterprise / Solution Architect(s).
Once the order of work has been set, the product backlog is split up into sets of ‘sprint backlogs’ which illustrate the list of tasks to be performed during each ‘Sprint’. Sprints are the iterative development cycles and tend to range in time between 2 to 6 weeks or so (at least in my experience with SCRUM). The aim of the sprint is to have an area of the product in a ‘ship ready’ state by the time the sprint ends, so that should mean that the unit tests have been carried out and the QA guys and gals have signed off on the work.
During the sprint, daily team catch up meetings (huddled in headlocks of course 😉 take place to ascertain the state of play each day. Being open and transparent in these meetings is the key to ensuring the sprint will finish on time. In the SCRUM meetings I have taken part in, there is generally a rule within the team that there is no bad news, just be clear and no friction will arise. No one care’s if you’ve not finished something, just be honest so the team can handle it during the current sprint. In my experience, a playback of development to the customer occurs at the end of each sprint.
The workload and project timeline is normally set out against the burn down chart. This is a popular diagram with project managers / Scrum Masters because its a visual indication of whether the project is ‘burning down’ enough to land the project on time for delivery. By understanding in advance whether the sprints are delivering, you can understand whether additional resource or cost injection is needed in order to finish the work in the timescale agreed with the stake holders. There’s nothing worse for a project manager or programme manager than being grilled by the board because a project is over run and over budget.
I’ve certainly had my fair share of involvement in projects that have overrun and have gone well over budget (who hasn’t 😉 and these are non SCRUM projects. I’m a fan of SCRUM because of its honesty about each sprint’s state of development. You know exactly where you’re at every day and because everyone does tend to stand in my experience (you don’t have to), people are quick to update and get to the crux of matters because they wan’t to sit down. This leads to quick identity of issues and resolution of those issues.
I’m a fan of SCRUM and I’d love to hear about projects implemented using this framework that have been delivered both on time and within budget… Comments please!
Oh and last but not least, Happy New Year!