Interestingly, so many organizations have revenue or profit as their Product Goals as well as Strategic Goals. Some organizations do not consider using Product Goals at all. Or they are not aware of this need.

How often have you thought: "This Sprint Review is useless and boring!" or "We are just reviewing internally what we already have seen before as a Scrum Team. We have no new feedback. Let's skip this event. Waste of time."

How often have you been exposed to the conflict or different objectives between departments? If never, congratulations! You have probably seen and experienced healthy environments, meaningful shared goals, and true leaders. Keep on!

Product Goals were added to the 2020 version of the Scrum Guide. The idea of incorporating this concept was to emphasize the importance of having a longer-term goal than a Sprint Goal.

Previously, I have described some challenges with the Evidence-Based Management implementation. There are plenty of challenges regarding the process of applying Evidence-Based Management, there are also great results.

We have now launched a new Scrum.org course – Professional Agile Leadership – Evidence-Based Management (EBM), and it is an exceptional occasion to share my experience with implementing the framework.

People in organizations are often afraid of running experiments. I have observed that approximately 70% of people responsible and accountable for products are reluctant to validate their assumptions by experimenting. There are several reasons for this hesitancy. The most common is misunderstanding what exactly the Agile experiment means. The second one is the negative result of the experiment. I always answer that this is fine that we have such a result! It means that there is no need to develop a solution that no one wants or does not fulfill users' expectations.

Recently, I have been discussing some reasons why Agile Transformation may fail or go slowly. In this blog, I am presenting some success factors that might help your organization move toward Agility.

In the previous article, Agile Transformation – Success Factors part 1, there was a strong focus on key levels that should be taken first into consideration. That was a high level overview.

Based on my experience working in agile environments since 2010, I did some research and had general observations on the topic. Regardless of the business domains or product area, there are some common rules that may devastate your efforts toward agility.

A significantly increasing number of companies strive for agility. They intend to progress with agile transformation.

Facing a large number of risks while delivering products seems to be normal. And, it is. It is common and natural. What we need to do, is manage the risk.

From my experience and observations, my concern is weak understanding that the Evidence-Based Management (EBM) framework is empirical. It requires transparency, frequent inspection, and adaptation.

Large numbers of Product Owners begin their work by creating requirements. In some situations, these scopes are dictated by others. Their work mainly consists of describing demands, thus apparently appearing as a scribe in their role.

In this blog, Professional Scrum Trainer Magdalena Firlit talks about some of the differences in words between English and the Slavic languages with helpful tips for translations when it comes to Professional Scrum certification assessments.

While working with plenty of Scrum Teams and teaching Professional Scrum Product Owner classes, I observed a similar anti-pattern regarding Product Owners, which resembles anti-patterns of Scrum Masters who are not empowered.

Through my professional experience, while serving my customers, working with Scrum Teams and training people in Professional Scrum, I have observed that some Scrum Masters only work to serve the Development Team and the Product Owner.

An Agile mindset is crucial in management roles for organizations that are moving towards Agility.