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...

Book Review: Six Thinking Hats

Thinking is a skill. Like any other skill it can be improved.

Six Thinking Hats aims at making your thinking process more effective by removing something that I rather enjoy but which makes any decision longer to come: arguments.

People do not use arguments because it is the preferred way. They simply do not know any other way.
- Edward de Bono, Six Thinking Hats

I admit, I'm guilty... I've been in a few useless debates before. I'll try to change now that I know another way...

Instead of arguing back and forth over an idea, it might be worth it for everyone in the meeting to gather information over a single axis at a time.

So when you explore an idea, you might want to wear a different hat to be sure to explore all sides. This can be done in group meetings or if you are alone thinking about a problem. Colors are used because they offer a neutral language which is easy to remember:

• Blue: overall view, control of the thinking process
• White: cold facts and information
• Yellow: hopes, positive outcomes, advantages
• Black: caution, warning, disadvantages
• Red: emotions, feelings, hunches
• Green: creativity, new ideas

The premise is that it is difficult to view all sides at once. In a meetings it gets worse because someone might be focused on finding what is good about an idea while someone else is focused on the drawbacks. Disagreement follows and it becomes a willpower contest.

A brief example

You do not have to use every hat for each decision. You might for example start with a blue hat to define the problem and the desired outcome. The you might gather as much information as you can about the problem (white hat). Then talk about the advantages of a particular solution (yellow hat). If the advantages are not what you expect, then just drop the idea and explore something else. No need to argue over a bad idea...

On the other hand if the idea looks good, then request everyone to put on their black hat and explore the hurdles that might encountered during the implementation.

Power of the team

So I invite you to think about the principles behind the book and try to find alternatives to arguments to solve problems. I know it can be fun, but arguments just are not that effective...

By focusing on each side separately, everyone is sure to have a global view and the decision is probably going to be easier to reach. Everyone is focused in a single direction at a time. Everyone is working together instead of against each others. If you're a software development team, it might be time to act like one...