Rating: 
Summary: Leadership and collaboration
Review: "Adaptive Software Development" is a light, human-powered methodology for development of complex software systems. Unlike Extreme Programming, Adaptive Software Development is less disciplined and does not mandate individual techniques like On-Site Customer, Pair Programming or Automated Tests. It rather encourages adaptation, which depends on leadership and collaboration.One of the vital components of Adaptive Software Development is clearly articulated Project Mission, Shared Vision and Clear Focus, and it is the responsibility of the whole team to create the mission and use it on a day-to-day basis as an alignment tool to keep the common direction. I would also highly recommend "Agile Software Development" by Alistair Cockburn in addition to this book.
Rating:
Summary: Leadership and collaboration
Review: "Adaptive Software Development" is a light, human-powered methodology for development of complex software systems. Unlike Extreme Programming, Adaptive Software Development is less disciplined and does not mandate individual techniques like On-Site Customer, Pair Programming or Automated Tests. It rather encourages adaptation, which depends on leadership and collaboration. One of the vital components of Adaptive Software Development is clearly articulated Project Mission, Shared Vision and Clear Focus, and it is the responsibility of the whole team to create the mission and use it on a day-to-day basis as an alignment tool to keep the common direction. I would also highly recommend "Agile Software Development" by Alistair Cockburn in addition to this book.
Rating: 
Summary: How to Manage High-Speed, High-Change Projects
Review: ABOUT THE BOOK To survive in today's turbulent e-business world, software project teams must exhibit adaptability, speed, and collaboration. Adaptive Software Development is targeted at software teams where competition creates extreme pressure on the delivery process. Four goals of the book are * to support an adaptive culture in which change and uncertainty are assumed to be the natural state
* to guide the iterative process of managing change using frameworks
* to institute collaboration, the interaction of people on interpersonal, cultural, and structural levels
* to add rigor and discipline to the RAD approach, making it scalable to the uncertainty and complexity of real-world undertakings This innovative text, grounded in the science of complex adaptive systems theory, offers a practical, realistic approach to managing the high-speed, high-change projects characteristic of our highly uncertain economy. ABOUT THE AUTHOR JAMES A. HIGHSMITH III began his career working on software for the Apollo spacecraft program. He has written dozens of articles for industry publication, and he serves as editor of e-business Application Delivery. A principal of Information Architects, Inc., based in Salt Lake City, Highsmith teaches and consults on software quality process improvement, project management, and accelerated development techniques. Married and the father of two grown daughters, he is an avid mountain climber and Dawdling, McLuhan, and Thin Air REVIEWS "Jim . . . decided to tell us the truth, uncomfortable as it will end of a narrow tunnel, and then drive work effort down that tunnel to reach the light. . . . Rather, development teams need to seek a light that emerges along a discovered path, incrementally illuminating sign posts. . . . Adaptive Software Development gives us . . . the vocabulary we need to discuss the truth, and still create results. Bravo!"
-- Adele Goldberg, Founder and CEO of Neometron "A great introduction to applying complexity theory to the software development process. . . . for every project manager that wants to know how the next generation of systems will be built."
-- James Odell, Consultant and Coauthor of Object-Oriented Methods "Jim Highsmith . . . writes for those of us who have to develop real software in a competitive, constrained, high-change environment. "There can be no canned answers to the problems of modern, rapid software development. Adaptive Software Development heralds an emerging discipline of inventing and adapting strategies to fit each situation. This discipline requires that we study the dynamics of software projects and software people, not merely their practices or documents."
-- James A. Bach, Principal Consultant, Satisfice, Inc. ". . . contains many examples and analogies that I can use in helping clients be more effective in using teamwork and group learning on software development projects. . . ."
-- Cheryl Allen, KSI, Inc. "Well done! . . . a plethora of provocative ideas."
-- Robert N. Charette, ITABHI Corporation ". . . successfully rebuts software development traditionalists with results over process. . . . a must read for the thinking developer."
-- Rob Arnold, former CEO of ST Labs, Inc.
Rating:
Summary: MustRead
Review: Compelling case for Adaptive Software Development (ASD), an approach enabling successful completion of complex software development projects. Draws on the theory of complex adaptive systems (CAS). Explains using judicious analogies with mountain climbing. Assembles ideas from the author's own extensive experience and readings. Describes in some detail the ideas of other authors that have influenced ASD. Excellent annotated bibliography allows the reader to pursue further study in any of a number of different directions. It's hard to express just how good this book is. I can't recommend it highly enough. If you're interested in the currents of thought on software development variously labeled "extreme" or "agile," then I believe you will find Adaptive Software Development to be very near to their sources. The author distinguishes a "complex" project from one that is merely "complicated." As one might well imagine, he would classify a project to develop the avionics software for the NASA space shuttle as complicated--but not complex: its goal is well defined and attainable by applying the stable laws of Newtonian physics. Development of an internet-based product for the consumer marketplace on the other hand is complex because one might expect almost anything to change during the course of such a project: target technology, competitive offerings, financing, marketing strategy, etc. Complexity arises from moving fast in a continually changing environment. Adaptive Software Development comprises
(1) Adaptive Conceptual Model--the theoretical foundation,
(2) Adaptive Development Model--a software development lifecycle for complex projects, and
(3) Adaptive Management Model--principles for managing complex projects. (1) The Adaptive Conceptual Model proposes that a software development organization is a complex adaptive system like a marketplace or a flock of birds. According to the theory, CASs composed of independent agents acting for themselves without centralized control can under proper circumstances develop "emergent" capabilities exceeding the mere sum of the capabilities of the individual agents. It is further proposed that only emergent capabilities are powerful enough to tame complexity. Software development organizations aspiring to do so must create the proper circumstances for the emergence of superior capabilities. The Development Model and the Management Model show the way. (2) The Adaptive Development Model has three phases: Speculate, Collaborate, Learn. A typical project is expected to cycle through the phases several times. The output of each successive cycle converges on the final product of the project. The beginning of each cycle is called "speculation" in preference to "planning" to reject the command-and-control philosophy that stifles emergence. ASD establishes a general direction, hypothesizes a product with a set of components, then puts the developers to work. Tasks are not specified in the ASD project plan--only the components to be completed by the end of the cycle. Collaboration is the phase where development occurs. Under conditions of "diversity, rich relationships, unfettered information flow, and good leadership (p. 45)" collaboration can be the crucible of emergent capability. To foster this emergence, the project leader must keep the team "poised at the edge of chaos," imposing just enough rigor on the collaboration to keep it from spinning out of control. To impose any more rigor would stifle emergence. Borrowing from Ralph Stacey, Mr. Highsmith cites five dimensions for measuring how closely a project team approaches chaos. The goal is to structure collaboration so that it has just enough--but never too much--of each of the following: 1. Information Flow
2. Diversity
3. Rich Connectivity
4. Contained Anxiety
5. Power Differential. Mr. Highsmith observes that adaptation, not optimization, is the key to success in a complex ecosystem. Software developers adapt by learning. ASD ends every cycle with specific collaborative learning activities including customer focus groups, technical reviews, post-mortems, etc. The adaptations resulting from the learning phase keep the output of subsequent cycles converging on a successful product. (3) ASD gives to the project leader responsibility for establishing the conditions under which superior capabilities emerge from the collaboration of team members. This responsibility entails "the ability to help teams to understand the project's mission, to stand back and let the group struggle with mistakes, to encourage learning, to balance the need for flexibility and rigor, and to force decisions onto the group (pp. 209-210)." To balance successfully between flexibility and rigor--poised at the edge of chaos--managers of complex projects must attend primarily to two structural elements: workstate and network. ASD manages workSTATE in preference to workFLOW. Instead of monitoring the completion of tasks, the project leader tracks the completion of components. Tasks are not necessarily prescribed. Team members decide for themselves how to build the components. To scale up to large projects, workstate management defines explicit milestones for each component describing its degree of completion. Progress is tracked against these milestones. The emergence of superior capability through collaboration depends on the communication network of the collaborators. For smaller, collocated teams with sufficient interpersonal skills, it will emerge informally. For larger teams, ASD prescribes a conscious effort to build it and to maintain it. The remote nodes of a virtual team are all too likely to fall into a state of insufficient interaction. The collaboration network should provide team members just a little more information than they need, stopping just short of overload. Information clutter must be avoided. Content must not be provided without context (author, revision date, approval status, for example). The formal properties of the collaboration network must be identified and tuned to the needs of the complex project. A "collaboration service layer" of tools (mostly web-based) and practices must be installed. A new role, collaboration facilitator, extending the role of JAD facilitator, should be created to tend the collaboration network. Is a software development organization really a complex adaptive system? No matter. Mr. Highsmith has ably used the theory of complex adaptive systems as a powerful metaphor for unifying many existing ideas about managing complex software development and for generating new ones--with at least as much validity as older theories have been applied in the past. Stimulating and refreshing. A must-read by any standard.
Rating:
Summary: MustRead
Review: Compelling case for Adaptive Software Development (ASD), an approach enabling successful completion of complex software development projects. Draws on the theory of complex adaptive systems (CAS). Explains using judicious analogies with mountain climbing. Assembles ideas from the author's own extensive experience and readings. Describes in some detail the ideas of other authors that have influenced ASD. Excellent annotated bibliography allows the reader to pursue further study in any of a number of different directions. It's hard to express just how good this book is. I can't recommend it highly enough. If you're interested in the currents of thought on software development variously labeled "extreme" or "agile," then I believe you will find Adaptive Software Development to be very near to their sources. The author distinguishes a "complex" project from one that is merely "complicated." As one might well imagine, he would classify a project to develop the avionics software for the NASA space shuttle as complicated--but not complex: its goal is well defined and attainable by applying the stable laws of Newtonian physics. Development of an internet-based product for the consumer marketplace on the other hand is complex because one might expect almost anything to change during the course of such a project: target technology, competitive offerings, financing, marketing strategy, etc. Complexity arises from moving fast in a continually changing environment. Adaptive Software Development comprises
(1) Adaptive Conceptual Model--the theoretical foundation,
(2) Adaptive Development Model--a software development lifecycle for complex projects, and
(3) Adaptive Management Model--principles for managing complex projects. (1) The Adaptive Conceptual Model proposes that a software development organization is a complex adaptive system like a marketplace or a flock of birds. According to the theory, CASs composed of independent agents acting for themselves without centralized control can under proper circumstances develop "emergent" capabilities exceeding the mere sum of the capabilities of the individual agents. It is further proposed that only emergent capabilities are powerful enough to tame complexity. Software development organizations aspiring to do so must create the proper circumstances for the emergence of superior capabilities. The Development Model and the Management Model show the way. (2) The Adaptive Development Model has three phases: Speculate, Collaborate, Learn. A typical project is expected to cycle through the phases several times. The output of each successive cycle converges on the final product of the project. The beginning of each cycle is called "speculation" in preference to "planning" to reject the command-and-control philosophy that stifles emergence. ASD establishes a general direction, hypothesizes a product with a set of components, then puts the developers to work. Tasks are not specified in the ASD project plan--only the components to be completed by the end of the cycle. Collaboration is the phase where development occurs. Under conditions of "diversity, rich relationships, unfettered information flow, and good leadership (p. 45)" collaboration can be the crucible of emergent capability. To foster this emergence, the project leader must keep the team "poised at the edge of chaos," imposing just enough rigor on the collaboration to keep it from spinning out of control. To impose any more rigor would stifle emergence. Borrowing from Ralph Stacey, Mr. Highsmith cites five dimensions for measuring how closely a project team approaches chaos. The goal is to structure collaboration so that it has just enough--but never too much--of each of the following: 1. Information Flow
2. Diversity
3. Rich Connectivity
4. Contained Anxiety
5. Power Differential. Mr. Highsmith observes that adaptation, not optimization, is the key to success in a complex ecosystem. Software developers adapt by learning. ASD ends every cycle with specific collaborative learning activities including customer focus groups, technical reviews, post-mortems, etc. The adaptations resulting from the learning phase keep the output of subsequent cycles converging on a successful product. (3) ASD gives to the project leader responsibility for establishing the conditions under which superior capabilities emerge from the collaboration of team members. This responsibility entails "the ability to help teams to understand the project's mission, to stand back and let the group struggle with mistakes, to encourage learning, to balance the need for flexibility and rigor, and to force decisions onto the group (pp. 209-210)." To balance successfully between flexibility and rigor--poised at the edge of chaos--managers of complex projects must attend primarily to two structural elements: workstate and network. ASD manages workSTATE in preference to workFLOW. Instead of monitoring the completion of tasks, the project leader tracks the completion of components. Tasks are not necessarily prescribed. Team members decide for themselves how to build the components. To scale up to large projects, workstate management defines explicit milestones for each component describing its degree of completion. Progress is tracked against these milestones. The emergence of superior capability through collaboration depends on the communication network of the collaborators. For smaller, collocated teams with sufficient interpersonal skills, it will emerge informally. For larger teams, ASD prescribes a conscious effort to build it and to maintain it. The remote nodes of a virtual team are all too likely to fall into a state of insufficient interaction. The collaboration network should provide team members just a little more information than they need, stopping just short of overload. Information clutter must be avoided. Content must not be provided without context (author, revision date, approval status, for example). The formal properties of the collaboration network must be identified and tuned to the needs of the complex project. A "collaboration service layer" of tools (mostly web-based) and practices must be installed. A new role, collaboration facilitator, extending the role of JAD facilitator, should be created to tend the collaboration network. Is a software development organization really a complex adaptive system? No matter. Mr. Highsmith has ably used the theory of complex adaptive systems as a powerful metaphor for unifying many existing ideas about managing complex software development and for generating new ones--with at least as much validity as older theories have been applied in the past. Stimulating and refreshing. A must-read by any standard.
Rating:
Summary: Solid theory behind the Agile movement
Review: Highsmith postulates: "If the core of our belief system about managing organizations is rooted in the old science of deterministic Newtonian physics and survival-of-the-fittest Darwinian biology, then only a new science such as complex adaptive systems with an equally powerful philosophy and scientific foundation provides the credibility necessary for a major management cultural evolution." He then persuasively uses the science and language of complex adaptive system theory to provide new conceptual models to guide complex software development projects. His presentation is refreshingly well thought out, synthesizing much of the best ideas in science and business management in the past decade to software development. Highsmith succeeds is providing a theoretical basis for the Agile methodologies that are sprouting up everywhere (XP being the best known). If you are looking for specific best practices of software development, look elsewhere. But if you want to understand the true nature of software development as well as principles in harnessing change as a competitive advantage, you will not find a better book. I couldn't recommend it any more strongly.
Rating:
Summary: Sensible software process
Review: I have worked at a Fortune 100 company for > 15 years as a software engineer, software manager, and consultant on improving software projects. During that time, I've read many texts on software engineering and software management. This book, more than any other I've read, best captures my philosophy of software management, except for the rants against software process and the SEI which I think are a little much at times. Really, what the author advocates (at least in my reading of this book) is a sensible balance -- not too much process nor too little. This book, along with Rapid Development, are my two favorite "handbooks" for software managers. If you're looking for a quick recipe that doesn't require thought and is guaranteed to be successful, you won't find it here. However, I'd argue that you won't find it anywhere. What you will find is a guide to developing your own "common sense" on software management.
Rating: 
Summary: Keeping cool in the demanding e-development world
Review: If you're about to start a new software development project, it's worth reading this book first. It will help you make some sense of today's demands on you that software development should be fast and iterative while meeting ever-changing requirements. James Highsmith offers and explains concepts like "adaptive" and "emergent" and explains what to do with them in real life. It's not a complete how-to book, though. While it has a lot of detail, be prepared to read it and discuss with your co-workers to figure out what part of the ideas you may be able to apply on your upcoming project.
Rating: 
Summary: "Rock climbing, Joel ! Rock climbing !"
Review: The quote is from Mystery Science Theater 3000, and is used to identify a movie scene so repetitious that it seems like torture. But it could also apply to this book. I've lost count of how many times Highsmith has padded his text with rock climbing metaphors. It's annoying and distracting and it adds only fluff. I've developed the practice of skipping the paragraph whenever Highsmith starts another inane mountaineering passage. There is some meat in this book, but you've got to nibble around a whole lot of loess to get it.
Rating:
Summary: Mountain climbing as an analogy for software development
Review: There are many areas of human endeavor that can be used as an analogy for software development. In this book, the author uses mountain climbing to illustrate his points about teamwork, planning and adaptation to rapidly changing conditions. The points are well-taken, although he does stretch it a bit. If the team doesn't function well or a judgment error is committed while climbing, there is the real and immediate threat of injury or death. Similar problems in software development lead to much gentler consequences that are sometimes years in the future. One does not easily change teams in the middle of a climb and developers often have several golden ropes to clutch if it is necessary to leave. Nevertheless, the comparison is largely a good one.
The most significant point is about how software development must be a process of aggressive, rapid adaptation to changing conditions. Among all the things that we do, software construction changes faster than anything else. The solution is to perform the delicate act of balancing on the head of a pin. On one side, there is the necessity of setting down standards of rigor that will keep the process within acceptable boundaries. However, the addition of too much rigor and the mortis sets in, making it too difficult to change the product when the inevitable modifications are needed. Many such strategies for how to maintain this minuscule middle are set forward. There are many points of sound advice in this book, several of which lead to the following simple adage. "Rules can be barriers to hide behind or guidelines for the wise to consider and break when the circumstances justify it." Effectively executing the latter is the not so secret plan for success in the current IT world of dynamic competition.
I respectfully disagree with the author on one point. He argues that the day of the lone "coding cowboy", where one programmer builds a killer app, is over. While the lone programmer may be a thing of the past, the small team is not, and some small teams of two or three can work wonders. The second point of my disagreement are due to the increasing use of components and rapid development tools. Given the library of tools that can be used, it is now possible for one person to put several distinct items together in a unique way and build a complete system. Furthermore, it may be possible for a lone programmer to build the next little "big thing" component that could revolutionize how we do some things.
Despite my occasional disagreements with the points made, reading this book made me think a little harder about some aspects of the software development process. The authors' metaphors of biological adaptation and mountain climbing have many equivalencies in software development that should be seriously considered.
| 
