sprint-velocity

11 tips for Scrum team buy-in

If you’re thinking about adding Scrum as part of your software development process (and who isn’t these days), one of the key considerations in rolling it out is getting some level of buy-in from the team. Scrum is often “sold” as an empowerment tool for the rank and file, but it’s not always perceived that way by the staff.

We started using Scrum nearly two years ago, and there was definitely an “adjustment period” in crafting a day-to-day plan that worked for us. After 40+ sprints, here are some of the hurdles we encountered along the way, what we learned, what we did and didn’t like, and tips that may help others become believers in the process.

1. Let it be the team’s idea

Wait… don’t tap out yet!

Yes, the “We’re going to start using Scrum!” stone tablets may have already been delivered from on-high to your group, but even if you’re in the beginning stages of adopting an Agile/Scrum approach, having early champions come from the ranks will help with overall acceptance of the process. If you’re a manager, work at getting some buy-in from key staff to help your cause. In our group, the initial thought that Scrum might be the way to go for us came from a senior developer, and that certainly helped.

2. You will not get this right the first time

Read all the books and web articles on the process you can. If your company will spring for it, go to a week-long class off site. Knock yourself out. All of that will help, but the actual experience of getting a team up to speed will take many sprints, and you will have to make adjustments along the way. Team members will groan and roll their eyes from time to time as you collectively put the pieces together. If everyone from stakeholders on down view it as an evolving process, getting into a groove will be less painful.

3. Walk before you run

Don’t throw every piece of the process at your team during the first sprint. At worst they may freak out, but more likely they’ll just feel overwhelmed, and the mere effort of incorporating the process will become their main focus to the detriment of actual work getting done.

4. Start with paper swim lanes

Our first couple of sprints were a bunch of sticky notes on a whiteboard with some basic swim lanes for Todo, Coding, Testing, and Done. And we weren’t even that conscientious about moving the notes around. The idea was to get used to having progress tracked openly by the whole team and visually gauging how we were doing. We’d add in stickies without team approval, etc., all the things you shouldn’t be doing, but it did help us become familiar with the cadence of Scrum and breaking projects into sprints.

4. Don’t let a bad tool derail the process

Experiment with a couple of software tools for managing the process. Since we’re a Microsoft shop and live inside Visual Studio, we started with the Agile Scrum tools that Team Foundation Server (TFS) offers. For whatever reason, possibly because we were new to Scrum, we became frustrated trying to shoehorn that particular tool into our team’s workflow. It just did not work for us. Once we switched to Jira, it no longer felt like we were fighting the process.

6. Hold off on using story points

Tracking progress by assigning story points is a key part of Scrum, but it can also trip teams up. There can be a paranoia factor, that management may be concerned solely with numbers, velocity, and burn down charts. Also teams can struggle with the notion that the points are intended to be more of a slushy, relative weighting than hard and fast hours of effort.

Once we started storypointing as a team, the whole process finally fell into place for me. Yes, you’ll soldier through the “What does a 5 really mean?” debates more than once, and it will take staff a while to get loose with estimating this way, but you’ll get there.

7. Suck it up, have the daily meetings

This can be one of the most contentious part of Scrum for a team.

  • “Just look at the board, you can see what I’m working on!”
  • “We don’t need to hear about every line of code Joe added yesterday!”
  • “We’re not children!”

This is something the team should start doing from day one (the meetings, not the whining). As a manager, this can be the one time you say to your group, “I know this seems like overkill, but trust me on this, just give it a try.”

8. Keep daily meetings time boxed but loose

To help with buy-in of the daily standups, make sure they’re kept to 15 minutes max, but allow for some flexibility on how they’re run. Our meetings have shifted from the traditional “I did this yesterday, I’ll do this today, and I have this impediment” to a more relaxed conversation focusing mostly on impediments and questions. You’ll have the boards and charts to look at during the meeting to see how tasks are moving along.

9. No stakeholder input during daily meetings

If you have higher-ups turning daily team standups into “can you get {insert feature here} done by Friday?” status meetings, you’re doomed. The team will resent it and, in turn, the whole process. Anyone can listen in, but only members of the team should speak. This was not a huge issue for us, but it’s something to be mindful of.

10. Piggy back ceremonies onto daily standups

Early on there was a bit of a “death by meetings” vibe with the daily standups, the retrospectives, the reviews, the backlog refinements, the planning. We found combining meetings where it made sense helped. For example, instead of doing a daily standup and then backlog refinement a half an hour later, all of the Scrum “ceremonies” are piggybacked onto our daily standups. As a result, we only ever meet once a day.

11. Don’t skip the retrospectives

Sadly, in most corporate environments, there are few opportunities for rank and file to get together and discuss what is and isn’t working. Scrum incorporates those types of water cooler conversations as a formal part of the process. These retrospectives at the end of each sprint are vital. Not to get too Oprah-esque here, but a core human need is to be heard and understood, and that’s a key part of buy-in for any team whether it be Scrum or otherwise.

So… take it slowly, expect an evolving process, keep lines of communication open, and view implementing Scrum as a collaborative, team effort. And one day you may scratch your head and wonder how on Earth you ever developed software without it.