This is part 2 in a series on Software Gardening. If you’re just jumping in, you can find Part 1 here.

Perhaps the most important thing you need for your garden to thrive is good soil. Go to Home Depot every spring and you’ll find huge bags of soil for your garden. So, if we’re going to grow software, what kind of soil should we use? If you read Part 1 of this series, you’ll know that one of the drawbacks of comparing software development to construction is that construction uses waterfall project management. So, the answer to our question, of course, is to use the best soil we can. For software, our soil is Agile methodologies.soil

Agile methodologies have been around for a long time, but it was in 2001 that the leading experts pushing these development processes got together to sign the Agile Manifesto. Those leaders agreed on four principles that summed up their different processes:

  • Individuals and interactions over processes and tools: People are the most important part of developing software. It isn’t process or tools. Think about it this way. How many times has a process or tool caused pain on your project? How many times has people issues caused a problem? Keep people first and foremost in mind. Most Agile processes have some sort of period meeting, generally daily, to ascertain where you are on your tasks. It’s a way to keep the people working together and completing the next point.
  • Working software over comprehensive documentation: Aren’t we paid to deliver working software? A stack of documentation does nothing to help the customer, but do not misunderstand the Manifesto, which states, “comprehensive documentation”. This means some documentation is acceptable. Most Agile processes deliver working software to the customer every two to four weeks. And every build should be considered a potential release candidate.
  • Customer collaboration over contract negotiation: Don’t drag on negotiations with the customer. Make the deal, then get to work. Keep the customer informed at each step. If that means having the customer at the daily stand-up, so be it.
  • Responding to change over following a plan: Change happens. Get over it. You should be prepared for it and embrace it. Don’t needlessly put stuff into the project. Every piece of code your write should be tied back to a defined user story and should add value to the software. The nice thing about Agile is that if change to the business environment causes you to change the code, you won’t be months down some path that ends up being a dead end.

Now that we’ve covered Agile at a high level, which flavor of Agile should you choose? I’ve seen studies that indicate that 80-90% of Agile projects today are using Scrum. But other methodologies are effective. I know of a large web-based retailer that uses Extreme Programming (XP) and it is effective for them. The important thing is not which Agile methodology you choose, but that you pick one and use it properly. Many companies say they are Agile, but really aren’t. Get some Agile training and maybe bring in an expert to show you the way.

There you go, you have your soil. You’ve taken the first step to begin software gardening.