Hell’s Kitchen — IT edition
Imagine you start a new job in the kitchen of a fancy restaurant. You just graduated from your culinary studies and you’re eager to learn all about working in the fine dining industry.
But, oh boy, it’s not like you imagined. Everybody in the kitchen is under constant pressure to deliver as many dishes as possible to customers. And while you and your team manage to keep up in the beginning of the evening, soon more and more orders keep on piling in, and you find yourself preparing food for 4 tables at the same time. Even worse, whenever you try to clean out the oven, sharpen your knife, or sort out old food in the pantry, the owner comes in shouting: “why are you not preparing dishes? It’s your job to deliver what the business wants. The business wants more dishes.”
Very rapidly, the kitchen becomes an unorganised and unhygienic mess. The chaos in the kitchen slows down the delivery of every next dish, which makes the owner even more nervous. So he applies more pressure to the team by mandating a certain number of dishes go out per hour. The team objects but has no choice. Of course, this results in half-finished, poorly produced dishes. And soon many of these dishes are returned to the kitchen and need to be solved “with the highest priority”. This results in a lot of context switches. Dishes that were already in the oven, need to be pulled out again to serve the prioritised dishes first. Which results in even more delays.
This goes on for several days and weeks until the kitchen team has had enough. Creating a single dish has become a 5 person — 2 hour effort. Adding 6 more junior aides in the kitchen has slowed them down even more. The kitchen has turned into a rat-infested hazardous environment, where no knife is sharp, no oven is clean, and no food is fresh. They demand to close down the restaurant for a week to literally kill bugs in the kitchen and clean the mess. The owner is as frustrated. Most clients have left. And those who do return, get poor quality food, slow service and a high bill.
There is no kitchen in the world which is run like this and can survive more than a couple of days. Yet, in IT, this type of kitchen is commonplace. Why is that? First and foremost because work in IT is, for the most part, not visible. No layman can walk into an IT kitchen and see the mess that has been created. It takes a seasoned professional weeks or months to understand an IT kitchen: its architecture, its technical debt, its automation, its code smells, its collaboration model, …
I can’t tell you how often I meet a team where the only type of work that matters, is building new features. Any other work is simply ignored. And building those new features is constantly interrupted by a “high priority, fix now request”. After a while, all progress grinds to a halt. Development would like to do a “refactoring sprint”. Never-mind it’s a contradictio in terminis. It’s often too little too late.
If you haven’t read The Phoenix Project yet, do that first. From that almighty book, we learn there are actually 4 types of work:
- Business projects: This is preparing and serving the dishes to the customers
- Internal work: Anything the kitchen needs to do, in order to support the preparation and serving of the dishes. Things like cleaning the oven, sharpening your knife and validating the freshness of the food.
- Changes: Anything that is prepared in the kitchen, needs to be served to customers. In IT, this should be automated as much as possible.
- Unplanned work: Dishes that are returned. Work that has to put other work on-hold.
If you only focus on business projects, you will soon find yourself doing a lot of unplanned work. So it’s simple, really. You need to plan for all 4 types of work, even for the unplanned work. It will never go away completely. So it’s better to add a buffer to your workload for that unplanned work.
What’s often lacking in organisations, is technical leadership. Not that there’s not enough technical expertise in the organisation. But at best, their concerns are given a lower priority than what the PO wants. At worst, their voices are simply ignored. One way to deal with that, is to assign the role of Tech Lead to somebody in the team, and give him the same “authority” as the PO. Now the PO and the Tech Lead will have to collaborate to get work done.
But it’s even better if the entire team, including the PO, understands that the fastest way to deliver business value, is by investing in all 4 types of work. Next to building features, everybody expects the team to continuously invest time in internal work, and continuously invest time in automating releases. Everybody understands unplanned work is evil and tries to reduce it. There are no opposite sides. Everybody in the team wants the same thing: fulfil your mission by shipping high-quality products that are meaningful to the customer as fast as possible. But not faster.
How do you do that? That’s also described in the Phoenix Project, and is described as “The Three Ways”. Maybe I can dive into that in another blog post, using another analogy.
