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:

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.

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:

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.

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:

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.

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.

Would you like to include comments?

Tagged:

About the Author

As the founder of Mountain Goat Software, Mike Cohn specializes in helping companies adopt and improve their use of agile processes and techniques to build extremely high-performance teams. He is the author of User Stories Applied for Agile Software Development, Agile Estimating and Planning, and Succeeding with Agile. Mike is a founding member of the Agile Alliance and Scrum Alliance. He is also the founder of FrontRowAgile.com, an online agile training website. He can be reached at [email protected] or connect with Mike on Google+.

Having someone on a successful team be a ScrumMaster or at least mentor to another team can be a great way to spread knowledge and best practices through an organization. Good idea!

Posted by mikewcohn on 2014-03-12 15:27:50

Thanks Mike et all. Great points from everyone :) All the very best for this year. One more thing I would like to do is motivate team members to take the role of scrum masters for other teams as they mature with the processes.

Posted by Rajaraman Kannan on 2014-03-12 09:16:28

Thanks for linking to The Board Mike :) Counting silently sounds like a good strategy.

And you’re absolutely right that my problem with jumping in with an opinion was primarily when I was both ScrumMaster + developer or formerly a developer on the team. Also, Garretth was right to bring up the “power of silence.” (Wasn’t that a Simon & Garfunkel song? ;) The best way I’ve found to be silent is to count silently in my head: 1, 2, 3, 4… and that allowed me to stay silent longer than others could. And so they’d speak up first. Thanks for mentioning you’d discussed this today.

Posted by mikewcohn on 2014-01-08 19:50:42

Thanks Mike - this is a pretty inspiring post - It's really made us think about what we'd like to resolve to do this year. In fact we based a whole half hour Agile TV show around this :)

Posted by Kirstin Donaldson on 2014-01-08 19:38:48

That’s a great story and it often takes something like that for people to see the benefits. But once they do, they become a team’s strongest advocates. Thanks for sharing it.

Posted by mikewcohn on 2014-01-08 09:27:06

Thanks:-) ...and yeah, you can try that but i will tell you an actual story.

One member of our team was not 'feeling' good about writing these acceptance tests and actually said so in a daily scrum out of utter 'delay' it was causing him. Before i could say anything another two member spoke about a user-story that we had completed (and called 'done') before we included acceptance test in 'definition of done'. These two members (while pair programming) found 19 bugs while completing the acceptance tests in the current sprint. They were sold on the idea of acceptance testing!

Posted by M.Nafees Sharif Butt on 2014-01-08 08:45:08

Hi Nafees—

Great resolutions. I’m happy to see helping the product owner in there. I see too may ScrumMasters who feel they are on the “side” of the team and dedicate nearly 100% of their time to helping the team. Product Owners need help sometimes, too, and a good ScrumMaster recognizes that. Great point, too, on doing less acceptance tests through the GUI. Testing through the GUI is expensive (to write the tests), time-consuming (to run the tests) and brittle (as they break easily). It’s necessary to do some but should be minimized in favor of testing at other layers. Of course, if I were on your team I’d probably quote you out of context and tell the rest of the team, “OK, our ScrumMaster has written ‘less acceptance tests’ as a goal for 2014. Let’s make him happy and not do any!” ;)

Posted by mikewcohn on 2014-01-07 10:18:37

HI Anis—Yes, I think product owner availability is one of the biggest challenges. They have very tough jobs—they are pulled outward (toward customers and the marketplace) and also inward (toward the team). It is challenging.

Posted by mikewcohn on 2014-01-07 10:14:43

As a ScrumMaster,a) Do the necessary mix of lobbying and escalation to ensure that product owner is empowered fully and is not deterred because of functional managersb) Coach the team into better practices on testing; lesser acceptance tests through GUI, facilitating until TDD becomes second nature

Posted by M.Nafees Sharif Butt on 2014-01-07 04:56:42

Sounds like a great set of resolutions, Nikos! Good luck with them.

Posted by mikewcohn on 2014-01-06 21:40:00

as a scrum master, i would like to experiment more, evaluating more, accepting more, memorising more and when i could not escape from my local optimums i've been stuck in..restarting!..this loop i would like to become my new habit!

Posted by Nikos Batsios on 2014-01-03 04:50:16

Availability of the product owner is always a challenge, as a project manager we do not have an authority on the business side but can only explain the importance of their commitment for the project success

Posted by Anis Malouche on 2014-01-03 03:43:10

Good luck! I haven’t broken any of mine yet (so far)!

Posted by mikewcohn on 2014-01-02 18:48:39

Thank you Mike. I made a simple resolution, Which I can keep up. One small baby step at a time, through out the year. :)