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.