Author name: Chris

A man with a plan.

When Product Owners Go Wild

Is this your org?

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.

Coaching Agile to a Waterfall Mindset

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!

Unpack Those Adjectives!

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.

How will Scrum Evolve?

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.

The Pillars of Servant Leadership

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.

Optimizing To Prevent Failure

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.

When Things Break Down

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:

Causes of Delay

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.

Excuses

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?

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.

Scrum Master: The Wearer Of Many Hats

Whether it’s as a teacher, mentor, facilitator, or coach, the role of Scrum Master is expected to wear a lot of hats to fit into many different situations. What we do on a day to day basis depends on who we’re talking to. Product Owner? Stakeholder? A different team’s lead? Individual contributor? Another Scrum Master? We have a lot of faces to put on to effectively interface with, coordinate with, and collaborate with any given part of the organization. This article takes a look at the different roles, and gives practical examples of what these things may look like.

https://conceptsandbeyond.com/scrum-master-is-a-teacher-mentor-facilitator-and-coach-whats-the-difference/

Software For Standup Meetings

Remember when we all didn’t use Slack all the time? There’s a pretty cool app for Slack called SUP. In a nutshell, it allows you to collect a lot of data from team members which they can answer throughout the day….meaning you don’t have to take time during the meeting to get arbitrary stuff like mood, etc. That way you keep the main thing the main thing during the actual standup. SUP can be found over at https://sup.today/

The things that make a standup great today are the things that made one great 10 years ago, only now we may be using different tools to reach the same objectives. We didn’t live in the age of remote work and distributed teams a decade ago, so the tools we use have had to evolve. Still, a good meeting is a thing of beauty. Here’s a rundown of what it takes to keep things running smoothly.

What’s the Best Scrum Software?

With so much to keep track of, what’s the best software out there to use to help Scrum Masters and teams get their work done? As you may expect, there are a ton of options on the marketplace, and the best solution for a SAFe team may not be the best solution for a 10-man small shop. This article lists the pros and cons of some of the best solutions currently out there. While a lot of these solutions have paid options, a surprising number of them offer unlimited free tiers as well.

Agile: Not Just for Breakfast Anymore

Since the early 2000’s when Scrum/Agile really started coming into its own in software development, a lot has changed. The non-software world took notice, and now we’re seeing Agile methodologies being used in manufacturing, IT, DevOps, and other areas. Perhaps somewhat ironically, Agile is constantly evolving, iterating, and changing. As such, there are trends concerning where the philosophy of Agile is headed as a whole (beyond just Scrum.) This article discusses some of those trends. I’m particularly interested in seeing how AI and ML can assist within an Agile framework, and how that might help us all be even more efficient.

Scrumban: A Different Perspective

Is Scrumban as easy as borrowing what you like from Kanban and lumping it in with what you like from Scrum? Nope. At least, not per se. There are a lot of things to consider that boil down to how your individual organization runs. This article makes some excellent points about things to consider, and some of the suggestions may surprise you.

Scrumban: A Scrum/Kanban Hybrid. Is It For You?

We know what Scrum is. We know what Kanban is. What if we could take the best of both worlds and put them together. Would it work? The short answer is: It depends on how your team is structured, and what the overall goals are within your org. It certainly *can* work, but is it right for you? I’ve often been intrigued by the concept of Scrumban, and think it has some excellent advantages over traditional Scrum…sometimes. Here’s a great article pointing out the pros and cons of this hybrid methodology.

Can Scrum and Kanban Be Used Simultaneously?

Scrum. Kanban. While certain people think these two approaches are somehow opposed to one another, the reality is more nuanced. Kanban may be the right approach for some organizations, while Scrum is the better approach for others. But can the two philosophies be used simultaneously to reap the benefits of both? Sometimes it’s not either/or, but both/and. The short answer is yes…but there are some caveats to making all of it work together as it should. This article explores the question in detail, and the conclusions may surprise you.

Great Article About Daily Standups

So what about this whole “daily standup” thing?  Is it actually useful, or is it a waste of time?  The short answer is, it can be both.  Martin Fowler has written a very insightful article about how to ensure your daily standups are as effective and productive as possible.  It’s got many direct tips and tricks that go far beyond the standard definition. Worth a read for anyone in Scrum!

Scrum et al.

Way back in 2006, Ken Schwaber (one of the creators of Scrum) gave a great talk at Google that describes how Scrum fits in with everything around it, and what sets it apart from the other methodologies being used out there.  It’s filled with insight and depth about this field.  It’s an hour long, so grab some popcorn and a drink, and check out the zen of Scrum.

Why YOU Should Be a Scrum Master

Being a Scrum Master is a calling for some, but what skills does it really take to get into the field?  This article explores some of what both recruiters are looking for and what current Scrum Masters are offering.

Three Tips For New Scrum Masters

Mitch Lacey has written a great article containing some solid advice for new Scrum Masters.  Whether you’re only new to Scrum, or just getting into tech, it’s a good read.

The Lean of Scrum

David Starr has written an excellent article discussing how to make the art of Scrum even leaner and meaner.  Translation = more efficient.  There are some great tips here to help improve the Scrum process by improving lean thinking.  Worth a read!

When is Scrum Not Scrum?

superscrumman

So you get hired to a company to do Scrum on a project.  Great!  As you begin to look around and settle in, you start to realize that something is amiss.  You hear the words “agile!” and “Scrum!” and “sprints!” being thrown around, when it starts to dawn on you that what you’re seeing isn’t actually Scrum.  It’s easy to be Scrum-like, or even practice “Scrum lite”, but when is Scrum not actually Scrum?  I’d like to paint a few scenarios where there would be cause for concern:

Example One:

The stakeholders/management decide to implement scrum to manage a software development project. The powers that be give approval to use Scrum but insist that the team follow the prescribed software development processes (e.g. waterfall) to make sure the team is doing only what it’s supposed to be doing.

Example Two:

The management decides to try using Scrum to manage a non-software development project.  The team isn’t working together (i.e. non-collocated) and the Product Owner has neither the time nor inclination to prioritize the Product Backlog.  According to the Product Owner, everything is top priority.

Example Three:

The management implements Scrum to manage a software development project. The team collectively decides they don’t have the time to do retrospectives at the end of each sprint.  Further, they only do standups once a week.

If you found yourself in one of the above scenarios, what would you do?  Scrum works as a methodology only when we adhere to its principles.  Can Scrum be adapted to fit within an individual organization and/or process?  Of course it can.  But when we start changing the recipe in significant and meaningful ways, we lose our notion of what the final product is supposed to taste like.  Scrum works when it’s frequently inspected and transparent.  Quickly adapting to fit the situation is key…that’s why we’re agile!  When the team’s ability to adequately respond to either outside business needs or internal issues is neutered, I believe the spirit of what makes Scrum “Scrum!” is lost.  Personally, if I got hired and walked into one of the above scenarios, I would do everything in my power to correct the lilting agile ship, and implement Scrum in the way it was meant to be used. You’re a Scrum Master.  Save the team!