Agile Project Management Using Scrum

  • Article

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):

  • Give the business something to touch and see and feel. Give it regularly. Do it regardless of deliverable dates. Track progress by demonstration.
  • Keep iterations short (maximum 8 weeks). the longer the iteration the larger the risk of missing
  • continuous testing (earlier the better)
  • Good and experience programmers will get agile quicker (meeting the business requirement and moving on). Not always getting the right answer according to the textbook.

Finally on scrum, the core activity is a daily (or as regularly as possible) short meeting on:

  • Yesterday - what happened?
  • today - what's going on today
  • road blocks - what might prevent me doing today's work

The Scrum happens during each iteration or sprint. Each sprint is the result of a planning session:

  • Use experienced developers to create "backlogs" based on effort measured by intuition
  • Use business owners during the iteration planning for the purposes of prioritising
  • Based on the priority (and if sizable split into groups) the work is arranged into a sprint
  • Plan on reality (40ish hour weeks) and manage reality.
  • Anything that cannot be achieved within one sprint, goes into a backlog
  • At the end of a sprint expect to have defects,  a backlog and a new requirements and new priorities

Artefacts (which is largely talked about but not structured):

  • Sprint burn down chart - ability to check after each scrum if it's still possible to complete work
  • Backlog - items that are not in the current sprint

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):

  • it's not for life or mission critical systems (systems where good enough is not ok)
  • it's not for large teams

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)