What is a Scrum Master?

Most of my friends and family have no idea what I do for a living. In fact, I’m sure a lot of my own coworkers don’t really know what I do either.  To those not in development, the title “Scrum Master,” doesn’t exactly help explain things.  The tl;dr of it is that I’m a project manager of sorts. I run a lot of meetings (about 35-40 a week!), help the Technical Team by removing impediments, and hopefully make everyone a lot more efficient.

So what is Scrum? And what’s with all these meetings?

Scrum is an iterative, agile development framework for creating deliverable products by using a time box called a “Sprint.” A Sprint is a set period of time, for example, at DreamHost, our Sprints are two weeks long. The Scrum Team is made up of the Scrum Master, the Technical Team and the Product Owner, which is the person who defines what goes into the product backlog.

 Each Sprint has four meeting types:

The Planning Meeting.

This meeting occurs on the first day of each Sprint.

In this meeting, the Product Owner presents a list of prioritized features he or she would like to have completed by the end of the Sprint. The Scrum Master runs the meeting and facilitates conversations about each of the tasks. The Technical Team votes to give each task an effort score. The goal of the planning is to decide, through mutual agreement within the Scrum Team, what will be accomplished in the Sprint. This is done by using totaled effort points from previous Sprints (known as the team’s “velocity”) and by including only the items from the Product Owner’s prioritized list that will “fit” into the Sprint. After several Sprints the velocity should become more predictable, thereby making future planning meetings more effective.

 Pro Tips:

  • Keep track of past velocities in a spreadsheet or other tool that you can quickly reference during each Planning. This will help establish how much to bring into your current Sprint.

  • The team should never bring in more points than they believe they can accomplish.

  • Ask the team their availability for the upcoming Sprint. Look at your company calendar: Do you have any holidays coming up? Is anyone taking any vacation days? Are you launching any other products in which your dedicated team member may be asked to review the work for another team? These should be taken into consideration before you establish this Sprint’s expected velocity.

  • Bring in any past lessons from the previous Sprint for maximized improvement.  Create a checklist of questions and reminders from learnings from previous Sprints. Tailor this list to each team.

The Daily Stand-up.

Frequency: Daily. Duh.

This meeting is called a “Stand-up” because everyone is encouraged to stand up, with the purpose being to keep the meeting short and to the point. In this meeting, the Technical Team reports progress of items they’re working on, typically in the format of “What did you do yesterday?” “What are you going to do today?” and “Are you blocked by anything?” We’ve gotten pretty good at these to the point where what used to be a 10 or 15 minute meeting is now 2 to 3 minutes. Efficiency!!

Pro Tips:

  • To make this meeting run super fast, use a tool like Trello, Jira + Greenhopper, or a physical board. Use a work-in-progress column and go down the list of what’s in progress, asking each assignee how the work is going.

  • In an ideal situation, a developer will only have a few tasks in progress at a time.

  • Have a “Blocked” column and be sure you address those in Stand-ups too.

  • Listen very closely for any blockers (sometimes they can be buried in someone’s update) and then do what is necessary to unblock them after the Stand-up.

  • If the same person is talking about the same task for several days in a row, ask if anything is going wrong with the task. If this particular task is huge, then the score should reflect that.

 The Review.

This meeting takes place on the last day of the Sprint.

This meeting is an opportunity for the developers to show off all their hard work over the last two weeks. Anyone internal to the company is welcome, so they can see the progress of the project.

 Pro Tips:

  • Be sure your Product Owner and important stakeholders are closely involved in accepting these items well before the review so there aren’t any serious surprises.

  • Be sure your team is ready to show off any work that’s presentable.

 The Retrospective.

This also takes place on the last day of the Sprint.

This is a closed meeting, which means the only people who should attend this are the Scrum team. In this meeting the team makes note of the “Velocity points” achieved for all the work done over the Sprint, and talks about if they met their target or not. Regardless of whether the target velocity was met, there is bound to be good information from the Scrum Team about what went well and what didn’t, so there can be some incremental improvements to take forward for the next Sprint! The ultimate goal of the meeting is to walk away with a few action items for improvement for the next Sprint.

 Pro Tips:

  • Start the brainstorming off on a positive note, asking “What went well this Sprint?”

  • When people run out of positive things to say, ask “What could have gone better this Sprint?”

  • With each item that could use improvement, ask the team to brainstorm to find an improvement “action item” and assign if possible.

  • If “action items” aren’t necessarily assignable, but instead are reminders for the whole team, add them to your Sprint Planning checklist for the team. If applicable, announce them at the beginning of the Planning Meeting as reminders for a better Sprint.

 

Does it Work?


People that I talk to outside of DreamHost ask me if Scrum really works.  The answer is absolutely yes! But your team and management has to be willing to give it a try, because it does take a few Sprints to see results for new teams.

We implemented Scrum roughly two years ago at DreamHost and I’ve seen tremendous growth and improvement of all my teams. Before we implemented Scrum, we had miscommunication and poor coordination between teams. Now we have a uniform, consistent framework for planning, work and reviews. Now other teams have insight to the development process and if they’re interested, they have tools to see the status of any given project. We now have a reliable way to estimate tasks, and four different meeting types with clear cut goals and agendas, which keeps everyone focused on the matter at hand.

Most importantly, we have a process that actually works, and we have support from management team who believe in us.

 

Recommended Resources:

 Jira + GreenHopper

Trello

Agile Estimating Agile Estimating Part 1 & part 2 .