Are you working with Scrum or eXtreme Go Horse (XGH)?

Sometimes we feel that we are working with anything but Scrum.

David Pereira
May 6 · 7 min read
Image for post
Image for post
Photo by REVOLT on Unsplash

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.

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)

Take a moment to inspect and adapt
Take a moment to inspect and adapt
Photo by You X Ventures on Unsplash

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.

The Scrum Guide

Blaming single developers

Don't blame the other team members, the accountability belongs to the whole team
Don't blame the other team members, the accountability belongs to the whole team
Photo by Zdeněk Macháček on Unsplash

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.

The Scrum Guide

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.

The Scrum Guide

No Ownership

The problem belongs to the team
The problem belongs to the team
Photo by NESA by Makers on Unsplash

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.

The Scrum Guide

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.
Image for post
Image for post

Do you want to write for Serious Scrum or seriously discuss Scrum?

Serious Scrum

Content by and for Scrum Practitioners.

Sign up for Serious Scrum Newsletter

By Serious Scrum

In this periodical newsletter we will inform you about the most recent developments and accomplishments of Serious Scrum. THE reference in the field of Scrum and related practices on Medium. Take a look

By signing up, you will create a Medium account if you don’t already have one. Review our Privacy Policy for more information about our privacy practices.

Check your inbox
Medium sent you an email at to complete your subscription.

Thanks to Maarten Dalmijn

David Pereira

Written by

Head of Product Management @virtualidentity. Agile enthusiast. Free e-Book: What not to do as a Product Owner https://bit.ly/35tx7W4

Serious Scrum

Content by and for Scrum Practitioners.

David Pereira

Written by

Head of Product Management @virtualidentity. Agile enthusiast. Free e-Book: What not to do as a Product Owner https://bit.ly/35tx7W4

Serious Scrum

Content by and for Scrum Practitioners.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface.

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox.

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic.

Get the Medium app