SCRUM – after 3 months (1 product release cycle)
Three months ago I implemented SCRUM for the development team I manage at work (C2C Systems). So, whilst I agree with some elements of Steve Yegge’s comments about getting the best out of developers, I disagree with the blanket statement that all Agile methodologies are no good – I am a great advocate of SCRUM – and my reasons ??
I implemented it and it works !! Here’s my comments / thoughts and experiences so far….
So far we have had 5 SPRINTs of between 1 and 2 weeks, and we are just getting to the stage where we have learned all (most of) the lessons and are in a position to begin ‘living by it’
So, how has it been, what benefits did it bring and is it successful or not.
Better communication of project status – the daily SCRUM meetings (15 minutes at the end of each day), involving all developers are really working out well – the developers appreciate being 100% up to date with the status, understanding what everyone else is doing, how much work is still to do, how close we are to meeting the deadline / target. NOTE: We have a 10-15 minute meeting at then end of every day, the status sheet and burndown chart are both updated and published in a prominent position.
There seems to be a general feeling that ticking things off the list gives a sense of progress (getting closer to the objective / target) – previously we simply had a big queue of things and it was not easy to gauge how far through we were or easily see how much closer we were getting to completing. Also, as each ‘feature’ is ticked off, I have more confidence that we can do a snapshot release or put together an early beta for a customer demo – basically it allows additional flexibility.
Statistics / Status – I’m a great ‘measurer’, I love to measure every facet of what we are doing. All these stats are on the status sheet and are visible to everyone, so each person can see how they are doing (accuracy of time estimates, hours worked towards the Sprint / Backlog item, percentage of time spent on the Sprint – as a department we have a target percentage of work towards new software development – the Sprint – figure we need to achieve.)
Estimation – as with any project there is a general bias towards overestimating – this is (I believe) reduced with SCRUM – one of the measures on my spreadsheet is the accuracy of the estimates. So, not only is there a measure on the spread of how well the developer estimated the time required but it is also very visible to everyone why we need accurate estimates (so we can effectively plan the Sprints).
Early visibility of problems (allowing early corrective action) – this is the opposite of the above, under estimation – if this happens then at the very least I get almost immediate visibility of the issue and can take corrective action (more on this later)
Identification of where we are lacking good process – measuring or noting the impediments gives a very good handle on where your processes are falling down, for example if the developers are spending 2 hours chasing down Product Management for answers to ambiguous requirement details then you know you need to improve the requirements process (yes you can see this in normal development lifecycle, but measuring it as an impediment give you good solid / tangible metrics to go Prod Mgmt with to discuss the issue and have them sort it out.
Identification of where we were unexpectedly burning time that was not being allocated – what I mean by this is that we were averaging XX% of development time spent on new feature development, after a couple of Sprints we noticed that we had not been including time for: Code reviews, Demo’ing features to Support, Memory leak testing, Measuring performance metrics and the like – all necessary tasks but we had not been measuring them in our ‘time towards new feature development’.
Links / Useful Info.
Control Chaos
Mountain Goat Software
The SCRUM Alliance
Yahoo SCRUM Group
A sample SCRUM Excel Spreadsheet that I use…