Only the Adaptable Will Survive Change

By Andy Hunt

June 15, 2006 —

Programmers are a conflicted lot. On the one hand, we love change. We love shiny new toys: new technologies, new programming languages, new challenges.

When the original C++ hit the scene, we embraced it warmly because now we had C with classes! When Java began to supplant C++, we were thrilled at getting better object orientation and memory management. Ruby is currently gaining fast on Java, and in another 10 years even Ruby itself probably will be replaced with some sort of direct neural-input system or something equally unimaginable.

But on the other hand, even though we tend to greet these new developments full of hope and excitement, it seems we really hate change. We hate new and steep learning curves that are forced upon us, gratuitous vendor upgrades that aren’t backward compatible, and new languages with weird, unfamiliar syntax (and far too many angle brackets). We especially hate those pesky users who keep changing their minds about requirements once they start using the system.

Change ain’t all it’s cracked up to be.

Charles Darwin observed, “It is not the strongest of the species that will survive, or the most intelligent. It is the one most adaptable to change.” That sentiment holds true in both the biology and business fields. We like to go around saying that “adapting to change” is what agile software development is all about. But what does that mean, exactly?

Some folks seem to take “agility” as a license to run around like headless chickens, in perpetual crisis mode. Others take adaptability as a commandment to hack mercilessly. And some take “agility” as permission to beat their teams senseless with aggressive, unrealistic schedules.

That’s not what we mean by agile.

In our latest book, “Practices of an Agile Developer: Working in the Real World,” I settled on the following pithy definition: Agile development uses feedback to make constant adjustments in a highly collaborative environment.

The agile approach combines responsive, collaborative people with a focus on demonstrable, concrete goals—in other words, software that actually works. That’s the spirit of agility. The practical emphasis of development shifts from a plan-based approach—where key events happen in individual, separate episodes—to a more natural, continuous style.

That means you don’t leave testing to the end of the project. You don’t leave integration to the end of the month or stop gathering requirements and feedback as you begin to code.

Continuous Development
Instead, you continue to perform all these activities throughout the life cycle of the project. In fact, since software is never really “done” as long as people continue to use it, it’s arguable that these aren’t even projects anymore.

Development is continuous. Feedback is continuous, from the users, the code itself and your teammates. You don’t have to wait for months to find out that something is wrong: You find out quickly, while it’s still relatively easy to fix. And you fix it, right then and there, while the details are still fresh in your mind.

That’s what it’s all about.

This idea of continuous, ongoing development is pervasive in agile methods. It includes not only the development life cycle itself, but also technology skills learning, requirements gathering, product deployment, user training and everything else. It encompasses all activities, at all levels.

Why? Because developing software is such a complex activity, anything substantive that you leave until later won’t happen, won’t happen well, or will grow worse and fester until it becomes unmanageable. A certain kind of friction increases, and things get harder to fix and harder to change. As with any friction, the only way to fight it effectively is to continually inject a little energy into the system.

NOT A CRISIS
Some skeptics raise the concern that agile development is just crisis management in disguise. It’s not. Crisis management occurs when problems are left to fester until they become so large that you have to drop everything else you’re doing to respond to the crisis immediately. This causes secondary crises, so now you have a vicious cycle of never-ending crisis and panic. That’s precisely what you want to avoid by adopting an agile approach.

Instead, you want to tackle small problems while they are still small, explore the unknown before you invest too much in it, and be prepared to admit you got it all wrong as soon as you discover the truth.

When you’re doing agile development, you are part of a team. Agile teams tend to be small or broken up into several small (10 or so people) teams. You mostly work very closely together, in the same war room (or bullpen) if possible, sharing the code and the necessary development tasks. You work closely with the client or customer who is paying for this software and show the client the latest version of the system as early and often as possible.

You get constant feedback from the code you’re writing and use automation to build and test the project continuously. You’ll notice that the code needs to change as you go along; while the functionality remains the same, you’ll still need to redesign parts of the code to keep up. That’s called refactoring, and it’s an ongoing part of development—code is never really done.

Work progresses in iterations: small blocks of time (a week or two or so) where you identify a set of features and implement them. You demo the iteration to the customer to get feedback (and make sure you’re headed in the right direction) and release full versions to the user community as often as practical.

Agile development recognizes the importance of pragmatism, and seeks to adjust everything—the schedule, the design, the features—based on what is really happening. It’s about facing reality and dealing with it, not hiding behind an IDE, PowerPoint presentation or a Gantt chart.

I’ve seen plenty of projects fail over the past 25 or so years—both traditional, plan-based projects and newer agile projects. In either case, the dogmatic approach fails.

Sticking to any plan or technique that is no longer appropriate is a guaranteed way to fail. Both the dodo bird and the buggy whip manufacturers learned this lesson the hard way. The economic equivalent of a giant, dinosaur-extinguishing meteor or the next business ice age could come upon us at any moment. And when that happens, only the agile will survive.

Long ago, Heraclitus recognized that “the only constant is change.” But that’s a little misleading: Only the presence of change is a constant. These days, the rate of change is closer to exponential. You can’t avoid it, you can’t hide from it, and you’d be hard-pressed to react to it after the fact.

If you’ve tried something promoted as “agile” but weren’t happy with it, perhaps you should look again. Maybe what you were being sold wasn’t as agile—or as pragmatic—as you thought.

And if you and your company are using an agile approach successfully, that’s great! See you around.I’ll sure miss those other guys.

Share this link: http://www.sdtimes.com/link/29375

Change Manager blends roles of DBAs, developers Embarcadero's first post-acquisition version of CodeGear's Change Manager aims to combine the activities of developers and database administrators. It can hold numerous schemas in memory and examine the effects of changes on the whole database, among other abilities.

Unified change management helps IT and developers Changes in a company's internal software can cause anxiety, so it is a sound idea to join together the schedules of both the development and IT sides. This, along with adhering to best practices and consistent training, can ease everyone's jobs.

AmberPoint Governance System searches for changes in app environments The company’s new SOA solution design provides visibility into all life-cycle stages by linking with other management systems

Add comment

Name*
Email*
Country

Comment
Preview

News on Monday
more>>
SharePoint Tech Report
more>>

Download Current Issue
ISSUE 3/15/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?

Google Code turns 5
Google Code Turns 5, and adds a Paxos Algorithm to make the system more stable and reliable.
03/17/2010 11:16 AM EST

Test your Visual Studio 2010 know-how
Microsoft is offering free beta certification exams for Visual Studio 2010.
03/17/2010 11:08 AM EST

Microsoft lifts the hood on IE9
Microsoft is previewing IE9.
03/16/2010 01:10 PM EST