A few weeks ago, I became a Certified Scrum Master.

Though I’ve been working as a Scrum Master for almost 4 years, the course was a great refresher, and reminded me why I love Scrum. (I took my course with trainer Robin Dymond @ Innovel, whom I highly recommend).

If you work at a company that doesn’t lend itself nicely to Scrum—for example, a company with a shared resource pool—there are still some really valuable lessons we can learn.

What is Scrum?

Scrum is a framework by which teams can do work. Basically, it is a set of rules and guidelines that teams can follow to effectively tackle iterative software development.

Team Self-Organizing

In Scrum, if something goes right, the team is responsible; if something goes wrong, the team is responsible.

The Scrum Master guides the team to self-organize and lets them make the final call/decision on what they work on and what is feasible. As a PM, sometimes we may find ourselves telling our teams what to do instead of relying on them to tell us what they can do. That’s a trap I think a lot of PMs can fall into.

Give your team the tools and resources they need, and let them take ownership and make decisions (with your guidance).

Multitasking

A big element of Scrum is to keep focus and reduce multitasking as much as possible.

Engineers face this daily – being pulled in many directions and being constantly distracted from what they are doing. According to the Scrum course, on average, it takes someone 20 minutes to get back to the work they were doing after being distracted.

What does this mean for Project Managers?

Well, I think as PMs we should give ourselves a pat on the back, as we don’t usually have 20 minutes in between meetings to switch gears. I think we should consider blocking dedicated time off in our calendars for each project we need to work on to have some focus time.

For other team members, at least from my perspective, I think we (especially PMs) should to find a way that we can ping our team without disturbing their work. When I ping an engineer and it’s really not urgent, I will say “get back to me when you can” but it comes in at the same priority as “prod is down i need your attention ASAP”. One option that I’ve actually started experimenting with is using Slack’s Snooze function:

Consider using the “snooze notifications” for when we are focusing: as PMs, we a) see someone has snoozed notifications and know they are busy, we b) can say, when you un-snooze can you get back to me on a, b, c, and c) when something is actually on fire and we need their attention, we can send a notification anyway that will break the snoozing.

Ordering, not Prioritizing

We’ve all been there: reviewing a task list with the client and ask them to indicate the priorities of each task.

In a list of 25 items, we will probably end up with 2 blockers, 20 highs, 1 medium, and 2 lows.

Well, that’s not realistic; the team can’t work on 22 items at once. Scrum helps us think about this in a different way; instead of prioritizing, we should try ordering. That way, we agree that they are all important, but it puts the onus on the client (with our support) to order the work in a way that is doable, technically feasible, and will keep the team working on the most important work.

Stop with the “What” and “How” and focus on the “Who” and “Why”

This isn’t as much a Scrum belief but a methodology for writing better user stories, and solving deeper problems for clients. If we focus on the “who is this for?” and “why do they want it?” as opposed to the “what are they doing” or “how do they do it” we will be more effective at solving problems for our customers.

Our customer will come to us and say “Can you please add reporting functionality to this and this” and as PMs, we are trained to say “Yes absolutely let me get the LOE for you”.

As Project Managers, we should change our approach: instead of just doing what clients ask, we should get to the root of the issue they are encountering by asking WHY they want this. What is the underlying problem they are trying to solve? In this example, is reporting even the best solution? Or maybe they actually just want a built in dashboard, or a CSV export, or something entirely different?

If we understand the WHY, we can better support our clients to help establish the best solution. Maybe reporting is in fact the best approach; maybe it’s not. We won’t know until we understand the why.

Unicorn Hours

Unicorn hours are magical, fairy-land hours – i.e. when we estimate a ticket will take an engineer 4h, we really mean 4 unicorn hours, or 4 totally focused and un-distracted hours. How many focused and un-distracted hours do we get in a day? Well, that depends on how much snoozing someone sets on their slack notifications.

Keeping in mind that oftentimes our resources will estimate in “Unicorn hours,” we should continually expect that tasks will take a bit longer since there are so many distractions when sitting down to do work.

Acceptance Criteria / What does DONE mean

Each work packet (JIRA story, Teamwork task, Trello card) should have some sort of clear, tangible outcome; that way, the team member knows the work is complete and we have something to test against.

Sometimes, it’s not easy to establish what the acceptance criteria would be; this can be a discussion with the team member working on the ticket, so you all can agree on when you know the ticket is complete. Think about acceptance criteria as all the things that have to go right for you to consider that ticket complete.

If you are interested in learning more about Scrum, check out scrumalliance.org.