- Posted by Ian Suttle on August 9, 2008
- Filed under Agile | Process
Welcome to part three in our ongoing quest to bring an effective agile development process to IGN Entertainment.
Early on I recognized one piece of criteria critical to us succeeding in bringing Scrum to IGN - everyone had to buy in. This is a change for us and as has been drilled into our noggins for years, most people don't like change. The idea isn't to change for the sake of change of course, but to continually improve our team, processes, communication, and company. I'm sure most people can buy in to that one so we had to show how the change being proposed would accomplish these goals. We're still in adoption phase (it's been about three weeks) but feel it's going really well. Here's how we got to today:
Early Warning
We notified the product and engineering (us) groups we were looking to make some changes to improve how our groups worked together. We committed to introducing the process and let them know we were going to need their help. It wasn't the intent but this got their mouths drooling a bit for new ways to improve. I received numerous emails asking when we were going to "discuss the new process." Slow down people we're workin' on it!
Introduction to Scrum
We held Scrum introduction meetings with multiple product groups to discuss Scrum including key terms, roles, and the flow. We also thought it'd be good to run through a mock sprint but in hindsight that was a bit redundant with the rest of the introduction. We also created a Scrum cheat sheet to hand out so people could leave with some reference material. Lastly we opened the floor for questions. We certainly didn't have all of the answers but expressed our commitment to work through them together.
Working Together
Scrum has distinct roles and criteria to fulfill each piece of its process. The product owner must populate a product backlog and prioritize their items. A sprint planning meeting is held to review the product backlog and assign sprint backlog items with estimates. A daily scrum is held to ask the famous three questions of "what did you do yesterday," "what will you do today," and "is anything blocking you". It goes on and can seem like a lot to rookies like us.
The fact is in the beginning nobody knows how to actually execute on these things so we dove in head first. We were committed to giving this a real go and working together to answer questions and solve problems. We helped create the product backlog, provided access to tools for reviewing and prioritizing, ran the sprint planning meetings, and took the role of getting the answers to whatever needed to be answered. Learning, team building, and communicating at their best.
Delivering the Goods
A new process with magical results and innovative ways of getting things done doesn't mean squat if you don't deliver on your commitments. At the end of our first sprint we did what we promised in a variety of ways. The product group knew exactly what to expect from us, communication was improved through sprint planning and daily scrum meetings, and the work got done. In fact the work got done earlier than expected and we started taking more items before the sprint was over! I guess our estimates were too conservative but better that than too aggressive.
Delivering on your commitments builds trust in both the process and the people.
Marching Ahead
Formally holding a sprint retrospective meeting is another piece of the Scrum process. We did this after our first sprint which revealed a number of things, the most important being to account for everything you have to do using sprint backlog items: coding, code reviews, documentation, deployments, unit testing, meetings, testing, documentation, etc. If it needs to be done, add it!
I'm looking forward to continuing our rollout of Scrum and other agile-esque methods. Each day we invest reveals more clarity and benefits of the processes which is great because day one it didn't all make complete sense :).
Have you worked with Scrum and came across pros or cons you hadn't even considered?
