en-uspt-br
Written in 2023-09-13 Modified at 2023-09-13

GoHorse GFX

Disclaimer

This specific article is about my personal experience. I have no intentions to point fingers nor call names, it is not my desire to insult anyone. You are welcome to disagree but please be respectful. The sources I have linked throughout the article were used in my research but as is customary: When in doubt, always check the sources. Thanks and on with the show!

Index

> Quick Recap on Agile and Waterfall

In order to understand the Eldritch Terror which is the GoHorse GFX approach, we must first understand what good approaches are.

And yes, I just mentioned that Waterfall can indeed be a good thing, deal with it. 😎

The Waterfall

If you want to get deep into the water, I have already written extensively about Waterfall before.

Waterfall is a project management technique in which each step depends directly from the one before, with no chance of iteration.

While inflexible, it can be a very powerful tool for problems with known solutions such as civil construction.

The Agile Framework

For a quick feedback you may check my article explaining the Agile Framework first.

The Agile Framework is about taking care of the team and dealing with changes as they come: Giving and receiving honest and clear Feedback is a must in order to grow and mature.

> Breeding Horses

If you like sarcasm and want to taint your mind with the content, check the GoHorse axioms at your own peril.

GoHorse is NOT a real methodology. It is the result of fundamental lack of understanding about the project, requirements and effort. It may be however, the single most used “format” of working in projects out there.

Simply put, GoHorse is the amalgamation of bad practices performed by anyone involved in the project that doesn’t care enough about its success.

Project management is not really a science but it is a very complex area: You have to manage people, expectations and results in a way that is satisfactory for your clients and stakeholders while maintaining the structure of the team.

It is not simply a “throw money to solve” kind of problem. It requires dedication, attention and work ethics.

Do you realize now why GoHorse is so prevalent in today’s world?

> The Anatomy of GoHorse GFX

GoHorse GFX tries its best to pretend to be Agile and normally it chooses SCRUM as the template for its nefarious deeds.

SCRUM is actually a GREAT agile implementation and you should really consider it for your team if you’re thinking about being agile. As it is customary, GoHorse leans on this reputation in order to take a foothold and ends up tarnishing SCRUM as a methodology.

The descent to madness happens in different ways, sometimes many ways at once:

>> Team Hierarchy

Some companies will have the technical teams be subordinates of the business teams. This means that the technical team is not capable of having their own priorities, having to serve the business teams as their lords. This makes the job of the technical teams very hard because they may have changes in priorities which they not be ready for.

Looking at the Agile principles of setting your priorities and togetherness is becomes clear that such an approach of having two different backlogs will not respect neither the agile framework nor SCRUM.

Since the business teams control the budget for the projects under the technical teams, they ultimately have the power to change whatever roadmap the technical team has, effectively undermining their efforts to make themselves agile.

>> The Clock Keeps Ticking

Most things in life are cyclical: Seasons, Night and Day, Water lifecycle, etc. This characteristic also shows up in businesses: yearly reviews, quarterly projections, yearly budget and so on.

This flow of checkpoints, let’s put it this way, creates an expectation of work to be delivered at those milestones as well.

Once you work in very predictable or even repetitive projects, it is easy to have plausible expectations on the execution time of your project:

However, when you tackle new or unexpected projects, such as a research or a software solution, you can’t accurately estimate the time to completion because you don’t have enough information for it.

This is why the agile framework asks for the feedback loop in many different ways (1, 2, 3) in order to make sure the team understand how much effort it takes to deliver something.

It then becomes clear that any project created with the sole purpose of adhering to a schedule will face a lot of difficulties and it is more likely to fail that succeed.

>> The Merchant

What happens when you sell a feature you don't have or buys something you have no idea how to use?

Obviously it becomes a project which needs to be tackled as soon as possible because money in on the line.

To Sell The Void

Imagine if you will a scenario where a sales person is trying their best in order to secure a client. In order to close the deal, the sales person sells a feature the product does not support but was key in the negotiation.

The problem now is clear: the client expects the feature to be available when they start to use the product and yet such feature does not exist.

The company's executives will not allow a sale to do under because not only does it mean more money is coming in but also because cancelling the sale could have negative consequences to the company's reputation.

What’s the solution to this conundrum? Well, no matter how hard, difficult and exhausting it will be: the team will have to implement this feature before the client starts using the product.

That goes against most of the Agile Principles right off the bat and is pretty much as GoHorse as you can make something.

If You Bought It, You Got To Use It

Let’s try another scenario for now: let’s picture an advertisement in which a product is said to solve all the problems you “believe” you have. The product does tick all the boxes you think you need and it also looks great so let’s purchase it!

Now that it was bought, how does this product integrate with the rest of your solutions? Does the team have to build some kind of integration? Is it compatible with whatever we already have?

The thing is: it is already bought so it must be used NOW: it doesn’t matter how hard the integration is going to be, it must happen yesterday because “this is a very strategical solution to us” (bet you heard that before).

As in other scenarios, this forces the team to move into GoHorse territory, with no chance of sanity.

>> Overcrowding The Team

Agile teams have to become self sufficient in order to have high performance as well as making sure everyone is connected.

Those principles are easy to lose track of, especially if your team get too big. What does it really mean, to have a team too big? You know you have passed critical mass when managers do not have enough time in their calendars to have a 15-minute conversation with their personnel at least once a month.

Those conversations are extremely important because they are the only way for managers to get some feedback but it is not how GoHorse likes to operate.

In a GoHorse environment, the work of the manager is to put out fires. The only time your manager will talk to you is when something is not right and will probably only criticize your work with no real feedback loop.

