Adaptive Software Development
Buy this book at www.fatbrain.com
Workstate, Not Workflow
By Alan Zeichick
What should be the goal of a software development department? To develop processes designed to help them climb the CMM ladder? Or to build software that suits the customers? needs? In a perfect world, perhaps, the answer would be ?both,? but in the real world, you can have one or the other. You can spend hours writing down policies so that your developers will strictly adhere to a certain set of methodologies, best practices, frameworks and procedures?in other words, you can mandate a process. Or, says James A. Highsmith III, you can find out what your customers need, set step-by-step goals that will propel you closer to meeting those needs, and then create a collaborative environment that will allow you to proceed one step at a time while constantly re-evaluating the work that still lies ahead.
I really enjoyed ?Adaptive Software Development,? which I found unusually thought-provoking. Highsmith?s stories about mountain climbing, and the way in which he drew analogies between that sport?which has both individual and group aspects?and software development are clever and help to frame his discussion. However, it would be a mistake to look at this book as a silver bullet. There?s no ?Aha!? aspect; you?re not going to rush out and re-engineer your core processes. But Highsmith offers many good ideas.
For example, without referring to Extreme Programming by name, he pointed out many of the flaws in such a RAD-to-the-max development methodology, which relies upon instant gratification, rather than solid design, as its foundation. Yet he also recognizes the importance of RAD; in fact, Highsmith?s solution to the industry?s woes, which he calls Adaptive Development, is a refinement of his own RAD model.
The key to Highsmith?s model is the word ?adaptive? itself. By that, he means that developers should assume that their customers? needs will constantly be changing. Management needs to define a mission for a project, determine the features and dates, and break the project into a series of individual steps, or cycles, each between four and eight weeks. Early steps might verify the project?s scope; later ones will design an architecture, build the code, perform final testing and then deploy.
A key point is that the steps aren?t defined by workflow, or by who does what tasks. Rather, the key indicator of success is the state the project is in at the conclusion of each step: That?s the workstate, says Highsmith. By focusing on tangible results, rather than processes, the project is guaranteed to move forward. Once the plan is in place, managers bring their teams together to complete each step, one at a time.
Those steps, however, aren?t monolithic, and aren?t necessarily designed to produce perfect results. Adaptation is significantly more important than optimization, he says. Assuming that the project is going to be rebuilt or modified, don?t waste your time building a perfect solution in 18 months?that?s too late, too huge and too inflexible to satisfy the customer. Instead, design your steps to create a good-enough solution in three months, with a procedure in place to change that solution as required. Then, your customers are satisfied, and you have an adaptable framework from which to build.
How to do it? Collaboration. Key individuals involved in a project need to constantly engage in joint application development sessions, formal and informal customer reviews, prototyping?the usual. More important, managers need to realize that the best work is done by what Highsmith calls ?Great Groups??teams of people who are in the groove. Fostering a technological and social environment in which people feel empowered and want to put in the extra effort to become a Great Team is key to meeting milestones, controlling costs and reducing defects?and quickly adapting to changing conditions.
Sound simple? It?s not, according to Highsmith, who presents his own techniques for implementing what he calls the ?adaptive development lifecycle? of speculation, collaboration and learning. After he lays out the basics of his model, most of the book is spent exploring the different aspects of that model, presenting suggested best practices for encouraging Great Groups collaboration within a programming team and an entire organization, and ways of tuning his methodology to deal with real-world pressures.
He?s no pie-in-the-sky idealist?in ?Adaptive Software Development,? Highsmith demonstrates that you don?t have to adopt radical new development methodologies, or become a slave to specific process, in order to build and deliver the software that your customers want. Again, it?s a good book: You won?t decide to turn your organization upside down, but if you adopt even a few of his ideas, your team will be the better for it.
Reprinted with permission of SDTimes. Originally appeared in Issue 28 April 15, 2001.