As a Scrum Master have you ever been in a situation where you were in a team discussion and you agreed to a team decision because everyone was in for it, although deep down you were not really inclined or in agreement with the decision. Also, did it happen that at a later point in time, most, if not all, of the other team members shared a similar feeling that they agreed to a particular decision because they didn’t want to disagree with the rest of the team.

As a Product Owner, one has to dive deep into Product Management in order to create Valuable and Useful products. One of the key aspects in Product Management is to “know thy customer”. Knowing, understanding the behaviours, attributes and traits of the customer can help the Product Owner greatly to know how a customer would respond to a product within a specific market segment.

People tend to highlight that Scrum is best suited as training wheels. However, what most people forget is Scrum is a means to an end; it's not a silver bullet. It is only as good as the members of the Scrum Team. If your team is not getting the desired results with Scrum, then it probably is not Scrum, it’s your Scrum Team that is ineffective.

You have been working on an agile team or maybe a Scrum Team. And every time someone refers to requirements, they mention about User Stories. So, now you have started to believe that User Stories are Requirements. But is that true?

What is the Product Owner accountable for? From the Scrum Guide: The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. The important part to focus on here is - maximizing the value of the product. But how does the Product Owner know that they are really maximizing the value of the Product? Well, that is where Dan Olsen’s Product Market Fit and Evidence-Based Management from Scrunm.org becomes helpful.

If you have come across the book Reinventing Organizations by Frederic Laloux you would know that there are many different ways an organization can be structured. Similarly, there are many different ways how leaders act in these differently structured organizations. When there is an Agile Transformation happening in an organization, the status quo in the organization is challenged.  The answer often to this is to make teams adopt agile practices, method,s or frameworks but the leadership, management and rest of the organization stays in its own existing structures. Such Agile transformations often do not work. Reason being, true agile transformation requires a fundamental mindset shift not only in how we develop the products but also how we lead and manage the organization.

A Product Owner is an important accountability when it comes to creating Valuable products. However, a Scrum Team may not always have a Valuable Product Owner. What I mean is, if the person performing the accountability of Product Owner is not well versed or executes their responsibilities poorly then it leads to a lot of challenges and eventually can lead to failure of the Product.  Here are a few anti-patterns that I have experienced and observed with Product Owners. Hope, this will give you some ideas to identify and break the anti-patterns to make the Product Owners effective.

Every now and then some one talks about or highlights a practice which has nothing to do with Scrum. Yet, due to widespread usage of the practice, people think that the specific practice is part of Scrum and should be followed to do Scrum in the right way. Sometimes, the Scrum Masters for the lack of knowledge enforce such practices and then feel the resistance.  I am not saying that every Scrum Team should know each and every right or wrong practice. That’s not how empiricism works. When I started as a Scrum Master back in 2010, I had my set of practices and I evolved. I expect Scrum Masters and Scrum Teams to have that journey. What I am unable to comprehend is the same practices of 2010 becoming anti-patterns for Scrum Teams in 2025.

The core strength of Scrum is its ability to take advantage of self-managing teams who are capable of making faster decisions, taking ownership and creating value by helping the customers to respond to ever changing needs of their domain, market. The challenge however is, how many self-managing teams have we encountered in the software world. At least, in the places where I have worked in the past, the sighting was rare to none. It is like going on a birding trip to find a specific bird species only to know that the species has already migrated to some other place. It was here yesterday but now it is gone. The question this situation raises is, if self-management is so important for Scrum or Agility to thrive then why do we have so few self managing teams. And can by simply declaring a team, a self-managing team will make it so magically?

The only reason for a Product Owner to exist is to maximize the value of the Product. One of the ways a Product Owner can accomplish this is by ensuring that most valuable items remain at the top of the Product Backlog and the Product Goal underscores their importance. So, how does the Product Owner order the Product Backlog; what techniques can be used? Is MoSCoW a valuable approach? Let’s explore.

