Beginning our first Scrum sprint on Monday

Well, it's finally about to happen.  I did a short presentation to get the team educated about Scrum (they seem excited about it), and we did our backlog selection and sprint backlog planning meetings yesterday.  The sprint begins on Monday.  I'm pretty optimistic, at least from the frontline level.

The biggest problem, of course, is trying to do something like Scrum in a big organization.  I think our managers will like Scrum because it provides a lot of visibility into our progress and provides natural 30-day checkpoints at which to change course as needed.  However, I'm still nursing some terrible fears:

  • Once our managers see our sprint backlog, they're going to want to turn it into a blood commitment that must be achieved no matter what.  Normally we can reason with them and remind them that estimates are just estimates, and a lot of unpredictable things tend to come our way and inhibit progress.  But this will be an ongoing battle.  Hopefully they will be able to see the value of having great visibility and regular checkpoints and agree that's worth accepting a certain margin of error in our task estimates (our estimates were never very accurate anyway due to lack of time to refine them, but keep that between you & me!).
  • It will be impossible for our managers to keep their hands off this effort for 30 days at a time.  This is, in fact, one of the big values that Scrum should be able to provide -- perhaps a bit of insuluation from changing expectations.  This one will be ugly, and it's inevitable.  So, I'll have to be a brave ScrumMaster if this happens and point out that we're trying a new process and that trying to change what we're doing mid-sprint is a bad idea.  At least I know that this is a battle faced by most ScrumMasters, and in fact most frontline managers in any big organization.
  • We have a big management review that will be smack in the middle of our first sprint.  Heaven help us if there are action items from that review that we're demanded to deal with immediately.
  • Going forward, you never know what our division may cook up in terms of reporting and tracking requirements, and those may or may not be Scrum-friendly.  I have an action item to lobby for iterative-friendly processes management at the divisional level.  We'll have to see what happens on that one.

As the sprint proceeds, I shall let you know how it goes!

My hope with these blog entries is to share some experiences so that others trying to use agile methods like Scrum in large organizations can benefit.

Take care,

Chris

Comments

  • Anonymous
    October 02, 2004
    I did my first Extreme Programming project in a big corporate environment over the last year. I'm very interested in tracking your progress with Scrum and comparing your results with what I encountered.

    Good Luck!!
  • Anonymous
    October 02, 2004
    Not sure if you've seen this before, but i stumbled across it this week while googleing for wikis.

    Scrum Wiki -
    http://scrumwiki.org/cgi-bin/wiki.pl?SandboxProduct

    --jason
  • Anonymous
    October 03, 2004
    Glad to see another Scrum team getting started! There's a great pool of experience available to you on the ScrumDevelopment list, feel free to ask your questions there. While many senior ScrumMasters monitor the list, we are quite newbie-friendly :-) --deb

    PS: some other resources for you:
    - a backlog spreadsheet used by my team can be found here and tailored to your needs. It's not elegant - excel can be quite fragile
    http://tinyurl.com/3ks54
    - there is also a commercial product starting out called ScrumWorks, you might want to look into it. It seems good, though not yet complete for everyone's needs.
  • Anonymous
    June 04, 2008
    We are always looking to improve on how we build software at Microsoft. Part of that journey involves trying out new techniques on small teams.