Is your organization doing Extreme Programming or one of the other agile methods? Are they considering it? Before you jump on the latest methodology bandwagon, you should make sure you're not just giving your developers a license to hack. Karl Wiegers provides some insight into how agile development models can be misused and how you can ensure that your process improvement effort has the best chance to be effective.
It was bound to happen. It had been a few years since someone offered the software industry a new productivity-enhancing miracle methodology. Managers and developers everywhere were primed for a new approach that avoided all those time-wasting requirements, design, and planning activities. So Extreme Programming and the other agile methodologies were welcomed with open arms.
But then the same old things started to happen. Developers chose to perform their favorite bits of Extreme Programming, ignoring the fact that XP defines an integrated set of practices. Apparently relieved of the burden of writing any documentation, programmers began typing furiously, perhaps with a second programmer sitting alongside so they could claim to be doing pair programming. "We don't know who our users will be, so we'll just bang out something quickly and see how it goes over," they said, neglecting XP's emphasis on full-time, on-site customer engagement. "No need to contemplate design," they said. "We'll refactor our code later." Developers thought they had been given a fresh, new license to hack. After all, it's called "Extreme Programming," not "Extreme Software Development."
I've seen this phenomenon before. "I'm following the spiral model," a developer would claim. "I don't need to write requirements because I'm just prototyping until the customer likes it." While iterative prototyping is a basic element of the spiral development model, the protesting developer didn't appreciate that risk management-which he wasn't doing-is also a central tenet. "We're doing RAD," (whatever that meant), insisted another team. "We don't have time to create a plan because we have to write this code rapidly." Evolutionary prototyping and evolutionary delivery are other legitimate development methods that the ill-informed or undisciplined developer uses as a license to hack.
All of these approaches to software development have structure, discipline, and a set of carefully selected practices that are thought to provide advantages on certain types of projects. They were devised by thoughtful people who wanted to help projects deliver useful and reliable products to customers quickly. Uninformed developers rashly adopt these new methods, assuming that the antonym of "waterfall" is "code-and-fix." It's not. Code-and-fix is indisputably the least efficient way to build quality software. However, it's fun, at least until the "and-fix" part gets old.
Programmers want a license to hack because most people find coding to be the most enjoyable part of software development. I haven't written a program in a few years, and I miss the excitement of creating software that does something interesting, amusing, or useful for myself or for others. So some developers embrace any methodology they think promises freedom from the tedium of understanding requirements, designing robust solutions, and planning the myriad activities that make up any nontrivial project. However, all of the methodologies mentioned above do include the nonprogramming steps, in various forms and depths.
Many software developers are inadequately trained in areas such as requirements engineering, configuration management, quality engineering, and project management. As a result, they don't appreciate the need for these activities. They're uncomfortable when asked to perform them, and they welcome any opportunity to bypass them. But these practices serve as important structures that lead to project success, not barriers that interfere with the "real" work of cutting code.
All development teams want to deliver their applications faster. Rapid development should begin with a retrospective analysis to understand the factors that prevent your team from being as productive as they'd like. The resulting insight might well suggest a change in the development lifecycle you're following and the practices you perform. This is the essence of process improvement. In contrast, jumping on the current methodology bandwagon without knowing