How do we get there from here?

OK, last time I talked in vague terms about Agile software development, uncertainty, yada, yada, yada. But chances are if you are reading thing you already know what it means to be agile, and you even may know the benefits, but the one question I get asked the most is: How?

The first answer is that it is not easy. Many companies seem to be hardwired against agile methods from the start. Budgeting, bonuses, staffing all support a more linear waterfall project plan.

The best advice is to start small. Pick a project, preferrable a smaller project with large corporate visibility, and choose to be agile. Pick a method, such as Scrum, FDD, or even XP and a starting point and run the project using those methods as a guideline.

The first task after picking a project management guideline is picking an iteration length for the project. I would start out with 3 weeks and play it by ear. I like 2 week iterations, but they can start to feel fairly compressed, especially early on a project when you are ramping up.

From a technology side, I feel getting the environment set up to support agile methods is vital. I would highly recommend starting with a test-first development philosophy. Test-first development warrants is own topic, but in my opinion it drives 3 main benefits: Faster Development, Change with Confidence, and Quality Requirements.

The main drawback I hear to test-first development is that it requires more effort from the developers. If the metric for effort is lines of code, then naturally it requires more effort. However, if the metric is time, then I am not convinced. Based on my industry experience, code actually goes faster when unit testing coverage is higher, rather than lower. While this may initially seems counter-intuitive, the improvement in development time comes from catching bugs sooner rather than later. The further down the line a bug is discovered, the more effort is required to fix it. A good set of unit tests will catch 60% or so of the bugs as they are written, where the code is fresh in the mind of the developer.

One the philosphies of Agile Development is to embrace change. With a good set of unit tests, you can make changes to our code with confidence that the bugs will not cause problems in other parts of the system. These regression bugs, (As as I like to call them "Whack-a-Mole" bugs) can cause series headaches for developers and result in many lost hours. By investing in a set of unit tests, these bugs are caught sooner rather than later saving time throught development.

The last main advantage of the test-first technique is it helps to drive better requirements. By asking the question: "How can we test this?" it forces the analysts and customers to think about the feature at a deeper level. By going through the excercise, additional questions are usually raised that may not have been raised until much later in the process.

The next step is to set up a continuous integration server. There are several products available that accomplish this, including Cruise Control, which I am most familiar with. The idea behind continuous integration is that there is always a working copy of the build running at all times. Whenever a change is made to source control, a new build is made, unit tests are run, and it is deployed to the test area. If any of the steps fail, the entire team is notified through a tooltray icon, and the team works together to get the build up and running again.

The effect of continous integration is that integration related bugs are caught as soon as they are checked into source control. On many projects without Continuous Integration, there's a mad rush on build day to get changes into the build, and then a frantic effort to get the changes working together. By continously building the software, these frantic efforts are reduces and deployments can go smoothly.

The last thing I would recommend on your first Agile project is find a way to engage your customer. Getting regular face to face meetings is extremely important along with regular phone conferences, if necessary. Getting the face to face contact improves the communication, and just as important, it builds trust. Building trust allows the users to prioritize their requirements. All too often when a user hears "We'll but it on the next iteration" they interpret that to mean "You will never get that". After demonstrating in a couple iterations they will eventually see their lower priority items, they are much more willing to place items up the future task list and tackle them when they come up.