Developers own the Sprint Backlog.

Every good Scrum Master knows this, but do the Product Owners always respect it?

A common challenge I see involves developers who feel they must ask permission from the Product Owner before pulling items into a sprint. Or worse, a PO who actively controls the Sprint Backlog by pulling items in and out whenever they feel like it. (Blasphemy!)

As you might imagine, this presents a lot of challenges for the team. If the devs can’t adapt, it can lead to incomplete sprint goals, not to mention potentially driving the buildup of technical debt. Scrum very deliberately puts developers in control of the Sprint Backlog to avoid this scenario. You don’t need PO permission to pull items in or out, and you can say no to requests mid-sprint.

The PO should ensure the Product Backlog is properly ordered so the teams know what’s being prioritized, and they should work with developers to form a Sprint Goal. Additionally, the PO needs to trust the developers to get the work done, and to manage their sprint time wisely. If the team decides they want to deal with technical debt, architectural issues, or even pull in new work from the backlog, as long as it doesn’t endanger the Sprint Goal, the PO should have no issues with it.

Developers: If you feel like you need permission from your Product Owner to pull items in or out of a Sprint Backlog, be sure to make your Scrum Master aware of it, and by all means bring it up in your next retrospective. After all, if we don’t keep up with the Scrum trinity of transparency, inspection, and adaptation, issues certainly can and will arise.

Scrum is ultimately about people, and more specifically having those people (hopefully) on the same page. But it doesn’t always work out that way. Some are rooted pretty deeply in the Waterfall culture. To that end, here are some helpful reminders when approaching individuals/teams who aren’t all-in on Agile just yet:

1. Changing people’s behavior cannot be achieved through force.

2. People and teams will only make changes when they have an intrinsic desire to do so.

3. Your role is not to force individuals to adopt Agile practices, but to make them aware of their Agile potential. Show them there’s a better way.

4. It’s important to remember that your message may not be received immediately. Change may take time.

5. Consistent and repeated communication will become a habit, increasing the chances of your message being received.

6. Don’t assume that your team members can read your thoughts. You know what they say about assuming…

7. It’s necessary to communicate your ideas and expectations when necessary. Scrum is transparent, and your ideas surrounding Agile should be as well.

8. Your effectiveness as a leader goes beyond your ability to speak. Actions, say:do ratio, attitudes, willingness to listen/empathize all go a long way.

9. Your greatest strength lies in your ability to listen and understand the needs and perspectives of your team members.

10. A hybrid approach to change is the best one. Engage Management. Engage Stakeholders. Build alignment. Then engage your teams.

The sooner you accept and implement these approaches, the sooner you’ll get buy-in and alignment toward Agile in your org.

By embracing these principles, you will foster a more positive and productive working relationship with your team!

Being a Scrum Master requires a lot of concepts, ideas, and….adjectives? We do a LOT to help teams stay on track and become the best versions of themselves they can be. To that end, I found this really cool list of things Project Managers in general do, but it absolutely applies to Scrum Masters. If you’re looking for ways to help define the things you do in the role, this may be helpful.

From the days of its inception, Agile, and specifically Scrum, have been in a constant state of iterative refinement and evolution. Just as within a sprint, the more that’s known, the more we can improve aspects of the work. As teams around the world have adopted Scrum, more tools have become available, and the concepts of Agile reach ever-deeper into workflows, the inevitable talk about “what comes next?” or “a post-Scrum world” has begun. I don’t doubt Scrum as we know it today will evolve to meet the needs of an ever-changing technological workspace. However, I think the overall zeitgeist surrounding Scrum, and what’s brought it this far since the mid-90’s, will continue at its core more-or-less unchanged. The chart below does a brilliant job of defining the “lifecycle” of a concept, or philosophical approach to work. I find myself wondering where we as purveyors of Scrum are on this list? I’m not sure it can be broken down so simply into a chronological timeline. After all, there’s no way to put the concept of Scrum/Agile back into the bag now that it’s been around for a few decades. While it’s hard to imagine a better ideological approach coming along for certain kinds of iterative design, history has proven there’s always a better mousetrap lurking just around the next bend. I can’t help but wonder what that’s going to look like in the Scrum world.

It’s interesting to watch how Agile and Scrum have evolved over the years. Every so often the Scrum guide gets updated, or some new variant like ScrumBan rolls around. Still, the concept of the Scrum Master being a “servant leader” remains constant. I find these principles to be spot on, and they define pretty clearly the overall attitude and purpose I take in the role of being a Scrum Master. There isn’t a single item in the list below that could be removed without significantly degrading the effectiveness of a good Scrum Master.

People frequently refer back to “the good ole’ days”, a time when things were simpler, or at least easier to navigate. On a scrum team, that could be a month ago. Changes for the sake of making changes sometimes come with a great opportunity cost. If we see management or team members making statements like the ones below, there’s ample reason for the Scrum Master to dive in and figure out what’s breaking down. Did management recently change seating around? Did team members get pulled and placed on other teams? At the end of the day, finding why something isn’t working can become a great opportunity. Knowledge is expensive, and time-consuming to attain. Scrum Masters should always be on the lookout for ways to help their teams gain the most knowledge with the least amount of investment.

We’ve all been there. We’ve watched as something melts down in front of us. Whether it be code being written, or interpersonal conflicts arising, or friction with another team, things can…and do…happen around us all the time which keep our ship from sailing smoothly. When we look at some of the reasons things break down or get delayed, some age-old culprits rear their heads:

When things fly off the rails, most people start making excuses rather than doing a root cause analysis of what caused the actual breakdown. Excuses aren’t helpful. Finding reasons *is* helpful. I love the bottom point in the graphic below. Being able to say “we failed” is critical, since “we” collectively didn’t help the person not to fail.

With all this in mind, what are some potential causes of causes? Sure, things break down during a sprint, or with Product Owners or Stakeholders, but behind every breakdown is a cause. What are some of these causes of causes?

Honesty and accountability are key in overcoming these obstacles. It starts with personal honesty, and being able to recognize when a mistake has been made. This isn’t necessarily punitive or meant to be a negative. Unintended consequences happen all the time, and we learn and glean knowledge from these types of errors. Ultimately, the goal isn’t to pass blame then sit back with your arms folded in some kind of moral superiority. If one team fails, we all fail. If one individual fails on a team, the whole team fails. The Scrum Master is at the heart of this, having their pulse on what’s going on inside a sprint, or between team members. Team issues are inevitable, but our response to them doesn’t have to be.