Some things are hard to change. A policy that seems to haunt me is that you must stabilize (or harden) a release candidate for a certain period of time (for instance in the staging environment), before you can deploy it in production.
Last week I tweeted:
One reason for establishing this kind of policy might be that it’s related to a (predefined) release schedule. The system simply has to stay there until it’s time for the next release. The problem, from a lean perspective, is that most of the time stabilizing is waiting (or idle) time. You build inventory.
Ideally you should try to minimize the waiting time by deploying more frequently. If you don’t know where to start, you can read up on continuous delivery, but you can make thing better simply by moving the value adding activities earlier. This makes sense because you shorten the feedback loop.
In other words:
Are you facing a large and complex task? Sometimes it’s hard to even get started, right?
A natural response would be to start analyzing the task searching for the most efficient way to deal with it. But it’s easy to over engineer a solution, and for me this is never the most efficient approach. I simply don’t (yet) know enough about the task to do this kind of thinking up front.
This is why I prefer to start with the smaller tasks that I actually do know how to deal with – without giving the bigger picture much though. I move on, one (sub)task at the time. This seems to work magic. I now naturally know the next natural step, and can create more (sub)tasks. All of a sudden, the large and complex task seems manageable.
I know this sounds trivial, but it’s really about the mindset. Of course, you have to put some thought into it, but over analyzing a task before you start working on it is waste. Instead, start with what you do know, and make it a habit to split tasks early if it’s too big. It’s better to do this early than late.
Every now and then you will get stuck in a task, because you made wrong assumptions. When this happens it’s hard to take a step back and start over (the right way). This is a muscle you have to train, so make sure you reward yourself whenever you manage to do so.
With all the different management models out there, chances are you’ve come across a model that can help you solve or improve a particular problem. From a bird’s perspective, they might look simple, but to fully grasp how to apply them in your organization, you need a deeper understanding than you can get from only reading a book. You need hands-on experience.
This triggers a question: How do you apply a generic model you don’t even understand the complete extent of, to a specific situation of high complexity?
Normally, when you get a question like this, you know you won’t get an answer in just one sentence. But the answer can be rather simple, actually just a single word: Feedback.
It doesn’t matter what the model is for and what it is designed to solve, but once you decide to give it a try, remember this: Get the feedback you need, as fast as you can, so that you’re able to take corrective actions. The more complex the situation is, the faster you need feedback.
No feedback is synonymous with failure, and the model certainly won’t do you any good. You need hands-on experience and you need feedback, that’s how you truly understand how to apply the model.