Everyday Kanban

Discussing Management, Teams, Agile, Lean, Kanban & more

The Castle vs. Shack Conundrum

I’ve begun to witness an all-too-common situation at work that I have dubbed “The Castle vs. Shack Conundrum.”

Problem

Customer A is adamant that we have to build a house in 4 weeks. When we begin to talk to our customer, we start to understand that the house that they envision is more like a castle. However, building a castle in 4 weeks is so unlikely that its barely worth discussing. When the team analyzes the situation, we are in agreement that, with focusing only on this project, we could build a house in 4 weeks. However, that house would be a very nice shack — most decidedly not a castle. The team begins to discuss this reality with the customer and we find that this news is deemed completely unacceptable.

At this point we enter a twilight zone all too common in all kinds of work. The underlying rule that all participants will realize before they exit this phenomenon is that REALITY ALWAYS WINS IN THE END. Do what you will. Rail against the world, make demands that you will get your way, whatever. If you are fighting against reality, you will lose. Plain and simple.

Solution

I believe that the solution to this problem breaks down into 2 parts. Of course, I’ll only touch upon them here. To go into them in great detail would mean a book, not a blog post. 🙂

Work smart

It is going to be much less difficult for a customer to put their trust in you if its apparent you are doing the best you can as quickly as you can. If you have an undefined or poorly understood workflow or process, you are not helping yourself get work done as best and as fast as possible and you’re not helping gain the trust of the customers.

Spend time mapping our your value stream (what it takes to get something done from start to finish). We’ll call that our Y-axis. But, you need to pay attention to the X-axis as well. Look at not only how things get through, but what type of things come in. Do you have different types of work? Do you treat them differently? If you’re not in manufacturing, the answer to both of those questions is probably yes. This means you need to start understanding what those unstated rules are and make those policies explicit to yourself and others.

There are many methods you can choose to facilitate the movement of work through your value stream, but I suggest that, especially in this situation, that you look at the Kanban Method. It has low overhead as far as rituals are concerned and you always work to ensure you are doing the most important thing possible. In addition, you are limiting what’s in progress at any given time to ensure that individual pieces are done more quickly. If you are doing that, and you are doing it with quality, once we add the next part of the solution, its much harder to argue with the reality.

Want to go deeper? Read “The Principles of Product Development Flow” by @dreinertsen and study Queueing theory.

Let’s move onto part 2 of the solution.

Be transparent

So much of what I do in my management role is making truth visible across everything that my team does (as well as striving for that to be done across all interfaces that they touch). I really fight against the inherent tendency of teams to be private. I have found that, by making our work intake and our work delivery processes public and visible, I now have at least 50% fewer customer complaints across the board.

Often people just need to understand why things are the way they are and we can accept them or begin to focus on potential solutions rather than only the problem.  When you are no longer fighting with your customer and you are working in tandem towards bringing desire and reality together, you’re no longer fighting a losing battle. When we don’t have visibility, which leads to understanding, we’ll keep fighting. This is the underlying premise of the well-known phrase “just walk a mile in his shoes.”

In summary

I’ve learned to focus on getting work started by coming to agreement on defining the most important things, specifically the underpinnings or foundation of the castle, and getting those in process as soon as possible using WIP limits. Even when you’re still building trust and there’s not complete consensus on what can be done, you are not wasting time. You don’t want to be in the situation of spending valuable time convincing people you can’t build the castle and ending up only being able to build half the shack you could have built if you had started earlier, throwing everything into reactive, emergency mode.

When you get closer to your delivery date and the customer sees that you are doing things quickly and well and you still can’t meet the date, as you have been saying all along, then you finally have data points for a conversation on realistic expectations.

 

1 Comment

  1. I was struck by a couple of things in this post…

    First, I believe that castle v. shack conversations (no matter what the work product) are a result from poor communications and expectation setting from the beginning. That has been my experience. The best sales people in the world broker that purgatory between what the customer wants and what the organization can deliver. Having a shared vision of mutually agreed upon outcomes helps plow that ground. Accordingly, I would gently suggest that the first question to ask is how did expectations get so misaligned and how would that be handled differently? The upfront part of the sales process is very critical and sets up how things will fare.

    Second, I read some years ago (probably about 20, and I regret I do not remember the source (though I suspect Peter Senge) that organizational processes should enable a company to withstand the most difficult customer and the most difficult employee. (It matters so long as the customer is a profitable one and the employee is a talented one).

    Senge’s work was inspirational to me as a young professional many years ago, and aided me immensely in my work.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

© 2024 Everyday Kanban

Theme by Anders NorenUp ↑