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

A Simple Introduction to BDD Part 1

A Simple Introduction to BDD Part 1

Today marks the premiere of my screencast, which is essentially my initial foray into video blogging and sharing insights in this format.

Read More

Simple, Complicated, Complex and Chaotic Systems, in Other Words Cynefin. And How Does It Relate to Software Development?

Intro

You might have already come across terms such as complex systems, complicated systems, or complex adaptive systems; especially, if you have read Management 3.0 by Jurgen Appelo or heard about Ken Schwaber’s ideas about the applicability of Scrum. It might sound intriguing, but finding logic in it is difficult without some background theory. This is the point at which Dave Snowden’s Cynefin concept comes in handy. This concept is based on complex systems theory, anthropology, evolutionary psychology, and, last but not least, cognitive psychology.

Read More

Architectural Mantra

Those who attended JDD 2013 could see it live. For those who weren’t there or missed it, below you will find a presentation on the Architectural Mantra along with an extensive article. Set aside some time for this.

Read More