Introducing Agility: The Programmer’s Guide

If you’re not in charge of the team but would like to push them in this direction, you have a bit of a challenge ahead of you. You need to accomplish everything listed earlier in the previous section, but you’re going to have to lead by example, not by decree.

As the old saying might now go, “You can lead a horse to water…but you can’t make him use your favorite code editor.” Unless, of course, you seem to be having a really good time with it. If the benefit is obvious, then your teammates will want to get in on the action.

For instance, unit testing is a good place to start. You can start by using it on your own code. Within a short time (weeks or less), you see that your code has improved—you’ve lowered the number of errors, improved the quality, and enhanced its robustness. You start to go home at five, and all your tasks are complete—you’re not getting panic calls at night to fix bugs. The developer next to you wants to know what you’re doing differently, and the word spreads. Instead of you fighting to convince the team, they are now eager to pick up the newfangled practice.

If you want to lead your team into new territory, it’s only fair you go first. So start with the practices that you can do right now. Most of the practices in Chapter 2, ​Beginning Agility​, make a good start, followed by coding-oriented practices such as ​Put Angels on Your Shoulders​, and ​Use It Before You Build It​, and the practices in Chapter 6, ​Agile Coding​, and Chapter 7, ​Agile Debugging​. You can run a continuous build on your own machine and know about problems as soon as they happen. Your teammates may even think you’re clairvoyant.

After a while, you might start some informal brown-bag sessions (​Invest in Your Team​) and talk about the rhythms of an agile project (​Feel the Rhythm​) and other topics of interest.