Organizational Refactoring

It struck me the other day that organizations have some similarities with code. Agile promotes designing as you go. Think ahead just as much as you need to. And implement for the now. When things change, "refactor" the design. I.e., morph it so that it looks like it would if you were to do a design for the current functionality of the system.

If you don't refactor, you end up with "technical debt". This is a gradual slowdown of productivity due to greater and greater difficulty in maintaining the code. If you don't refactor, you're hacking in the changes. It might be the quickest way to do it for now, but it will cost you more in the long term.

Now apply this approach to organizational design and processes. This means that you constantly need to adapt your organizational design and processes to map to the current reality. If you don't, then you're making things more difficult / affecting long term productivity.

An example would be finding an issue and making a tweak to the process to prevent that issue from happening in the future. Now imagine doing this again and again. Gradually you end up with a complicated process where no one understands why it is that you're doing things. You need to take a step back and design with the current situation in mind. Again, an analogy with system design is appropriate: what is the simplest design that works? That's what you should go with...