>A recent conversation had me thinking again about what I view are the required practices that have to be implemented in order to start gaining the benefits Agile can provide. I had addressed this back in 2006 when I presented Agile XML Schema Development at the XML 2006 Conference. The paper and presentation are available from the STAR web site. For those that want the highlights, here they are:
- Unit Test – as much as possible, every bug/feature should have one or more tests that go with the code that you are checking in. These tests must be run during the automated builds.
- Continuous Integration builds from head – These must be run at least once an hour, and pull in the code from head to be rebuilt. Ideally they run as soon as new code is checked into the system. The build has to be fast…running in less than hour. Preferably running the entire test suite. You should also build the entire system every night for a complete integration build with other projects that you depend on. If a build fails, the people that checked in code since the last build are informed of the failure.
- A failing build is a drop everything moment. Thou shall not leave the build broken. If a build fails it gets the highest priority to be fixed. This really only works well if your builds do not take 6 hours to complete. If they do, then the build process needs to be re-addressed. So builds have to be fast to provide the necessary feedback. Oh and one thing. Commenting out the test that is failing is not fixing the build.
- Daily integration from head. Check out code daily into your workspace. This allows you to catch integration errors early. This is crucial. Before you start coding for the day, synch with the repository.
- Iterative development. Personally I’ve experimented with 2 week, 4 week, and 6 week iterations, and have found the best results in 2 week intervals. It helps keep the focus on what needs to be done. No longer than 4 weeks, (yes I know that some organizations use 6 weeks).
- Involve and communicate with stake holders consistently. If you have them, involve them in the end of iteration/milestone reviews. Gather the feedback and use that to help address issues in the next iteration.
There are other practices, that can be implemented to various degrees but I have found these are the most critical to implement. For those that are wondering how to do enterprise level planning and estimating, I’ve found Mike Cohn’s “Agile Estimating and Planning” book invaluable. Of course I’ve also found the concepts of Scrum to be a good fit for implementing agile in the various projects. Most of the time I’ve seen agile fail, it is not because of the process, but because the people that were implementing it didn’t stick to the required practices. Deviation from these will affect how well your project goes…whether it is agile or not.
Oh and just to show that almost anything can benefit from agile techniques, where I work we have managed to implement Agile successfully in something that most would not think could be agile. A Standards Organization. If we can make a standards organization agile…anything can be made agile. Read more about how we did that and the benefits in the paper.