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.
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.
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.
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.