Using Scrum in MacBU

Today marks the official beginning of sprint number 2 for the Automation Team. Last month was our first attempt at a modified Scrum. I mention “modified Scrum” simply because of the cruel fact that I don’t know everything there is to know about the Scrum Methodology. We just kind of picked out what made immediate sense and did it. It’s a good change and we are learning. While our team is the first team in MacBU to be using this Agile process, hundreds of teams at Microsoft have had great success with it.

We’ve had daily standup meetings for a long time, but this was the first time we actually did the product backlog and sprint backlog so I thought I’d record some of my personal reactions to the experience. There’s a lot to like about what we’ve experienced so far, and as we figure out better how to apply this “Agile” stuff, I’m hopeful things will get even better.

Here are some of my first impressions about the process:

The backlog provides an awesome communication vehicle. Before the beginning of September the four of us on my team got together and generated a big long list of all the things we would like to do. We put all of this in OmniPlan, and then selected a subset that we would tackle in September. This did several very good things:

  1. It got us all excited about the ways our team could contribute to the overall success of the software products we produce.
  2. Helped us “get on the same page” with respect to the meaning of the individual items. You’d be surprised how different people can interpret even the shortest sentence!
  3. Allowed everyone on the team to see exactly what everyone else had to do.
  4. Allowed me, as a lead, to post the sprint backlog in the Lab for everyone to see. If folks wanted to see what we were working on, or how much progress we were making, it became very trivial. Perhaps low tech, but effective.

Developers are less randomized and more focused. Part of working on an internal team that builds software for folks sitting in the office next to you is that you get a lot of requests and lots of feedback. This is good, but the flip side is it can also lead to lots of interruptions and cause your efforts to be spread so thin that your effectiveness suffers. With our focus set in the Sprint backlog, new requests simply wait until the next sprint. All the devs get to remain heads down getting stuff done.

Cross Team Collaboration Improves. With the sprint backlog in place, when someone or some team comes to us to ask us to “Do X” we can immediately respond, “That’s a great idea, does it need to happen this sprint?” Almost always, it can wait, and this does two great things:

  1. It allows time for the customer to really think about the request. By the time the next sprint rolls around what was life-and-death-urgent is now better thought out and prioritized more realistically.
  2. It gets our “customers” in sync with our rhythm of delivery. The theme becomes, “Get your ideas in the next sprint’s backlog, and you’ll see some action on it in a month.” All the lobbying for changes and design discussions about what goes in next will happen with the Product Backlog owner (me in this case) while the rest of the devs are uninterrupted.

High quality things get done! This seems maybe a bit silly, but at the end of the sprint, even if you way over estimated your production capability, (which we did) you have something to show for your efforts. Not just working software, but reasonable easy to understand metrics (like units of work per day) that everyone can understand when you need to explain why it will indeed take 3 weeks to deliver a high quality solution next sprint.

Things get better now. One of the most interesting things about this whole process is how it elevates and exposes problems in the stuff you are doing. As you look at the backlog and compare your velocity of production to what you thought you could do, immediately you and everyone else begin to consider, “Why does this take so long?” On the last day of the sprint, (last Friday for us) we got together in the Cafeteria and took some time just to reflect on how things went, what slowed us down, and what can we do better. What’s great about this is you remember what you were doing and then we add to the next Sprint items that will increase our velocity. As Henry Petroski has said in To Engineer Is Human: The Role of Failure in Successful Design, we learn more from our failures than our successes. But only if we pay attention to the failures and figure out what to do right the next time. This is so much better than waiting until we ship Office to have our “Post Mortem” to discuss how the release went. Problems are fresh, and fixing them right away have a good chance of paying off in the current product cycle.

All in all, I’m very happy with how Scrum is working for our Team. For October, the Tools Team and Lab Team are joining us in testing out the Scrum process. I hope it works out for them, as well as it did for us.

P.S. If this kind of software development stuff interests you, there’s a great overview talk I recently found by Ken Schwaber which was produced as part of the Google Tech Talk series. I really enjoyed it. Lastly, if any of you have any sage advice for a Scrum Master in Training, I’d love to hear it.

8 thoughts on “Using Scrum in MacBU

  1. Nice to meet you Lyne. I don’t know a thing about scrums, but I do know that this format offers all kinds of opportunities to work on the balance of “building the group” AND “getting the job done.” In group settings, it is valuable to allow for what Sylvia Ashton Warner called,< HREF="" REL="nofollow"> “breathing out and breathing in”.<> This will make the sharing and collaboration that much more effective. You are on a wonderful path here. Are you keeping a journal of the journey? Your Dad

  2. I hope you will try our free Agile project management product called < HREF="" REL="nofollow">ScrumWorks<> — we’ve gone to great lengths to make it run on the Mac, including having a CruiseControl server retest it on a Mac mini every time a developer makes a code change.I use two Omni Group products on my Mac (OmniGraffle and OmniOutliner), but feel ScrumWorks is better suited for managing Scrum projects.

  3. Michael James,What I used OmniPlan for, was mostly outlining the detailed work items and balancing load. I’m a very novice user. For our October sprint, we are using Excel since it builds our burn down chart better and everyone has it. 🙂 I’ll check out ScrumWorks.

  4. Mark,I used OmniPlan because was already experimenting with it, just to get a feel for how it works and if I’d want to use it. It turned out that it was overkill, and we are now using a simple Excel spreadsheet hosted on a Sharepoint site. This shows us our burn down in graph from as we log our work each day. I personally really like OmniPlan and if I needed a Project-like tool on the Mac, it’s the tool I’d choose, but for Scrum it’s too much, Excel is just enough.David Weiss

  5. David I also use Excel to do the track time in the sprint and do the burn charts. However the tasks themselves are managed as index cards on my cube wall.The question I should have asked (and the first question that gets asked on the Scrum Development list on Yahoo). Did you try index cards and drawing your charts by hand? So before using a tool (any tool) did you try the simplest thing that could possibly work.CheersMark Levison

  6. Mark,We didn’t try the index cards and here’s why: We have people in Ireland, California and Japan that all use our tools. People need to know what we are doing world wide and a wall full of index cards may be “simple” but it “does not work” because our customers can not see it.David Weiss

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s