Two steps to become agile

A lot of companies today wants to become “agile”. The $100.000.000 question is: How do you become agile?



Where is software quality going?

Yesterday I was visiting Scania when their R&D department had a family-day where they demonstrated what they are working with. Scania, for those of you who don’t know, is famous for making high quality trucks and buses. What struck me when we went from room to room and hall to hall was that wherever we went, there was an automated testing rig!


Agile is relative and dynamic

Some people say things like “I wonder what will be the next hype after Agile?”.

I my opinion this illustrates a misconception about agile, that agile is static and absolute. This is simply not the case.


Restarts as a strategic tool for better software

During the years when I started to learn agile development, especially TDD and good OO, I had the fortune to work as a consultant for a company that ran a massive number of small projects, each lasting for approximately 3 months. This was exactly the amount of time I needed to learn something new, apply it, and discover the limitations of it.

At the end of each project I realized there was a much better way of doing things, and the effort to rewrite the code probably would have eaten me alive. But hey, no problem, I’ll be on a new project next week, with a fresh code base to apply my new findings at.

At that time the recurring project restarts actually was a good strategy to improve the average code quality! If I would have had to keep on working with the same code base I would never have been able to incorporate that much new technology and knowledge in the code base, and I would never have learned that much about what makes code good.

Later on I also learned refactoring, but I doubt I would appreciate it as much if I hadn’t learned about good code first. I think this is one of the great limitations of refactorings, it requires a lot of experience to know in what direction to go.

By allowing people and projects to restart you can make people raise their sight to take a new direction, to get a new vision of what it will be like there, to learn and incorporate their experiences in the new. Granted, most agile processes have retrospectives, but sometimes they are not enough a kick-in-the-butt to start off something new.

If it is hard to introduce refactoring in order to improve the code base, or when retrospectives don’t seem to do it either; try a fresh start iteration where you can dream a little! If you realize it’s not leading anywhere, just keep on working with the old code base. In the long run you will probably gain more from the new perspectives than the lost iteration cost.