Thanks to eBay and www.PM-Audiobooks.com I purchased a scrum audio book. It's taken me 8 months or so to finally get round to listening to it.
Primed with a new opportunity to use Scrum I thought it pertinent to remind myself what enthused me in the first place. Note, my perception is that agile estimation and scrum was a major contributing factor in the success of my last project. Specifically I think Scrum is ideal for helping turning around troubled projects (something Kevin and I agree upon). Unlike the perceived worry of new practices being risky, I would argue that Scrum, when implemented properly, is rigorous and produces time-tested results. Visibility of the process to management is core to Scrum and this was the seed for its use in my last major engagement.
Agile, the umbrella within which Scrum sits, is very similar to Microsoft's latest customer campaign around being "People Ready". It must be said it makes sense; people make software work. Agile is similarly human-centric not process centric. Agile also says "change is good" because it probably means your end product is closer to what the customer actually wants (not necessarily what they asked for).
So, back to the audio. It's pretty sketchy in quality but the presenter Kevin Aguanno, talked through the introduction pretty well. For an audio book there were too many muffled questions.
Here are my interpretations (and additions):
Finally on scrum, the core activity is a daily (or as regularly as possible) short meeting on:
The Scrum happens during each iteration or sprint. Each sprint is the result of a planning session:
Artefacts (which is largely talked about but not structured):
Note: THESE are in addition to any other requirements that may be required for the process being used for the sprint. Scrum is, of course, process independent (which may explain Kevin's closing remarks)
I quite liked the North American take on scrum (and consequent understanding of Rugby) - "The process of getting the ball back into play"
I don't quite understand Kevin's approach of doing Scrum over the phone (for a geographically disperse team). I think Scrum works best if the meetings are face to face and are, unfortunately stand up. Standing up is uncomfortable but sitting down does say "I'm here to discuss and debate" and a good Scrum is "I'm here to state facts only". The stand-up is round robin.
One big thing Kevin missed, perhaps because he is a true Project Manager and not a Scrum Master is self organisation. The team selects the items of work they will take ownership of. Psychologically and in practice people deliver better on their own commitments than those handed down.
The big questions that Kevin sells are when not to use Scrum (which I contest below):
To conclude I have found that on projects, the features, (gleaned from use cases, scenarios or storyboards) need to be tested and as well as having a working people of software at the end of a sprint, I would argue it should be a qualified and acceptable piece of software (ie. it has had some signoff and the the features that it says it performs actually do just that - nominally through automated testing). Therefore I would argue that it can be used for precision systems but I do concede it would be hard to manage for very large team (though there are emerging Agile thought patterns)
Good summary. A good way to check if you're really using all 7 elements of SCRUM is by using the nokia test.