The agile community has a saying: “Simplicity is the art of maximizing the work not done.” This idea is central to eliminating waste. To make your process more agile, do less.
However, you can’t take so much out of your process that it no longer works. As Albert Einstein said, “Everything should be made as simple as possible, but not one bit simpler.” Often, this means approaching your work in a new way.
Simplifying your process sometimes means sacrificing formal structures while increasing rigor. For example, an elegant mathematical proof sketched on the back of a napkin may be rigorous, but it’s informal. Similarly, sitting with customers decreases the amount of formal requirements documentation you create, but it substantially increases your ability to understand requirements.
Solutions come from feedback, communication, self-discipline, and trust. Feedback and direct communication reduce the need for intermediate deliverables. Self-discipline allows team members to work without the binding overhead of formal structures. Trust can replace the need to wait days—or longer—for formal signoffs.
Paring down your practices to the responsible essentials and removing bottlenecks lets you travel light. You can maximize the time you spend producing releasable software and improve the team’s ability to focus on what’s really important.
XP aggressively eliminates waste, more so than any method I know. It’s what makes XP extreme.
By having teams sit together and communicate directly, XP eliminates the need for intermediate requirements documents. By using close programmer collaboration and incremental design, XP eschews written design documents.
XP also eliminates waste by reusing practices in multiple roles. The obvious benefit of pair programming, for example, is continuous code review, but it also spreads knowledge throughout the team, promotes self-discipline, and reduces distractions. Collective code ownership not only enables incremental design and architecture, it removes the time wasted while you wait for someone else to make a necessary API change.
ISO 9001 certification is an essential competitive requirement for some organizations. I helped one such organization develop control software for their high-end equipment. This was the organization’s first XP project, so we had to figure out how to make ISO 9001 certification work with XP. Our challenge was to do so without the waste of unnecessary documentation procedures.
Nobody on the team was an expert in ISO 9001, so we started by asking one of the organization’s internal ISO 9001 auditors for help. (This was an example of the “Let the Right People Do the Right Things” principle, covered in Chapter 12.) From the auditor, we learned that ISO 9001 didn’t mandate any particular process; it just required that we had a process that achieved certain goals, that we could prove we had such a process, and that we proved we were following the process.
This gave us the flexibility we needed. To keep our process simple, we reused our existing practices to meet our ISO 9001 rules. Rather than creating thick requirements documents and test plans to demonstrate that we tested our product adequately, we structured our existing customer testing practice to fill the need. In addition to demonstrating conclusively that our software fulfilled its necessary functions, the customer tests showed that we followed our own internal processes.