Are you working with Scrum or eXtreme Go Horse (XGH)?
Sometimes we feel that we are working with anything but Scrum.
Sometimes we feel that we are working with anything but Scrum.
I assume that if you have worked with Scrum, at some point in time, you wondered, “Is this Scrum?”. I have experienced numerous misunderstandings about Scrum, and so many anti-patterns, which held teams back from getting the benefits that Scrum can give. Unfortunately, many organizations get disappointed and give up from Scrum; but are they working with Scrum or eXtreme Go Horse?
The Agile Methodology eXtreme Go Horse is a satire of inadequate implemented agile frameworks; yet, I have seen such situations with many Scrum Teams. The cases I am referring to are:
Endless bugs and technical debt.
Blaming developers when things go wrong.
No clear prioritization.
No ownership.
Endless bugs and technical debts
I worked with multiple Scrum Teams, at some point in time, I felt like we were in a negative spiral; the more we worked, the more bugs and technical debt we created. Most probably, you have experienced something similar to that if you worked with Scrum. The root cause for this issue can vary a lot, for example, poor definitions of done, poor development process, high pressure, and so on.
If we look at the eXtreme Go Horse, it says that for every problem solved, seven more are created. I experienced exactly that with some Scrum Teams. Instead of maximizing the amount of work not done, with XGH, we always do more.
3. You’ll always need to do more and more XGH. For every solved problem using XGH 7 more are created. And all of them will be solved using XGH. Therefore XGH tends to the infinite.
— Daniel Alonso, eXtreme Go Horse Methodology (XGH)

How can we avoid that in Scrum? We don’t know everything up-front, that’s why it is vital to inspect and adapt. Inspection can happen at any moment, but there’s a specific moment that the Team stops, and the focus is on inspecting the Sprint and adapting to be better; this is the Retrospective. Every Sprint, the Scrum Team should become a better version of itself, meaning that we learn from our failures and improve ourselves.
The Scrum Master encourages the Scrum Team to improve, within the Scrum process framework, its development process and practices to make it more effective and enjoyable for the next Sprint. During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by improving work processes or adapting the definition of “Done”, if appropriate and not in conflict with product or organizational standards.
Blaming single developers

In Scrum Teams, the accountability never goes to a single person, which means the whole Team is always accountable. Unfortunately, I have lived in many scenarios where developers accuse one another once bugs appear.
If you hear sentences from the developers like “I didn’t develop that,” “I told it wouldn’t work,” “I have nothing to do with that,” then you are living this scenario.
Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.
Developers blaming each other is part of XGH as well. Although in Scrum Teams, that should never happen because accountability belongs to the Team, I have come across to such scenarios multiple times. How can we avoid this trap? Once the Development Team establishes and agrees over the Definition of Done, the developers tend to stop blaming each other.
8. Be ready to jump off when the boat starts sinking. Or blame someone else.
For people using XGH someday, the boat sinks. As time passes by, the system grows into a bigger monster. You better have your resume ready for when the thing comes down. Or have someone else to blame.
— Daniel Alonso, eXtreme Go Horse Methodology (XGH)
Definition of Done is essential for the Development Team, don’t underestimate that, help the Team to establish and agree on it. Once that happens, commitment and engagement will increase.
No clear prioritization
During my first experience as a Product Owner, everything was a priority. I remember that we couldn’t focus on anything, because every time we needed to change directions. We had a Project Manager Officer (PMO), so I asked him which is our priority, he answered: “We have 50 projects, we must finish all of them, they are all priorities”. So we found our way of defining the priority:
The person who shout the loudest, gets the request prioritized.
For sure, that was not sustainable. We needed to adapt and find a better way. Unfortunately, this scenario without a clear priority lasted months. After I read the eXtreme Go Horse, I was sure that we were following it instead of Scrum.
11. XGH is anarchic. There’s no need for a project manager. There’s no owner, and everyone does whatever they want when the problems and requirements appear.
— Daniel Alonso, eXtreme Go Horse Methodology (XGH)
In Scrum, the Product Owner is responsible for defining what a priority is and what is not. To make that possible, the organization needs to respect the Product Owners’ decision. Once companies start to use Scrum, the prioritization might require special attention because it involves multiple parts of the organization.
The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner.
For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one can force the Development Team to work from a different set of requirements.
No Ownership

I have been in scenarios where developers refused to fix problems because they didn’t work on it. That happened once when the developer who developed a specific part of the product was not present, then a problem appeared, and nobody wanted to work on it.
If you hear sentences like “I cannot work on it,” “We need to wait until he or she is back,” “I am afraid of touching this part of the code,” and so on. I am afraid that the developers lack ownership over the product, or you are working with eXtreme Go Horse instead of Scrum.
22. The problem is only yours when your name is on the code docs.
— Daniel Alonso, eXtreme Go Horse Methodology (XGH)
In Scrum, the teams should be transparent, which means that all artifacts are transparent. The Development Team owns the development process, which means whenever there’s a problem, they are accountable for it. The Development Team must be able to solve a problem regardless of which individual worked on it before.
The Scrum Master must work with the Product Owner, Development Team, and other involved parties to understand if the artifacts are completely transparent. There are practices for coping with incomplete transparency; the Scrum Master must help everyone apply the most appropriate practices in the absence of complete transparency. A Scrum Master can detect incomplete transparency by inspecting the artifacts, sensing patterns, listening closely to what is being said, and detecting differences between expected and real results.
The Scrum Master’s job is to work with the Scrum Team and the organization to increase the transparency of the artifacts. This work usually involves learning, convincing, and change. Transparency doesn’t occur overnight, but is a path.
Wrap-up
Scrum is a robust framework. However, many teams fail to implement it properly, before you give up, inspect and adapt. Be sure that you are not using eXtreme Go Horse instead of Scrum.
Scrum is empirical. The more we do, the more we learn. Inspect and adapt whenever it is possible. Do Retrospectives at the end of each Sprint.
There is no single person accountable within the developers; instead, the whole development team is accountable for the work done.
Be sure that the Product Owner has his or her decisions respected.
Don’t fall into the trap of multiple priorities; there’s only one priority.
Do you want to write for Serious Scrum or seriously discuss Scrum?