New Year’s Resolutions for ScrumMasters and Product Owners

With the new year, it's time for some resolutions. I've got the same old ones (lose weight, eat better, get more sleep, help more old ladies across the street, stop calling every cat I see "Fajita," and such). But since I fail at those every year, I thought perhaps it would be better for all of us if we made some Scrum-related resolutions. And so here are a couple of suggestions for both ScrumMasters and Product Owners. Each is a resolution I've made in the past during my time in each role.

For ScrumMasters


Let's start with two possible resolutions ScrumMasters may want to make:

1. Always let team members speak before you do in meetings. This was a hard one for me. I'm both opinionated and impatient. When an issue comes up during a meeting, it can be hard for me not to instantly blurt out my opinion. This often shuts down debate that might otherwise have occurred.
 
I finally got over this problem (mostly) years ago when I resolved to always let two team members give their opinions before I (as a combination ScrumMaster / developer) would share my own.
2. Praise the team more often. I am very much a glass-is-half-empty type of guy. A team cuts their defect rate by 50 percent, and I want to know why not 100 percent. Velocity goes up by 5 points, and I think they could have gotten one more point. Part of this can be good; I am definitely always looking for ways to get better. And I put the same pressure on myself. But, I've learned that, of course, it can be depressing for a team that is making tremendous improvements to always hear about how there is still room to improve. Prevent this from becoming a problem by making it a priority to praise them more often.

For Product Owners

Here are a couple of resolutions Product Owners may want to make:

Redirect the team less often. It is extremely tempting to redirect the team every time you come up with a great new idea. Of course, you know how bad this can be as the team gets buffeted from one top priority to the next. Simply resolving to stop redirecting them, though, is unlikely to work. So here are two things you can to help achieve this resolution:

1. Sit on changes for a day before introducing them to the team. Just commit to yourself that no matter how good or urgent an idea seems, you will hold off for one day before asking the team to work on it. Rarely is a change so critical that it must be started immediately. Stalling for even a day gives you time to reconsider. If the change seems as critical tomorrow, go ahead and interrupt the team.

2. Write it down somewhere. Often telling the team to work on something new is just a way for the Product Owner to get the item out of his or her head. You can also achieve this by making note of the desired change. If you're using a tool to manage your product backlog, add it so it'll be visible when you plan the next sprint. If you don't use a tool, note the item in a simple text file you can review before each sprint planning meeting.

Be more available. I've surveyed a few agile teams about what their Product Owners could do better; "Be more available" always ranks near the top of the results. If you're a Product Owner, resolve that 2014 will be the year in which you fully address this problem. Here are a couple of things you can do to make that happen:

1. Spend time in the team's area. If your desk is away from the team's shared workspace, do something like tell the team you will spend from 1 p.m. to 3 p.m. every day in their area. This time isn't for any specific meeting (although meetings can occur during this time). Rather, you just bring your laptop, find an empty desk or surface in their area, and do your normal work right there. If the team needs you, you're just a few steps away. When they don't, you just do your normal work but near them.
2. Share a secret code with the team. Establish a rule with the team that if they email you with something like "[Today]" in the subject line of an email, you will respond before going home for the day. (Or perhaps before going to bed at night, if working remotely from the team.) Discuss with the team what constitutes appropriate use of this. For example, they shouldn't email you 100 times per day with this secret code. (If they need to, see the item above about spending time in the team's work area. You've got a problem that can't be solved by email.)

Last, but Not Least

Resolve to Improve. Whatever you choose for 2014, resolve that by the end of the year, you and the team you're working with will be better than you are today. And it wouldn't hurt if you ate better and got more sleep this year, too.

In the comments below, please let me know what agile-related resolutions you've made for 2014.