
SOFTWARE MANAGEMENT them is the only viable strategy. Rather than eliminating rework, the new strat- Agile Software egy is to reduce its cost. However, in not just accommodating change, but embracing it, we also must be careful to retain quality. Expectations Development: have grown over the years. The market demands and expects innovative, high- quality software that meets its needs— The Business of and soon. THE AGILE RESPONSE Agile methods are a response to this expectation. Their strategy is to reduce the Innovation cost of change throughout a project. Extreme Programming (XP), for example, calls for the software development team to Jim Highsmith, Cutter Consortium Alistair Cockburn, Humans and Technology • produce the first delivery in weeks, to achieve an early win and rapid feedback; he rise and fall of the dot- change grows through the software’s • invent simple solutions, so there is com-driven Internet economy development life cycle—remains valid, less to change and making those shouldn’t distract us from see- the question today is not how to stop changes is easier; T ing that the business environ- change early in a project but how to bet- • improve design quality continually, ment continues to change at a ter handle inevitable changes throughout making the next story less costly to dramatically increasing pace. To thrive its life cycle. implement; and in this turbulent environment, we must confront the business need for relentless innovation and forge the future work- Agile development combines force culture. Agile software develop- ment approaches such as Extreme Pro- creative teamwork with an gramming, Crystal methods, Lean Development, Scrum, Adaptive Software intense focus on effectiveness Development (ASD), and others view and maneuverability. change from a perspective that mirrors today’s turbulent business and technol- ogy environment. Traditional approaches assumed that if • test constantly, for earlier, less THE PROBLEM we just tried hard enough, we could antic- expensive, defect detection. In a recent study of more than 200 ipate the complete set of requirements software development projects, QSM early and reduce cost by eliminating Agile software development stresses Associates’ Michael Mah reported that change. Today, eliminating change early quality in design. These methods are some- the researchers couldn’t find nearly half means being unresponsive to business con- times confused with ad hoc or cowboy of the projects’ original plans to measure ditions—in other words, business failure. coding because the design is done on an against. Why? Conforming to plan was Similarly, traditional process manage- ongoing basis, in smaller chunks, as no longer the primary goal; instead, sat- ment—by continuous measurement, opposed to all at once and up front. Each isfying customers—at the time of deliv- error identification, and process refine- agile method addresses quality in certain ery, not at project initiation—took ments—strove to drive variations out of ways. For example, Dynamic Systems precedence. In many projects we review, processes. This approach assumes that Development Methodology (DSDM) calls major changes in the requirements, variations are the result of errors. Today, for a series of prototypes to attack unsta- scope, and technology that are outside while process problems certainly cause ble or unknown areas: new technology, the development team’s control often some errors, external environmental new business rules, and user interface occur within a project’s life span. changes cause critical variations. Because design. Scrum uses intense 15-minute daily Accepting that Barry Boehm’s life cycle we cannot eliminate these changes, dri- meetings and comprehensive iteration cost differentials theory—the cost of ving down the cost of responding to reviews at the end of each 30-day iteration. 120 Computer Basic principles must give, and we need to be clear about when a team of individuals practices Agile methods stress two concepts: the what stays and what gives. them. unforgiving honesty of working code and Relying on interactions between indi- Most methodologies provide inclusive the effectiveness of people working viduals facilitates sharing information rules—all the things you could possibly together with goodwill. and changing the process quickly when it do under all situations. Agile methods Working code tells the developers and needs changing. Using working software offer generative rules—a minimum set of sponsors what they really have in front allows us to measure how fast we actu- things you must do under all situations to of them—as opposed to promises as to ally produce results and provides quick generate appropriate practices for special what they will have in front of them. The feedback. Frequent interaction between situations. Teams that follow inclusive working code can be shipped, modified, individuals compensates for minimizing rules depend on someone else to name in or scrapped, but it is always real. documentation. advance the practices and conditions for Using people effectively achieves every situation. This obviously breaks maneuverability, speed, and cost savings. down quickly. A team that follows gen- People can transfer ideas faster by talking In a complex adaptive erative rules depends on individuals and face to face than by writing and reading system, decentralized, their creativity to find ways to solve prob- documents. A few designers sitting independent individuals lems as they arise. Creativity, not volu- together can produce a better design than interact to create minous written rules, is the only way to each could produce alone. When devel- innovative, emergent manage complex software development opers talk with customers and sponsors, results. problems and diverse situations. they can iron out difficulties, adjust pri- orities, and examine alternate paths for- AGILE PRACTICES ward in ways not possible when they are A team isn’t agile if the feedback loop not working together. Customer collaboration means that with customers and management is six all players—the sponsor, customer, user, months. Agile approaches recommend Agile Software Manifesto and developer—are on the same team. short iterations in the two- to six-week In recognition of these ideas, in Febru- Merging their different experiences and range during which the team makes con- ary 2001, we joined 15 other people rep- expertise with goodwill allows the com- stant trade-off decisions and adjusts to resenting XP, Scrum, DSDM, ASD, bined group to change directions new information. XP and Scrum have Crystal, Feature-Driven Development, quickly so they can produce more more directed cycles—two to three weeks pragmatic programming, and others appropriate results and less expensive for XP, 30 days for Scrum; other meth- sympathetic to the need for alternative designs. Contracts or project charters ods such as Crystal and ASD tolerate software development methods in sign- with the customers are necessary, but more variation. ing the Manifesto for Agile Software without collaboration, they are insuffi- Development. We wrote: cient. Feature planning and Working through producing a plan dynamic prioritization We are uncovering better ways of drives the team members to think Agile approaches combine these short developing software by doing it and through their project and its contingen- iterative cycles with feature planning and helping others do it. Through this cies. The plan itself usually goes out of dynamic prioritization. XP uses story work we have come to value date within just a few days. Afterward, cards; Scrum uses the term “backlog”; rather than focusing on the outdated ASD and Feature-Driven Development • individuals and interactions over plan, it is important to deal with the refer to features. The key point is that processes and tools, changing realities. agile approaches plan features, not tasks, • working software over comprehen- as the first priority because features are sive documentation, GENERATIVE RULES what customers understand. • customer collaboration over One aspect of agile development is Dynamic prioritization means that at contract negotiation, often missed or glossed over: a world the end of an iteration, the customer can • responding to change over follow- view that organizations are complex reprioritize the features desired in the ing a plan. adaptive systems. A complex adaptive next cycle, discarding originally planned system is one in which decentralized, features and adding new ones. Scrum That is, while there is value in the items independent individuals interact in self- explicitly states that priorities can only on the right, we value the items on the organizing ways, guided by a set of sim- change at the end of an iteration, not dur- left more. ple, generative rules, to create inno- ing one. DSDM uses “MoSCoW” rules vative, emergent results. XP’s 12 prac- for features—Must have, Should have, Processes, tools, documentation, contracts, tices, for example, were never intended Could have, Want to have sometime. and plans are useful. But when push comes to be all-inclusive rules; instead, they are XP’s priority scheme is binary—in this to shove—and it usually does—something generative rules that interact in concert cycle, or not. September 2001 121 Software Management Feedback and change Agility is dynamic, context-specific, Because they are most applicable to tur- aggressively change embracing, and bulent, high-change environments, agile growth-oriented. It is not about improv- Next- approaches
Details
-
File Typepdf
-
Upload Time-
-
Content LanguagesEnglish
-
Upload UserAnonymous/Not logged-in
-
File Pages3 Page
-
File Size-