Scrum
Computing projects are typically managed using standard project-management methodologies, such as GANTT charts. This doesn’t work too well for a variety of reasons:
- In any non-trivial computing project it’s impossible to identify the subtasks involved until you’ve more-or-less done them
- Computing projects are particularly difficult for the clients to envisage, since they’re so abstract. Therefore, the requirements change throughout the life of the project.
- Interrupting a computer programmer, or changing their goal, causes them to forget lots of important information about what they were doing, and hugely reduces their efficiency. It’s said that diverting a programmer’s attention for half an hour destroys the equivalent of a day’s productivity.
- Project management is hard.
There are various methodologies in computing for “agile” development, which are intended to solve these problems and others. I only really know enough to use two of them – test-driven development and Scrum. Test-driven development is simple: the idea is, before you write the real code, you write the test code. This helps you think about the purpose and interface of your real code, and also means that when you finally write the real code, you can be certain when you have finished and it’s bug-free, because all the tests pass. Which is nice. It also fits the typical project lifecycle a bit better, because tests should be based off the design or specification rather than off the actual code, which means it makes sense to write them before you write the real code. (Of course, most project managers secretly don’t want you to write test code anyway, because it means your project takes longer. But they’ll all deny that.)
However Scrum is much harder to explain, as it’s a project management thing. It has a number of interconnected principles. Here’s some of them…
- There is a master set of requirements called the Product Backlog.
- The development team does everything in 30-day “sprints”
- The requirements for a sprint are set at the beginning and cannot be changed
- However a sprint can be cancelled if its requirements prove to be irrelevant
- There are defined-length meetings at the start of the sprint to set its objectives, selected from the Product Backlog. This implies an acceptance that the requirements cannot be perfect.
- The team manages itself within the Sprint. There is no pro-active management.
- All deliverables in a Sprint must be finished and ready to deploy in a product. e.g. documentation and test code must be ready. Therefore your customers can assess what you’re producing and affect your Product Backlog appropriately for future sprints.
- Progress within a Sprint is tracked using a “burndown graph” which represents the time remaining on each task in the Sprint. The time remaining on each task can go up as well as down, based on developers’ current estimates – but hopefully, across all tasks, it tends down to about 0 at the end of the 30-day sprint.
- There are defined roles for a Product Manager-type person and for a Scrum co-ordinator (who just enforces the process, rather than actively manages)
Here’s an example of a burndown graph. (The numbers along the bottom are the 30 days of the sprint, which Excel has eaten. Bless it. The y axis is ‘time remaining’ in hours).
There are other principles – and I’m sure that, to be fully effective, you can’t arbitrarily omit the ones you don’t like – but this subset seems to serve me well for a team of one: me. I’ve been introduced to Scrum by my contracting work. To be honest it works better there – too many of the Macrobug tasks are too experimental, and, a bit like test-driven development, it doesn’t work too well if you’re just flailing around trying to make things work. Still, I’m quite sure it works better than the typical approach with rigid GANTT charts, and I hope one day I get a chance to use it in a team of more than one!
Things I like:
- The theory that, once you’ve planned your objectives for the 30 days, they won’t get changed and you won’t have to do lots of wasteful context-switching. This benefit only really applies if the organisation fully adopts Scrum, which my contracting job doesn’t really.
- If you discover that it’s going to take more time to do a task than you expected, that’s fine. You just record it, and the graph will show your product manager that there’s going to be a problem. Much less troublesome than aiming for arbitrary targets.
- The fact that you release things in 30-day increments which are supposed to be “finished”. That’s a bit like the well-known open source principal, “release early and release often”. It’s good.
In short, it seems like the best compromise between not interrupting the programmers, versus giving the customers/stakeholders frequent opportunities to affect the product progress.