So much has been written about a Scrum Master needing to have facilitation skills. But what about a Product Owner? In this article, I’d like to make the case that a Product Owner having facilitation skills is as important as a Scrum Master having them.

An important thing to understand when getting started with EBM is that there is such a thing as going too fast and too soon. EBM can create a lighting bolt of transparency, which in turn, could cause irrational responses. We humans can be emotionally triggered when we find a situation is much different than it appears.

Navigating leadership in complex work environments demands a nuanced approach, blending various tactics, practices, frameworks, and strategies. The road to success is multifaceted, requiring leaders to navigate and adapt to evolving situations within complex domains adeptly.

In organizations, there is a lot of time and activity spent on teams creating Release Plans. Is it worth it? Or are Release Plans just creating a false sense of security? In this article, I take a hard look at my past practices using Release Plans and how, if I knew what I know now, I would have abandoned that practice and instead used Evidence-Based Management.

As Evidence-Based Management (EBM) grows in popularity, I am often asked how to get started with it. With that, I have created a few questions that you should consider as you begin using EBM.

Overmanaging a Product Backlog can be wasteful. Product Backlog Items are no guarantee of value so details should be added with the minimum amount of detail to perform the work.

A lot of Scrum Teams are struggling to get stakeholder engagement in their Sprint Reviews. Without the proper engagement from stakeholders, Product Owners run the risk of not properly adapting the Product Backlog. There are many different ways to spawn better stakeholder engagement. This article is going to focus on an aspect often not considered: who is invited.

​​​​​​​We often get caught up in the tools we use and feel like we need to get our money’s worth by using every feature. Instead of creating transparency, using every feature of a tool often degrades the transparency of the Product Backlog. Keeping things simple and using a method such as a naming convention might be all that you need. Consider what is simple, is easiest to manage, and gives you the opportunity to create the most transparency.

The Scrum Guide is rather vague about how Product Backlog Items should be structured and how to make them transparent. That is by design because Scrum is intentionally incomplete. Understanding what attributes you are dealing with is helpful in creating a well-structured Product Backlog.

In Scrum, it is the expectation that the Product Owner makes the Product Backlog transparent. Making the Product Backlog transparent doesn’t just mean making it visible; it means making it easy to understand, to convey meaning, and to have it illustrate the ‘why’ behind the Product Owner’s decisions. Introducing levels of decomposition is an optional practice that can be applied when a situation calls for it.

I sat, as an observing consultant, in my third Retrospective of the day. I noticed high energy and openness as the room's buzz showed me signs that this team was genuinely collaborative...

Imagine Developers arriving at the Daily Scrum feeling like they want the monotony of it to end. They wish they hadn't had to bother to attend in the first place.

While teaching and consulting, I’ve had many existing Scrum Masters pull me aside looking tired, frustrated, and worn out.

I woke up Friday morning at 3 am for the second consecutive day and yet again I couldn't fall back asleep. The day before was the second and final day of my first experience co-training the new Scrum.org Professional Scrum Master II course.

From my go-to barbecue chicken to practicing Scrum, I have tried adding many different ingredients over the years. Is there a point when too many ingredients get in the way of the original recipe?  Would the Scrum framework in your world of work be more optimal with less of them?

Over the years, the tools we use to develop and deploy applications are significantly more robust, and most companies are working to become more efficient with their processes. But what is the next step toward improvement in software development? New expectations.

You’ve implemented Agile into your organization and hired professionals with Agile experience on their résumé to back it up. Yet, something is still not right. The gains that Agile promised don’t seem to be coming to fruition. Delivery times aren’t faster than they were before.

I've recently been involved with several Scrum Teams that are struggling to have the right level of detail in their Product Backlog items. Some symptoms: difficulty during Sprint Planning sessions, a massive or very small Product Backlog, or a lack of understanding during a Sprint. All of the teams I spoke with had refinement activities in place.

A Scrum myth that I have encountered: Not finishing all Sprint Backlog Items in a Sprint is perceived as a failure. I have seen organizations go as far as implementing performance indicators around Sprint Backlog completion percentage (yikes!).