If you try to schedule a real feedback talk, you will have to fight hordes of meetings, most of them taking literal hours to complete and many of them are back to back.

>> Graphics Are More Important Than The Gameplay

Another sign you’re into a GoHorse situation is when the managers are not only disconnected from the team's reality but also when they start to care more about graphics and metrics than actual work, feedback and people's motivation.

This situation is very close related to overcrowded teams as managing large teams take a lot of work. The “solutions” proposed are to automate managerial tasks with tools such as feedback forms, mood heatmaps and other automated tools that may generate graphical reports for mass review.

Because of the graphical reports the interest of managers changes from taking care of the team and their well-being to making sure the percentages are looking good. Working with a team is not statistical analysis, you should really be worried about any deviation: if a person is complaining, be sure more people are uncomfortable as well, just didn’t speak up.

This “style” of management takes the responsibility from the managers and divides it into all the people in the team: it is now their fault they didn't report a problem using the tools, not the manager’s for not doing their job.

Also, the team may be under heavy scrutiny from managers if they deviate from the standard metrics, regardless if it is a good deviation or not: this “style” of management does not allow changes to be made.

Allocate That Budget!

Most projects are born out of need and not exactly a necessity, even though they are marketed as such:

Of course, there are many situations in which a project is needed:

There are many other scenarios which a project is a valid solution, this list is not even close to being exhaustive.

Since some projects are more of a desire than a necessity, they end up poorly planned. At least in my experience as a software engineer this is so very common it is kind of an industry joke at this point.

Regularly big companies have budget adjustments which are often close to the end of their fiscal year. Sectors do their best to use all the money they have available before the reviews in order to justify their need for more money for the next year. it’s in situations like this a bunch of filler projects are created, only to allocate surplus budget.

As you may have guessed, this is a prime scenario for useless projects to be born. Their sole purpose is to have budget allocated, not to succeed. Of course, a project which is not meant to succeed can only fail but it mustn’t or the budget gets deallocated and may not be available after the review.

What ends up happening is something close to the sunk cost fallacy: you avoid stopping the investment because you are already so deep into it but in order to justify past expenses, you keep spending more.

Same Old Song and Dance

Not only budget constraints cause GoHorse projects to exist. Sometimes inertia may play against the projects as well.

There are many businesses which are multiple decades old and are still going strong. Sure, they may have gotten a rebranding here, maybe broken up in smaller entities there but in essence, they still have that old spirit in them.

This is to say, they have a lot of baggage: companies like this have done all kinds of deals, survived (or at least partially) many different regulations and so many more political changes.

Such businesses may have strict rules on how to engage projects, ventures, deals and competitors. Of course, such rules would apply themselves to all areas of the company, with no regard as to how each area operates because it is all for the good of the company, after all.

As you may have guessed by the hints I left, those strict rules may prevent companies from reaching new markets, improving their offers or just simply keep with the times and, when applied to projects may interfere negatively in the outcome.

The Advent of the Buzzwords

Buzzwords have the habit of using an important word or term and diluting their meaning.

Agile is one of the victims, as the buzzword version of agile tries to convince the reader it is fast, modern, is always better and will generate profit by itself (which may actually happen but only if you adhere to the principles). Of course, the buzzword doesn’t care about the principles as it is just a conversation tool, to embellish the contents of the speech.

At the same time, buzzwords caused a real problem to old-fashioned business: People started using those words and some of those people even knew what they really meant. Coupled with the fact that some business were pretty successful using some of the buzzwords the right way, the trend was set: We must now make ourselves agile.

To better illustrate my point, here’s a list of some buzzwords you probably seen before:

In the right context, most of those words are actually useful and have a significant meaning but when used as a buzzwords they are worthless.

None of the C-suite executives really understood what Agile means but the dear reader might: a very meticulous revision of the company culture, from top to bottom, left to right. It is simply not possible to work with an agile team stuck in a non-agile environment for a long period so either the company embraces agile or it pretends.

When You Pretend So Much You Start Believing It

The transition to agile is not an easy path. You have to meticulously analyze your processes and directives in order to ensure they embrace change and feedback.

Most businesses work close to the Waterfall approach: things get done by one department and are forwarded to the next. However, no single person knows how the company operates and how its processes are integrated, nor are those processes really documented nor updated. Finding those artifacts and checking if they really are up to date is a daunting task that most businesses ignore until it is too late.

If you have ever worked in any office, you are aware of the existence of the One Person. That is, the person which knows how everything is done and without this single person the company would go under or something similar.

When agile is to be implemented in places like this, the strong contrast between approaches causes a lot of clashes with the culture of the company. Since the agile framework allows one to construct their own “flavor” of agile, companies such as those end up creating a methodology which draws inspiration from both their old ways as well as agile but without the respect for the principles.

The result is the abomination I like to call the GoHorse GFX, which is not agile but people pretend it is.

> There Are No Victors In This Race

I must apologize if you got this far into this article. You were probably triggered by some of the contents but I feel that people need to recognize GoHorse and get rid of it as soon as possible.

I have named this article GoHorse GFX because of the graphical style I have seen going around, I myself got caught in some projects using this.

But hey, there really is a light at the end of the tunnel: make sure you also know the agile framework and even the waterfall method too, why not?

Make sure you understand them and fight for them: only you can stop GoHorse from being a regular occurrence in your life.

Thank you!

agileanalysisbudgetbuzzworderrorfailuregohorsegraphichierarchymanagementplanningprinciplesprojectteamwaterfall