Comments on first scrum sprint

  • Article

Hi all -

  Wanted to reply to a couple of comments about my prior entry about having completed our first scrum sprint.

  A reader named Laurent May writes:

"What software tools did you use to manage your sprint development methodology? We are are currently using Excel, but are looking for alternative solutions. Much like your team, we found this methodolgy as a great way to deliver product.  LM"

  Well Laurent, we likewise fell back to Excel and had the ScrumMaster do all editing to the spreadsheet.  Excel worked really well for the most part, with its charting ability and quick editing capabilities.  There were some drawbacks however:

  • Excel is not well suited to distributed editing.  This is an advantage of a wiki (e.g. ScrumWiki) or database-driven problems (I think ScrumWorks falls into that category).  You can plop Excel into a source control system and have people check it out, but that's a hassle.
  • I had to fight with Excel to get it to draw a burndown chart without plotting zero's (but I finally succeeded after I figured out that it won't chart cells with a value of "#NA".

  In the near future we plan to keep using Excel since it's a relatively simple solution that doesn't require any new learning, new cost (for anyone with MS Office), or special maintenance.

  In the far future I'm told that we may be forced (due to what I call the "Heavy Hand of the Division") to keep our work items (i.e. our sprint backlog) in a uniform work item database shared with non-scrum teams.  If we have to do that, it would likely mean that we use that database but then come up with some tools to generate burndown charts and otherwise make it easier to manage work items.  The upside is that it's distributed so it's trivial for anyone to edit their items at any time without having to make the ScrumMaster (or any other one person) a bottleneck for edits.

  Another reader named David Boschmans writes:

"Hi Chris, Congrats with your first successful sprint! Some time ago we've been looking into different agile methods (XP, UP, Scrum ...) and finally choose for the Unified Process method and not scrum because of UP's ability to scale up and down and better support for documentation and its higher degree of formality. I won't say this isn't possible with Scrum but I didn't found any good guidance on this.
In the complex (enterprise) environment we're working in, specs (system, component, use cases, ...) and documentation, .... are very important. More specific: they largely determine the success of the project! Hence why I'm very interested to hear how you tackled these issues with Scrum!
Thanks,
David"

  Well David, that's the big question with using Scrum inside a big organization!  Let me address the issues of scaling and documentation separately.  With documentation, I think any necessary specs & docs have to become part of what you consider a completed increment of functionality ("done" by the definition you are using).  In other words I think that the amount of documentation you want to produce as deliverables is simply part of what you need to deliver, and not really fundamentally different by virtue of using Scrum.  (I believe classic XP would encourage you to minimize your documentation to the minimum needed, but XP & Scrum are different.) 

  Regarding scaling, that's a much harder issue.  At the CSM class I went to a few months back, Schwaber cited some examples of people literally taking Scrum and scaling it up with Scrums of Scrums.  I don't know what I think of that.  I think a first step is to make a big organization more agile-friendly and lean-friendly by trying to do more incremental development, avoiding excess inventory (specs & schedules that are unlikely to still be relevant by the time they're needed), etc.

  I'd love to hear people's thoughts about trying to bring Scrum to a big organization that's used to the waterfall model.

Thanks all!

Chris