Better Software Conference – Day 1

As noted previously, I spent all of last week at the Better Software Conference. I was speaking on Thursday, but prior to that, I had the opportunity to attend a variety of technical discussions and workshops. Here is my coverage of the first day.

After travel delays that turned 5 hours of flight time into a buddy-travel script, I attended Jean Tabaka's session on Scrum: Project Management for Agile Software Development. When I walked in the door, I knew basically nothing about Scrum other than it was a type/set of agile practices. I'd heard of RallyDev from their training, but not even much there. I have to say that overall the experience was great.

First, let's talk a bit about what Scrum is. Scrum is a set of practices for agile development. It revolves around “3 ceremonies and 2 artefacts” which fit together to create the concept of Sprints. Each Sprint is essentially a phase of the project which is populated by a number of work items from the Product Backlog which are called the Work Backlog. A few key meetings such as Daily Standups which last 10-15 minutes every day and requires everyone to share what they have and haven't accomplished along with what's blocking them. Then there's a final meeting of each Sprint consisting of a demo of the new functions/software/etc and a review of the iteration. Sounds pretty simple, right?

What Jean did was quite interesting… she had giant sticky-note pages with various key points describing the process, the history, practices, etc and then collected a number of points from the audience. Then she split the workshop into a series of hour long Sprints and let us set priorities on which topics should/shouldn't be covered during each iteration. Since we (aka the customers) were allowed to pick the specific items from the Product Backlog, we were able to cover our most important points first. At the end of each session we did the Sprint Review to discuss what went well, which related points had been covered, and what strategy changes to use to improve the next iteration. We came up with things such as identifying the scope of work for given items and holding questions until specified breaks to speed the coverage. During the 10-15 minute breaks, we chose which points to cover. At the end of the day after our 5 (6?) sprints, the general consensus was that we covered the most important items, had a better understanding of the process, and didn't mind that we still had a third to half of the items left.

This seems like a minor point, but it was a great object lesson showing that everything that seems important isn't always so once the project begins and a product begins to form. If there was nothing else to take away, the power of this lesson was enlightening and immensely satisfying.

During the midpoint of the day, we did another exercise to further demonstrate this. We created our own product – a tour brochure for a Martian visiting Earth – from a rough set of guidelines and requirements. Each team chose a Customer and was tasked with negotiating a set of requirements they were going to meet during this Sprint along with doing the work involved. We ended up with a pair of 10 minute work cycles with a Standup Meeting in between. We laid out the top 4-5 items in our work logs, let people step up to the tasks (and assigned the rest), and dove in for 10 minutes. Yes, we literally stood up during the Standup meeting. For the second 10 minutes, all of the ideas began to come together to create the product and then our Customer demonstrated it for all to see.

Overall, the process was amazing. We were able to get direction from the Customer on priorities from the beginning. Since we were all working in a common space, we were able to kick around ideas and actually develop a theme for all of us to work towards. Finally, once we had work starting to appear and some of our subteams wrapped up, we were able to piece together the product into a cohesive whole with litte difficulty. It was a contrived project, but the process was satisfying.

In summary, using the Scrum process to teach the Scrum process was a great object lesson. Jean did a great job of getting the core points across, teaching the basics of the process, and keeping progress moving. The only complaint was that as a group of newbies, we tended to choose things which were important to us early on instead of what would have improved understanding in the process and teaching. I think a bit more guidance on the core issues during the first or second iteration would have helped head off a few questions that cropped up later on. If I had the opportunity, I'd definitely go to another Scrum/Project Management course from her.