Monday, February 27, 2012

How to get things done aka agile change

In an IT organisation with 100 or more employees and a 10 year old million lines of code base, things tend to become slow. Some reasons for that are complexity, fear of breaking something, and lack of knowledge, especially about the legacy stuff. The older problems are, the more hesitation is felt.

After a couple of infrastructure improvement projects I participated in, there is the one most important lesson I learned. The one thing that helps most, is to stop hesitating and "just" start doing something.

  • Find the right people, 
  • understand the problems, 
  • pick the most important problem, 
  • collect solution ideas to reduce this problem a bit 
  • and decide on the idea to start with. 
An important criteria to select the first / next idea to work on should be the time required to evaluate the idea. You should get feedback after one or two days of working on it (aka time boxing).  This makes simple solution ideas more likely to be choosen, which is good. Suprisingly often the first idea I can come up with, is much more complex than the idea finally followed after discussing the ideas with a small team. The implementation of the idea is not necessarily finished after one or two days. But if you do not see sufficient progress, you should rethink problem and solution with what was learned during these days. Often new ideas are borne in this time. Just do not ride that horse until it is dead.

As an example we were looking for a solution to get our database deployment in our dev environment faster. Someone came up with the idea to use an empty database instead of an anonymized production dump. This ideas was around for at least five years, but nobody really tried and and many problems were expected to happen. Having decided to try that idea, we managed to have a minimal dump available and our application starting and running with it within less than a day. So we knew it would work. We still spend two weeks to automate the creation of this dump and to build some quality assurance around the automation of minimal dump creation and database deployment, but we knew that it would work and save us around 10 minutes of deployment time.

No comments:

Post a Comment