The only purpose of doing Scrum is to create a DONE Increment. To get to a DONE Increment, quality is key. In Scrum Teams Definition of Done enables transparency around quality and releasability of the Increment. However, more often than not the Definition of Done stops at meeting acceptance criteria and completing a few levels of testing. But is that enough to make the product increment releasable; of highest possible quality? Maybe or maybe not.

Scrum has been around for almost 30 years now yet there are so many misconceptions about what needs to be done and how it can be done effectively. Even today, as I coach and consult many teams I often see that the purpose of events is mostly lost. And people simply go through the motions, probably to get “checkbox” ticked. For me, Sprint Retrospective is an important event which often is completely misunderstood and is often not very effective. In fact, at times I have seen some teams completely skipping the Retrospective. In this article, I am exploring a common set of dysfunctions I have observed and how can those be countered. I hope you will find it useful.

What is the relationship between Scrum and Lean Thinking? Please explain how Scrum enables Lean Thinking or how Lean Thinking fosters Scrum? These are my two favorite questions when I typically want to gauge the knowledge of Scrum Masters. And over the many interviews in the past couple of years I have come across maybe 1 or 2 people who were able to answer it satisfactorily. I often ponder why that is. This article elaborates a bit more on it and I also share how I connect Scrum and Lean Thinking. So, if you want to explore it, this might be a good starting point. Disclaimer: Long post alert.

What we measure is what we get? If there is no focus on defining what we want to achieve and articulate how we can measure it then often we end measuring wrong stuff and that impacts our ability to create value, to be successful.

Often we are required to make predictions about the future, specially the cost and effort that would be required to complete a project/ set of features for a product. Now in a complex environment this is not easy as many variables are at play. But is there an approach or tool to guide us? The Cone of Uncertainty might help.

Is the role of Scrum Master really relevant when Scrum has become the norm while the Scrum Masters themselves have not really upskilled or reskilled to support the Scrum Teams.

Scrum Masters change styles and stances as needed. However, when someone who lacks knowledge or experience takes on this accountability, it often leads to Scrum Master anti-patterns. In this post I am sharing the anti-patterns and its pitfalls that I experienced, there could be more.

In this blog post from PST Piyush Rahate, he explores the reasons why Project Management can be a useful tool to the Product Owner and Scrum Master.

Product Owner is an accountability within Scrum. If you are not doing Scrum then there is no Product Owner. However, Scrum does not clarify besides a couple of bullet points what is expected of a Product Owner and it leaves a lot of grey area for people to interpret and mis-interpret the need of Product Owner.

One of the accountabilities that a Scrum Master has to fulfill is to make the Scrum Team effective. This includes the Scrum Master, as well. However, in my experience I have come across only a handful of Scrum Masters who understand the concept and who focus on improving and making themselves effective. If as a Scrum Master one does not focus on making themself effective they might not be able to help the team to become effective.

Story points could be a great tool when combined with planning poker for getting estimation related conversations started. However, there has been quite a backlash and debate on whether to use story points or not.

Every Sprint starts with a Sprint Planning event. It is very crucial to ensure that the Scrum Team comes to a shared understanding of what and how are they going to deliver a “Done” increment that creates maximum business impact.

The Daily Scrum is an important Inspect and Adapt event for a Scrum team. Yet the purpose is often ignored and swept under the carpet by a multitude of teams.

As many Professional Scrum Trainers have experienced, there is always a good discussion around the Sprint Goal. A similar discussion recently led me to address this not so well understood aspect.

There has been so much written about Velocity and its impact on teams yet it is one metric that eludes everyone and keeps cropping up whenever there is discussion around productivity.

A few days back I did a Scrum Tapas Video explaining a few of the rules within Scrum. Besides these rules, there are also certain guidelines which help Scrum Teams to make the best possible use of Scrum framework to create maximum Business Impact.

Photography may sound simple but is actually a problem of complex domain. There are many variables - light, subject, motion, distance, composition, framing -  that come into play while capturing an image.