Some Other Ideas

Every project and situation is going to be different, so it is impossible to provide a step-by-step solution to your problem. I've tried to outline some of the common approaches I've used or seen applied to various situations, particularly when dealing with a legacy product that was not developed using sustainable techniques.

Identify Key Architecture Battles

Do an architectural analysis, where you identify things such as poor structure and areas with a large number of defects. Every time you modify these sections of code, even if only for a minor change, consider doing some refactoring work in addition to just making the changes, even if this means setting aside extra time to make the changes. Be sure to add tests at least for the new code, and if you can, identify the key interfaces and add tests for them.

In your iteration planning sessions, write up some cards for the refactoring work. Users, product managers, and managers are in my experience very supportive of refactoring work if they are involved in the process of helping to set overall priorities and understand, at least at a high level, the purpose of the refactoring work. The visibility that this gives to the architecture of the product is good for the entire team, while at the same time ensuring that architectural issues are weighed against the feature work that users are demanding.

Get Your Defects Under Control

Hopefully, you should now be convinced that defect backlogs are a bad thing. Introduce some visible metrics, and possibly an ambitious goal such as HP's "10x reduction goal" [Grady 1997] to get people focused on the problem. Then, work hard toward a culture built around defect prevention and working software.

Collaboration with Users

For many organizations, one of the most difficult steps in introducing agile development is getting timely feedback from users. This is an ideal problem for senior management in the company to get involved with, to set up the necessary user contacts and also to get everyone in the organization focused on the need for greater user contact.

Training

Training is a crucial part of moving from an unsustainable to sustainable development culture. Training needs to be considered for the entire team, ideally at the same time. In the early stages, using an external source (consultant or training organization) for training is usually required, because even if someone inside the company says the same things as the consultant, the consultant will often be listened to more, simply because he or she is from outside. However, once the initial training is complete, it is highly desirable to set up an internal training program, where people inside the company are given the opportunity to train others on topics they are knowledgeable in.

Group Refactoring Exercises

An unorthodox idea that I've seen work is a competitive refactoring exercise. Pick a piece of code that has many broken windows in it. Then, get a bunch of people together in a conference room and do a pair programming exercise to refactor the code. Consider pairing people together who don't work together too much. Use a projector to review the solutions that each pair came up with during the day and discuss the pros and cons of each. Optionally, an award could be given for the solution the group likes the best. This exercise is time-consuming, but it helps everyone understand the difference between good code and bad, and the result can often be applied in the live code the next day. Also, the discussions are valuable for everyone, and the whole process can be fun with an underlying thread of competition.

The Work Environment

One factor that is often overlooked when introducing change is the impact of the physical space the team works in. If you possibly can, change the physical space that the team operates in to facilitate collaboration and reduce unnecessary interruptions. Sometimes, simple changes can make huge differences in terms of productivity, and the highly collaborative nature of agile development demands a work environment that does not inhibit collaboration and free communication. Too many organizations are penny wise, pound foolish and skimp on equipment that will increase productivity simply because the equipment is considered too expensive. Here are some ideas to consider:

• Build a project room for the team or convert a meeting room into a project room. Cover the walls of the room with whiteboards and corkboards, and think of this space as the location where anyone can go to get an immediate idea of the progress of the project. The Apple II project, for example, had a war room that gave every member of the company instant insight into the project [Lynn and Reilly 2002].

• Make sure there are lots of whiteboards readily available and install a projector so the team can hold productive team code and architecture reviews. Magnetic whiteboards are also an ideal place to keep the index cards for iteration and release planning.

• Do people who run automated tests have fast computers? Computers are so inexpensive now that there should be no excuse to not ensuring that people have adequate computing power readily available.

• Do you need to buy dedicated computers for running automated tests?

• Do you use the right tools for your project?

• Are you using a good version control system?

• Are there SDKs, compilers, or development environments that would make your team more efficient?

• If the desks available to the team inhibit collaboration through having partitions that are too high or are not large enough for pair programming, find a way to buy some new furniture that removes these problems.

A Final Word

Sustainability and agility are more important than consistency.

If you have multiple teams working together or on multiple projects, it's more important that they have the same mindset than that they employ the exact same set of practices in exactly the same way. All that needs to be fostered is a free exchange of ideas between teams and a willingness to continually try out and discard ideas. This is far more fun, rewarding, and empowering than dictating practices!