You Shouldn't Run with a Broken Leg!

Table of Contents

You Shouldn’t Run with a Broken Leg!

Clear? Obvious? It seems so, yet we continuously run with broken legs…

One of the most common answers people seek (during training or consulting projects) is to the question: “How do I deal with certain problems in my situation?” (in my project, with my client, manager, analyst, whatever…). It’s a natural question, but a much more important question is: “Is the situation I’m in healthy?” Most often, it’s not!

In such a scenario, the original question can be compared to asking: “How can I run quickly and efficiently with a broken leg?” I’d love to hear the answers…

Examples:

  • We don’t have good contact with the person who defines the requirements (because there is an intermediary company between us and the client, and we receive second-hand information, often with no direct contact possible with such a person/people).

  • Business/project managers do not consider technical needs when setting priorities (business priorities are important, but technical needs cannot be ignored as they cause excessive implementation costs).

  • There is no one clearly responsible for the requirements, who defines them and is accountable for changes (bears the cost responsibility). Typically, this responsibility is blurred, and requirements come from uncoordinated sources.

  • Lack of active participation and support from business people during implementation work (difficulty obtaining detailed information explaining how it should work exactly).

  • No refactoring because it’s expensive (no one will pay for it), because it seems pointless (how can anyone clean up all this mess?).

  • And many others… probably each of these topics could be devoted to a separate article.

So How to Apply Something Reasonable?

How to apply, for example, Scrum in such situations? (because in such cases, I often hear this type of question). Recall the fundamental question: “How to run with a broken leg?”

Before you start adapting to the existing situation, try to eliminate its pathologies! Usually, we don’t do this because:

  • It is difficult,
  • It often requires confronting the current reality,
  • It may initially lead to conflicts and resistance,
  • It requires substantial communication skills (including negotiation),
  • It often will have to lead to the disruption of the existing status quo - and this is something almost everyone fears,
  • It simply requires courage!

So, usually, we learn to run with a broken leg. Yeah… I like it. Locally, everything can be organized (somehow you can live with it), but globally it’s pointless. Yet, this is typically how it functions… Interesting, isn’t it? It’s like being in a trance…

Critically Verify the Current Situation!

Before you start adapting to the current situation, critically verify it! There is a wisdom: “Automating an incorrect process (i.e., potentially speeding it up) usually increases its inefficiency”. If the situation you are in is unhealthy, can you find the best practices in that situation…? What would be the best practices for running with a broken leg? :)

What to Do Then?

The answer is long and often depends on the subtle nuances of a given context. I won’t attempt to formulate it here. This post aims to provoke thought! There’s a good chance that when you start analyzing the situation (by yourself/with colleagues) - you’ll find answers. Provided that you are not looking for a magic wand that will silently, non-invasively, and effortlessly solve everything. One more reminder - trying to start changes in this direction requires COURAGE and certainly stepping out of your COMFORT ZONE.

A Small Hint

If we assume such a chain approximately (let me skip the justification for this grouping to avoid lengthening the post, maybe there will be an opportunity sometime…):

developer/tester/designer… => analyst/manager => manager/client/client-side manager

The last elements of the chain have the greatest influence, but it’s also the hardest for them to see the pathologies, or very often they are the source of them (as decision-makers). This group will find it easiest to make necessary changes. The hardest part is for people at the beginning of this chain (since they have the least decision-making power, initiated changes often require the most courage!). For them, one of the more effective (though often tedious and long-lasting) techniques is the broken record technique :) (i.e., continuously pointing out pathologies, showing their consequences, and annoyingly reminding about them… tirelessly, without interruption). If you are able to build a coalition in our chain, the greater the chance of making changes.

There is one option - you can seek external help. Analysis, recommendations from an external, independent, objective person/company can catalyze the process of change.

Remember! Setting a broken leg might be painful!

(Text translated and moved from original old blog automatically by AI. May contain inaccuracies.)

Related Posts

Make Room for Progress...

From the collection Poetry for Project Enthusiasts

Make Room for Progress

There is never a good time for the first child,
There is never a good time for the second child,
There is never a good time to build a house,
There is never a good time for renovations,
There is never a good time for a wedding,
There is never a good time to introduce refactoring,
And there is never a good time to start writing unit tests.
In each of these cases, you simply need to make a decision,
Start doing it, and time and resources will appear,
Because they will have to…

Read More

Two Structuring Meetings Patterns

As I describe in my book, it is beneficial to structure meetings (or parts of meetings) to make them more effective. Here are two examples useful for planning meetings, applicable in Scrum and adaptable to other contexts.

Read More

The Natural Order of Refactoring Under the Microscope Part 3: Extract Method

Analyzing Class and Method Responsibilities

In the next step, we examine the responsibilities of individual classes and methods, checking if they align with the intended responsibility of the class. It is best to analyze all methods and group them based on performing similar operations. We look for a place for these in other classes or a new class. Remember: if there is a significant private method in a class (longer than 3-4 lines), it should be moved to another class.

Read More