How to be Agile in a Day

I read a few articles lately that claim Agile is basically a magic bullet that will allow you to have greater productivity in a few weeks. Well a few weeks is too long... Here is my magic recipe to be Agile in a day. It just requires a little preparation:

Preparation:

• Hire a good mix of junior and senior programmers.
• Hire passionate, pragmatic programmers that care about their craft.
• Make sure your team is co-located.
• Have a definition for a work item that is 'done'. Were coding standards followed? Is the feature tested? Is it documented? Is it installed in a demo machine?
  
• Plan the release of the product with the main features and an approximation of how big the whole thing is going to be.
• Plan the work for two or three weeks at a time.
• Make the team take responsibility for the work to be done in the next iteration.
• Test everything you do thoroughly (unit tests, end to end tests, and anything you feel is required in between).
• Know the difference between a stub, a mock and a fake for tests. Know when to use each one.
• Have a continuous integration build.
• Name your classes with words the customer will understand as much as possible. Programmers and customers understand each other better if they speak the same language (DDD).
• Have a good knowledge of object oriented design.
  
• Fix your bugs as soon as you find them.
  
• Refactor early, refactor often.
• Pair program when you can.
• Organize code reviews.
  
• Have a customer on site (or at least readily available) so you can question him about the requested features.
• Demo your product at the end of each iteration to get customer feedback.
  
• Ship! Release your software to some users early and often to get even more feedback.
• Integrate the feedback into your next development cycle. If the customer changes his mind because what he saw is not what he expected, do not be afraid to recode entire features (but make sure the customer knows he will not get new features in the meantime).
• Hold a retrospective at the end of each iteration. Identify the biggest problem you currently have and take steps to solve it.
  
• Follow up the retrospective with concrete actions to obliterate your problems. Retrospective are useless if you talk about the problems but do not solve anything.
• Always strive for higher productivity. "We always did it like that" is seldom a good reason not to improve.
• Allow failures. Expect the team to fail from time to time. Never failing might mean the team is aiming too low.
  
• Do all of the above for a few sprints. The longer the better. If you can do all of the above for a year and still continue to ship valuable software for a customer while maintaining clean code, there is a good chance you can continue to do it for a long time.

That's it for the preparation. Now, here's how to be Agile in a day:

• Read a book about Agile methodologies. Realize you're already pretty good but you still have a lot of room to improve. Claim that you are now Agile.

There's no shortcuts, no magic bullet. Software development is hard. Agile software development even more so. Do not expect every programmer you meet to thrive in a dynamic environment where everyone must take responsibility for their work. Agility is not for everyone. I believe it is the most enjoyable way to build software, but I'm aware that a lot of work lies ahead.

So can you be Agile in a few weeks or less? Well if you are already doing almost everything in the list you probably can. If you do not understand why the list is important, you're far away... Claiming you can be Agile in a few weeks might be a nice commercial gimmick but that's about it...