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 whether it will address shortcomings in your current development approach is a fruitless quest for the nonexistent silver bullet.
If you do adopt a different lifecycle or development methodology, make sure your team members understand how the components fit together, the rationale behind each element, and the types of projects for which the methodology is appropriate. For example, incremental delivery approaches are often ill-suited for embedded systems but work well for rapidly changing Internet projects. Do you want to fly in an airplane whose avionics were written by an Extreme Programming team or by a CMM Level 5 shop? I'll take Level 5 every time.
Set clear expectations that your projects will follow a structured, yet flexible, approach that will enable timely delivery of high quality, customer-driven functionality. Your product doesn't disappear after its release date and developers often change jobs, so write enough documentation to let future maintainers efficiently adapt the system to meet new business needs.
There's a broad spectrum of discipline between the dogmatic rigidity that some fear from software process improvement and the high entropy of code-and-fix programming. Give your team the best available processes and methods to engineer excellent software, but don't give them a license to hack.
