I have been involved in refactoring legacy code for so many organizations over the last 10 years. Also, I'm actively leading organization-wide transformation towards lean and agile. I've started seeing the similarities between the two "refactoring" efforts. And, here are some of the these interesting notes:
- Stages are the same: First, do some quick-wins in code, which is the first step in the my roadmap in refactoring old code, then restructure it towards modular design with disjoint parts, and finally work on optimizing the whole and the parts inside each module. In organizations, there are very similar. First, fix the urgent issues, second restructure the organization towards disjoint self organizing teams, and finally, work on optimizing the relationships between teams and members in side teams.
- You can't see problems until you start resolving them
- Problems build on each other. In code, you can have simple problem built upon another simple ones, and the chain starts complicating everything. In Organizations, a simple political issue leads to another simple issue, which may result in some dumb decisions and the chain continues.
- The earlier you tackle problems, the easier the solution is.
- Sometimes, you'll need to revamp part of your old code. This is exactly the same in case or organizations. Sometimes, it's even healthy to discontinue and redesign some departments, functions, groups, business lines, etc.
- "Forking" code and refactoring it for long time without merging back is very risky. In almost all cases I've gone though the two branches become very different and the new forked branch is abandoned. Similarly, "forking" a shadow organization does not work. It increases the friction in the organization and ends with killing this new parallel structure which is, from the viewpoint of the "old guard", eating up the organization one byte at a time!
These are some thoughts. There are still many others, what do you think?
