Agile methods recognize the humanity at the core of software development. Agile methods are built around people, not machines. Working effectively requires an understanding deeper than the surface mechanics of how people interact or who makes decisions.
One aspect of humanity is that we’re fallible. We make mistakes, forget important practices, and obstinately refuse to do things that are good for us—especially when we’re tired or under stress.
We have strengths, too. We are creative, playful, and—under the right circumstances—passionate and driven to succeed. No machine can match these characteristics.
As you modify your agile method, work with these essential strengths and weaknesses. Don’t require perfection; instead, build your process to identify and fix mistakes quickly. Do take advantage of your team’s creativity. If a task is boring and repetitive, automate it.
Have fun, too. Software development may be big business, but the best developers I know love their jobs. They’re passionate about their projects, and they also joke and play. The great teams I know socialize outside of work. There’s no way for your agile method to enforce this, but you can create the conditions for it to happen by identifying and eliminating the barriers to natural social interaction.
XP’s demand for self-discipline seems to violate this principle of understanding human weakness. People aren’t good at being self-disciplined all the time, so how can XP succeed?
XP handles the challenge of self-discipline in several ways. First, software developers love to produce high-quality work; once they see the quality of code that XP provides, they tend to love it. They may not always stay disciplined about the practices, but they generally want to follow the practices. Allowing people to take responsibility for their own quality encourages them to work to their full potential.
Second, energized work and pair programming give developers the support they need to be disciplined. Developers that want to follow the practices are most likely to break them when they feel tired or frustrated. Energized work reduces the likelihood of this happening. Pair programming provides positive peer pressure and additional support; if one member of the pair feels like taking an ill-advised shortcut, the other often reins him in.
Finally, while XP requires that the team be generally disciplined, it doesn’t require perfection. If a pair makes a poor decision, collective code ownership means that another pair is likely to see it and fix it later. Ultimately, XP assumes that the design is fluid—refactoring and incremental design make it much easier to fix mistakes, while iterative design and adaptive planning put the most valuable features of the code under continual review.
XP works with the team’s essential humanity in other ways, too. Among them are the automated build, which replaces tedious tasks with automated scripts, and test-driven development, which uses baby steps and constant feedback to help programmers spot and fix mistakes as soon as they occur.
A friend—“Mel”—used to work for a small consulting company. The shop had three to five developers and twice that many clients at any time, so it was common for them to work on several projects during the week. To simplify billing, the company used a custom time-tracking application that ran constantly in Windows, requiring developers to enter different billing codes whenever they changed tasks.
That single application was the only reason the developers needed to use Windows, as they deployed almost exclusively to Linux-based platforms. The lack of access to native tools occasionally caused problems. Regular task-switching—the reason for the time-tracking application—was often a more serious problem among the developers than minute-by-minute statistics.
Mel’s solution had two parts. First, he dedicated his mornings to small tasks such as addressing bug reports or minor enhancements or customer requests. The minimum billable unit was 15 minutes, which was just about enough time to get into a flow state for any particular project. This left his afternoons (his most productive time) for longer tasks of two to four hours. Very few customer requests needed immediate solutions, and most of the customers were on the East Coast with a three-hour time difference; when he returned from lunch at 1 p.m., his customers were preparing to leave for the day.
The second part of the solution was using index cards to record task times. This was often faster than finding the right billing codes in the application. It also meant that Mel could boot his computer into Linux and stay there, then enter his stats into the application on another machine just before leaving for the day. The other developers noticed Mel’s productivity increase, and he was only too happy to share his ideas. When their manager realized that everyone had switched to a new system, the results were inarguable. The developers were happier and more productive.