Matt Berseth

On September 11th and 12th I was in Orlando FL attending Mike Cohn's ScrumMaster Certification course.  The course consisted of two 8 hour days filled with scrum techniques and best practices.  I found the course valuable.  If you haven't met Mike Cohn, he is a high energy person that is passionate about scrum as well as software in general.  He does a good job presenting the material and makes an extra effort to tie it back to techniques you can take back to the office with you.  As a process, scrum is pretty flexible and Mike tells a number of useful stories about how successful scrum teams have adapted scrum to fit their organization's needs.  I found this useful as each organization tends to have its own unique quirks and I think it is reassuring to hear how others have adapted scrum to fit within their own organization.

Going into the first day of the course, I was a little skeptical of what the value would be to me personally.  I had worked on scrum teams in the past and figured that I had a pretty good idea of scrum was all about.  Needless to say, once again my ego was over inflated.  Here are a few points from Mike's course that stood out for me.  I figured I would share them for those that don't have the opportunity to sit in with Mike's ...     

The Daily Scrum Meeting

With some of my previous scrum teams as we progresses through the sprint cycles, we end up getting a little bit sloppy with the daily scrum meeting.  The daily scrum ends up going from a 15 minute stand-up meeting where only the 'pigs' are speaking to a sit down 45 minute daily status meeting where we go around the room reporting nothing more than how many hours are left on each task we are working on as well as every excruciating detail of any issue that was encountered.  While these discussions are needed, they are out of scope for the daily scrum.  Because on the teams I have been on the ScrumMaster is also the boss, the meeting also usually starts and ends with a 5 minute speech about other topics that are outside of the scope of the scrum team.  Luckily, Mike has a handful of tips that I think my current team can use to help keep this meeting short and productive.

1. The ScrumMaster should be a position of facilitation, not of authority.  The purpose of this meeting is for the team to get a feeling of where the other team members are at.  As the different team members speak, they should be focusing on each other.
2. The daily scrum meeting is about team synchronization, not about solving problems or designing solutions.
3. Remove the chairs from the scrum meeting room, or have the meeting in the hallway.
4. Have the ScrumMaster pay some sort of penalty if the scrum takes longer than 15 minutes.  Make the penalty small, yet provides the ScrumMaster with enough incentive to keep the meeting at the 15 minute mark.

Add Meetings to the Sprint Backlog

Mike told a story about one scrum team he worked with that included meetings in their sprint backlog.  So, if Manager Bob schedules a 2 hour project update meeting at the end of every month, there would be a 16 hour sprint task for the meeting for your 8 person scrum team.  Depending on your project, 16 hours might equate to one or more features.  Manager Bob might not be so incline to schedule that meeting if he see's that he can have feature XYZ instead.  I believe the idea here is that it might be more productive if Bob would attend a few daily scrum's he could get a feel for where the project is without taking up 2 hours of everyone's time.  Its a win-win, you have to attend one less meeting and the customer gets feature XYZ. 

Most Teams use 2 Week Sprints

Mike didn't really have a scientific reason for this.  He said he recommends 2 or 4 week sprints and that it is up to the individual teams to decide what length best fits their team and organizational needs.

Architect with a Tracer Bullet

There were a few people at the course that were just starting brand new development projects and were curious about how architectural tasks can be completed within a 2 week sprint.  If you aren't familiar with scrum, at the end of each sprint the team produces a software artifact that is potentially shippable.  Architecture is not usually shippable (unless you can find someone to buy all of those UML diagrams).  Mike's advise was to build enough of the application (maybe even just a prototype) that uses the architecture.  He said you can think of this as a tracer bullet.  You want to build enough an application using the architecture that you are sending a tracer bullet through a each of the architectural pieces. 

Tools

I have used commercial scrum tools as well as plain old Excel for managing the scrum process.  Both approaches have been a little awkward so I was curious what Mike suggested.  I was surprised to find out that he primarily uses recipe cards and a whiteboard.  I would like to try this.

Works Best Bottom Up Instead of Top Down

I thought this was an interesting point.  Mike mentioned that with most successful scrum teams, the push for moving to scrum started bottom up (starts with the individual contributors) instead of top down (starts from management).  Logically, I think this makes sense.  The scrum team is the focus point, I can see how scrum might not work unless the team buys into it.

That's it.  Enjoy!