No other role in Scrum can contribute to mediocre outcomes like the Product Owner—garbage in, garbage out. Therefore, the following list of some of the most common Product Owner anti-patterns might be a starting point to reflect on the role; maybe, there is room for improvement?
If you recognize some anti-patterns in your daily work, why don’t you ask the rest of the Scrum Team for support? For example, run a Retrospective with teammates and stakeholders on how the team is doing regarding figuring out what is worth building.
We are programmed at an early age to think that mistakes are bad. Make a mistake and you won’t get good grades. Choose the right career because there’s no going back. Make up your mind, there won’t be a second chance. You will regret this decision later. What were you really thinking? All this well-meaning advice rings loud and clear in our heads, conveying a simple message—stay away from mistakes.
Living in a mistake-phobic culture that links mistakes with stupidity and incompetence, it isn’t easy to admit a mistake. While most of the decisions we make aren’t about life and death and the consequences are rather trivial, we find it extremely hard to say, “I made a mistake.” We avoid taking responsibility for our actions and use blame, lies, and other fanciful stories to avoid looking like an idiot.
There are plenty of failure possibilities with Scrum. Given that Scrum is a framework with a reasonable yet short “manual,” this effect should not surprise anyone. Scrum thrives when the Scrum teams are self-managing while Scrum Masters embrace their role as servant-leaders. However, this also implies that Scrum Masters fail when they are overly protective.
Join me and explore the consequences of the overly protective Scrum Master and what you can do about it in less than three minutes.
There are plenty of Scrum stakeholder failures. Given that Scrum is a framework with a precise and concise yet short “manual,” this effect should not surprise anyone. While the Scrum Guide makes numerous references to stakeholders in Scrum, stakeholders themselves are no official role (accountability), no matter their crucial contribution to a Scrum team’s overall success.
Explore with me three widespread examples of how stakeholders fail their Scrum teams in three short video clips, totaling 6 minutes and 5 seconds.
There are plenty of failure possibilities with Scrum. Given that Scrum is a framework with a reasonable yet short “manual,” this effect should not surprise anyone. To make things worse, a crucial success factor of every Scrum team is not even mentioned in the Scrum Guide: Any organization that wants to employ Scrum to learn faster than its competitors needs to have a solid failure culture.
Join me and explore the consequences of not living a failure culture in less than three minutes.
There are plenty of Product Owner failures. Given that Scrum is a framework with a precise and concise yet short “manual,” this effect should not surprise anyone.
Explore with me three widespread examples of how Product Owners fail their team in three short video clips, totaling 6 minutes and 9 seconds.
There are plenty of Scrum Masters failures. Given that Scrum is a framework with a precise and concise yet short “manual,” this effect should not surprise anyone.
Learn more about three widespread examples of how Scrum Masters fail their team in three short video clips, totaling 5 minutes and 31 seconds.
This is Mike Cottmeyer's talk from AgileIndy 2021 on The Executive's Guide to Why Agile Transformation Fails.
Transcript
[Announcer] This is Mike Cottmeyer’s talk from AgileIndy, 2021 on “Why Agile Transformation Fails.”
– Okay, so we’re gonna talk about today is this thing I call “Executives Guide to Why Agile Transformations Fail.” And if you’ve been following my stuff, there’s really kind of a fascinating evolution of this story. So I got involved with agile back in like 2003 and I was working in this company called CheckFree. We were doing like large online banking bill payment kinds of things. And so my indoctrination to agile was never ever in the small. It was always large-scale agile stuff. And I was working for this VP that was like really super cool, is very into agile and we were coming up with really creative things for like team formation strategies and agile governance, all stuff. And this was like way before the days Dean Leffingwell hadn’t even written his first book on scaling. None of the stuff on scaling was out there. So we’re inventing scaling models and really trying to bring this. It was like these four or 500 people, this organization through an Agile Transformation. And so I started writing about multi-tier models and different teaming strategies and things like that and then I went to go work for version one for a couple of years. You guys remember them? It feels like I talk about them and I don’t even think they exist as a thing anymore. Version one CollabNet or something, I guess I call them now. So anyway, kind of a different company, but worked there probably about 10, 12 years ago and was going into a bunch of different organizations that were trying to adopt agile. And then the process developed a point of view around kind of why companies were jacking it up. And so I did talk on the three things and then we came up with this talk. It was just why agile fails. And the hypothesis behind that rev of why agile fails was largely about people trying to adopt practices of agile, and whether it’d be Scrum or extreme programming or now SAFe or LeSS or disciplined agile delivery, something like that, trying to adopt the practices of agile without the words I would use now, but I wouldn’t use them, the business architecture necessary for those practices to work.
Living in a country where the idea of "free speech" is a First Amendment Right allows opinions and views to be expressed on a wide array of topics. Sometimes these become hot issues that individuals are willing to become engaged in...at times a bit more extreme than one might expect.
One of those topics is the debate on vaccinations. While I am not going to provide the details on each side of the opinion, there was one quote that I heard a doctor state when talking to a patient about not wanting to administer a vaccination. The doctor basically asked, "Why would they make something that hurts you?"
If we were talking about inventing something, we would have told you to keep on trying and don’t give up. Running a business during the start is a fragile phase. An entrepreneur can’t simply afford to fail too much and lose the investment, just for the sake of trying again and again.
Do you ever feel like you are failing or wasting time? There are primarily two situations in this realm that I think need an alternative point of view; a more extended investigation that has led to nothing and getting rid of past work.
One of YLD's most spoken phrases is, "Begin again, never surrender." You cannot underestimate the power of not giving up and seeing your failure as an opportunity to give it another go.
That, together with the ability to freely make mistakes and retain a positive perspective is, according to Cal Henderson, Silicon Valley's secret "big advantage."
Failure has seldom been sexier, with advocates believing that if you're not failing regularly, you're not pushing the boundaries far enough. Such cheerleaders often evoke the spirit of Edison, who famously remarked that his thousands of failed experiments were a necessary precursor to the invention of the lightbulb.
Edison's notorious example merely serves to illustrate the importance of learning from each dead end so that you can be more successful next time. To take such constructive feedback from failure, it's vital that we understand the essence of what our failures represent.
Predicting failures of software in a production environment is very critical, apart from ensuring the quality during the development stage. The failures can happen in many ways, predicting them upfront and ensuring there are solutions for all such failures is a smart way. It will position you ahead in the race.
The preparation for failure should start from the initial stage of software design and carry on to the development and testing cycles. We must keep questioning our decisions in all these stages about the probability of failures and associated solutions.
In the digital world, application performance degradation and downtime are not rare occurrences. The impact such incidents have on end-user experience varies. The application may become slow and frustrating to use, or it could crash and impede user transactions. The severity of the issue and the MTTR (Mean Time to Resolve) directly affect end-user experience.
When the titans of information technology encounter performance challenges, the repercussions impact almost every single online application. Such outages are widely reported followed by a slew of write-ups analyzing the issue — what caused it, what fixed it, and what could prevent it. Performance analysts are on the lookout for such big outages, but we often overlook blips in performance. Blips or “micro-outages” are mostly intermittent performance issues that often go unnoticed.
