agile dinosaurs

www.s tqemagaz ine .com Sof tware Tes t ing & Qua l i t y Eng inee r ing Ju ly/Augus t 200022

This article is provided courtesy of Software Testing & Quality Engineering (STQE) magazine.

Management & TeamsManagement & Teams

DINOSAURSUsing Adaptive Software Development

to meet the challenges of a high-speed,

high-change environment

by Jim Highsmith

RETIR INGLIFECYCLE

Contrary to what you’ve heard all of your life,

form doesn’t follow function. Form follows

failure.

“The form of made things is always sub-

ject to change in response to their real or per-

ceived shortcomings, their failures to func-

tion properly,” writes Henry

Petroski, civil engineering pro-

fessor and author of The Evo-

lution of Useful Things. “This

principle governs all invention, innovation,

and ingenuity; it is what drives all inventors,

innovators, and engineers.” In a similar vein,

author Stuart Brand decries the oft quoted

“form follows function” as an illusion, writing

in How Buildings Learn: “[Louis] Sullivan’s

form-follows-function misled a

century of architects into be-

lieving that they could really

anticipate function.”

QUICK LOOK

■ Rethinking traditional projectmanagement practices

■ 6 characteristics of anadaptive lifecycle

http://www.stqemagazine.com/

May/June 2000 Sof tware Tes t ing & Qua l i t y Eng inee r ing www.s tqemagaz ine .com23

What can we learn from all this? First, as Brand pointsout, that none of us can really anticipate function very well.For all the many books on requirements engineering, thebest way to determine how a product should evolve—Pet-roski writes about zippers and forks—is to use it. Effective,lean requirements analysis practices are still very neces-sary, as long as developers realize that those analyses areinsufficient by themselves.

Second, iteration—building, trying, succeeding, fail-ing, rebuilding—governs successful product development,particularly as the competitive environment becomes moreextreme. “Good enough” requirements need to be followedby some form of usage (possibly utilizing a customer-drivenprototype), and then followed by evolutionary changes tothe requirements based on that usage.

Although a number of modern software developmentlifecycles have adopted an iterative approach, they stillmiss the mark in dealing with the messiness and unpre-dictability of complex (high-speed, high-change) environ-ments. While the cycles are iterative, the fundamental as-sumptions are still deterministic—they convey theimpression of short waterfall lifecycles strung together.

But as the world becomes increasingly dynamic—astechnological and business changes accelerate—static man-agement practices are overwhelmed. The old world was oneof optimization in which efficiency, predictability, and con-trol dominated. The new world is one of adaptation in whichchange, improvisation, and innovation rule. This dichoto-my—optimization versus adaptation—provides a distinctway of viewing the future of software project management.

We, the purveyors of the most momentous technologi-cal change period in the history of business, still don’t “getit.” Every publication—from ComputerWorld to BusinessWeek—trumpets to business leaders that “business will nev-er be the same.” Why then, do we insist that software devel-opment and management practices won’t undergo dramaticchanges also? We seem to accept the idea that everything ischanging to fit this 21st Century Internet world; everythingis changing, that is, except for you and me, and the wayswe’re comfortable doing what we do. Does that make sense?

In a Dilbert cartoon, Wally the co-worker bemoans thefact he has no impact on results, but he can take solace inhaving “process pride.” As Wally says, “Everything I do isstill pointless, but I’m very proud of the way I do it.” Maybeit’s time for a new outlook. It’s time for an era of results overprocess, understanding over documents, collaboration overcontrol, adaptation over optimization.

Adaptive Software Development (ASD) is one of agrowing number of alternatives to traditional, process-centric software management methods. ASD, Extreme Pro-gramming (XP), Lean Development, SCRUM, and CrystalLight methods—although different in many respects—aretied together by a focus on people, results, minimal meth-ods, and maximum collaboration. They are geared to thehigh speed and high change of today’s e-business projects.

Whether you’re managing testing, leading a develop-ment team, or running an entire project, it’s time to re-consider the values and assumptions that underlie theirmanagement. The practices of Adaptive Software Devel-opment are driven by a belief in continuous adaptation—adifferent philosophy and a different lifecycle, one gearedto accepting continuous change as the norm.

In ASD, the static Plan-Design-Build lifecycle is re-placed by a dynamic Speculate-Collaborate-Learn lifecycle(see Figure 1). This is a lifecycle dedicated to continuouslearning—and geared to constant change, re-evaluation,peering into an uncertain future, and intense collabora-tion among developers, testers, and customers. (Note thatit’s not always a simple circle; even in an iterativeprocess, one shouldn’t be adverse to diverging in order toexplore areas not considered before.)

ASD, rooted in an underlying conceptual base of com-plex adaptive systems theory, was designed for extreme pro-jects in which high-speed, high-change, and uncertaintyreign. Many, many projects are not extreme; but for thosethat are, ASD fits better than traditional softwaredevelopment approaches. (See the Webinfolink feature atthe end of this article for more information on adaptive sys-tems theory.)

A Change-Oriented LifecycleA typical project management cycle of Plan-Deliver-Review,based on an assumption of a relatively stable business envi-ronment, becomes overwhelmed by high change. The firststep in that cycle, planning, is one of the most difficult con-cepts for engineers and managers to examine thoughtfully.Raised on the science of reductionism (reducing everythingto its component parts) and the near-religious belief thatcareful planning—followed by rigorous engineering execu-tion—produces the desired results (we are in control), theidea that there is no way to “do it right the first time” re-mains foreign to many.

The word “plan,” when used in most organizations, in-dicates a reasonably high degree of certainty about the de-sired result. The implicit and explicit goal of “making aplan” restricts the project manager’s ability to steer the re-sults in innovative directions. While operating in this modeproduces the results you planned for, they may not be theresults you now need.

Speculation gives us more room to explore, to make

Learn

Sp

ecul

ate Collaborate

Or candiverge

Or candiverge

Or candiverge

FIGURE 1 The adaptive lifecycleAN

NIE

BIS

SE

TT



clear the realization that we are unsure, to allow us to devi-ate from plans without fear. It doesn’t mean that planningis obsolete, just that planning is acknowledgeably moretenuous than it was in the past. It means we have to keepdelivery cycles short and encourage iteration. Speculatingdoesn’t mean abandoning planning, it merely acknowl-edges the reality of uncertainty. Too often, deviations fromtraditional plans are considered mistakes to be correctedrather than opportunities for learning. Speculation recog-nizes the uncertain nature of complex problems, and en-courages exploration and experimentation. Speculating(difficult for my banking clients) allows us to admit that wedon’t know everything—and once we admit to ourselvesthat we are fallible, then learning (the third step in this cy-cle) becomes more likely.

The second conceptual component of an adaptive life-cycle is that of Collaboration. Complex applications arenot built; they evolve. Complex applications require a largevolume of information to be collected, analyzed, and ap-plied to the problem—a much larger volume than any indi-vidual can handle alone. “None of us is as smart as all ofus,” write Warren Bennis and Patricia Biederman in Orga-nizing Genius. While there is always room for improve-ment, most software engineers are reasonably proficient inanalysis, programming, testing, and similar skills. But tur-bulent environments are defined in part by high rates of in-formation flow and diverse knowledge requirements. Build-ing an e-commerce site requires greater diversity oftechnology, business skills, and knowledge than the typicalproject of five to ten years ago. In this high-information-flow environment, in which one person or small group can’tpossibly “know it all,” collaboration skills—working jointlyto produce results or make decisions—are paramount.

In his book No More Teams, Mastering the Dynam-ics of Creative Collaboration, author Michael Schragedefines collaboration as “an act of shared creation and/ordiscovery.” The issue, says Schrage, isn’t teams: it’s “whatkind of relationships organizations need to create andmaintain if they want to deliver unique value to their cus-tomers and clients.” Shared creation crosses traditionalproject team boundaries. It encompasses the developmentteam, customers, outside consultants, and vendors. Col-laboration then becomes the third key to building a moreadaptable project management lifecycle. Teams must col-laborate on technical problems and business require-ments. Teams need to improve their joint decision-makingability, and more decisions must be delegated to the teamlevel, because rapid change (and tight schedules) pre-cludes the traditional Command-Control style of decisionmaking.

That decision making depends on the third conceptualcomponent of this cycle: Learning. We have to test ourknowledge constantly—using practices like project retro-spectives and customer focus groups. Furthermore, thesereview practices should be done after each iterative cyclerather than waiting until the end of the project. The qualityof learning derived from practices like project retrospec-tives provides a key indicator about the true commitment tolearning in an organization, and, therefore, a key to itsadaptability.

Examining beliefs, assumptions, and mental modelscomes hard for many organizations. Learning about one-self—whether personally, at a project team level, or at anorganizational level—can be painful. Project postmortems,for example, are simple in concept, asking periodicallyabout what went right and what went wrong and what

Even as a child, John Sarkela saw thatthe “Plan-Deliver-Review” model

wasn’t always very realistic.“My father was a social worker,” he

recalls, “and I remember there being par-allels. Helping people build somethingworkable out of chaotic unpredictablecircumstances…in my father’s line ofwork it was all about helping peoplelearn and respond to cognitive disso-nance in their world models, and makeadaptive changes.”

In that sense, it wasn’t far off fromsoftware development. “It’s the sameprocess,” he points out, “no matterwhich discipline you’re in. You’re dealing

with constantly changing requirements,a shifting understanding of those re-quirements, and re-targeting your devel-opment efforts.” The project—be it a newdatabase application or a life in transi-tion—must accommodate that new in-formation, that new understanding.

Sarkela, chief technical officer forthe new metamedia publishing develop-ment company Fourth Estate, acknowl-edged long ago that software inven-tion—and life in general—is toounpredictable to work in a rigid textbookgrid.

“I’ve embraced adaptive softwaredevelopment processes pretty much

throughout my career,” he says. “I’ve hadto make compromises, depending onwhat projects and companies I’ve beenworking with, but the Speculate/Collab-orate/Learn model has been pretty fun-damental in my history as a developerand consultant.”

Speculating is necessary to set a di-rection, focus on a deliverable, and startmoving. And once you’re in motion, col-laboration is vital to deepening your ini-tial understanding of the product and theprocess. Keep in mind, says Sarkela, thatthese are not singular events; specula-tion and collaboration are recurring ac-tivities throughout the project.

Of Social Work and Software

PERSPECTIVE

24




changes need to be made in the future. Postmortems aredifficult for most organizations, however, because they candegenerate into blaming and politics—becoming vehiclesfor “who do we blame,” rather than “how do we learn.” Tobecome an adaptive, agile organization, one must first be-come a learning organization.

Characteristics of an AdaptiveLifecycleAn adaptive lifecycle has six basic characteristics: MissionFocused, Component Based, Iterative, Timeboxed, RiskDriven, and Change Tolerant.

For many e-business projects the final results may befuzzy in the beginning, but the overall mission thatguides the team is well articulated. Mission statementsact as guides that encourage exploration in the begin-ning, but narrow over the course of a project. A missionprovides boundaries rather than a fixed destination.Without a good mission and a constant mission refine-ment process, iterative lifecycles become oscillating life-cycles—back and forth with no progress. Mission arti-facts (there may be several types) not only providedirection, but are used in making critical project trade-offdecisions. Mission artifacts that don’t help make deci-sions are mere fluff.

The adaptive lifecycle focuses on results, not tasks;and the results are identified as application components.Component in this context defines a group of features (ordeliverables) that are to be developed during an iterativecycle. While documents (for example a data model) maybe defined as a deliverable component, they are alwayssecondary to a software feature that provides direct re-

sults to a customer. Iterative cycles emphasize “re-doing” as much as “do-

ing.” In manufacturing, quality programs try to drive out “re-work” as costly, the result of a broken process. But productdevelopment (software or other) varies considerably fromstamping out the exact same thingamabob on an assemblyline. Actually, the thingamabob was probably designed withan iterative process. Components normally evolve over sev-eral iterative cycles as customers provide feedback.

The practice of timeboxing, or setting fixed deliverytimes for iterative cycles and projects, has been abusedby many rapid application development (RAD) propo-nents because they use time deadlines incorrectly. Timedeadlines that are used to bludgeon staff into long hoursor cutting corners on quality are a form of tyranny; theyundermine the collaborative environment that adaptivedevelopment strives to achieve. It took several years ofmanaging RAD projects (I’m slow) before I realized thattimeboxing was minimally about time—it was really aboutfocusing and forcing hard tradeoff decisions. In an uncer-tain environment in which change rates are high, thereneeds to be a periodic forcing function to get somethingfinished. In addition, timeboxing forces a project teamand their customers to continuously re-evaluate the valid-ity of the project’s mission profile—scope, schedule, re-sources, and defects. Project teams that can’t—or won’t—juggle tradeoffs will never succeed in extremeenvironments.

As in Barry Boehm’s spiral development model, theplans for adaptive cycles are driven by analyzing the criticalrisks. Adaptive development is also change tolerant, view-ing the ability to incorporate change as a competitive advan-tage, not something to be summarily viewed as a “problem.”

“The goal is always—or shouldbe—to get some working code as soonas you can. Anything that stands in theway of that is a problem.” And analysisparalysis is often Problem Number One,says Sarkela. “The artificiality of the olddevelopment lifecycle methodologies,thinking that you could do a preliminaryninety-two-page analysis and therebyreally understand something, reallymakes paralysis inevitable in traditionalapproaches.” You end up with stacks ofpaper and no code, he warns, becauseyou’re afraid to move ahead without anironclad understanding of the problem.

You’ve got to have the courage to go

ahead, Sarkela stresses, in spite of thereal world’s uncertainties. “And you cando that only when you don’t have somuch invested in your code that if it’swrong you’re afraid to throw it out andstart over, if need be.” Sarkela likes tohave just enough spec to know what he’sbuilding, and what the user’s needs are.

Once that’s in hand, he collaborateswith the user to get something in place,using a “review-as-you-write” approach,with developers working in pairs. “Twopeople sharing ownership relieves someof the stress of being perfect,” Sarkelasays. “Giving up strict code ownershiptakes the ego out of the equation, and

means that anyone on the team can go inand fix code the minute defects arefound.”

All of that helps get code into users’hands faster, and helps open up thelearning process. “That may be the mostimportant part of this model,” saysSarkela. “You learn a lot faster, and a lotsmarter, with something tangible to ex-amine.” With this working code and earlyfeedback the hope is that—in softwaredevelopment, as in real life—subsequentiterations in our projects benefit from anever-deepening functional understand-ing.

—A. W.

Ju ly/Augus t 2000 Sof tware Tes t ing & Qua l i t y Eng inee r ing www.s tqemagaz ine .com25




The Basic Adaptive Lifecycle While the iterative “Speculate/Collaborate/Learn” cycle isuseful for outlining overall concepts, specifics are necessaryto actually deliver a software application. Figure 2 showsthe basic adaptive lifecycle and each of its components.

S P E C U L A T E :Initiation and Cycle PlanningThere are seven steps in adaptive cycle “speculating”:

1. Conduct the project initiation phase.

2. Determine the project timebox.

3. Determine the optimal number of cycles and the timeboxfor each.

4. Write an objective statement for each cycle.

5. Assign primary components to cycles.

6. Assign technology and support components to cycles.

7. Develop a project task list.

Project initiation is similar to that used in any com-petent project management approach. It involves settingthe project’s mission and objectives, understanding anddocumenting constraints, establishing the project organi-zation and key players, identifying and outlining require-ments, making initial size and scope estimates, and iden-tifying key project risks. Since speed is usually a majorconsideration in using an adaptive approach, much of theproject initiation data should be gathered in preliminaryJoint Application Development (JAD) sessions. For smallprojects, initiation can often be completed in a concen-trated weeklong effort. Larger projects may require a“Cycle 0” for more extensive initiation work. (Cycle 0 se-tups differ from other cycles that have to deliver a tangi-ble piece of an application to the customer; Cycle 0 in-volves preparatory deliverables but no pieces of the

application.)The second step is to set the timebox for the entire pro-

ject. This timebox should be based on the scope, feature setrequirements, estimates, and resources that result from pro-ject initiation work. Speculating doesn’t abandon estimat-ing; it just means accepting that any estimates are tenuous.

The third step is to decide on the number of cycles andassign a timebox to each one. For a small- to medium-sizedapplication (<5000 function points), cycles usually varyfrom four to eight weeks. Some projects may need two-week cycles, while others might require more than eightweeks (although this is rare). The overall project scheduleand the degree of uncertainty are two of the factors that de-termine individual cycle lengths.

After establishing the number of cycles and a schedulefor each, team members perform the fourth step: develop-ing a theme or objective for each of the cycles. Just as it isimportant to establish an overall project objective, each cy-cle should have its own theme. Cycle milestones are intend-ed to force product visibility, because without visibility theproduct’s defects and mistakes remain hidden. Without vis-ibility, learning suffers.

A Cycle delivers a demonstrable set of components to acustomer review process—it makes the product visible tothe customer. Within the cycles, Builds deliver workingcomponents to an integration process—they make the prod-uct visible to the development team. With this increased vis-ibility, testing is an ongoing, integral part of each develop-ment cycle—not some activity tacked on at the end.

The fifth and sixth steps assign components to cycles.The most important criteria for component assignment arethat every cycle must deliver a visible, tangible result to anend user. Assigning components to cycles is a multi-dimen-sional exercise. Factors in the decision include:

■ Making sure each cycle delivers something useful to the customer

■ Identifying and managing high-risk items early in the project

■ Scheduling components to accommodate natural dependencies

■ Balancing resource utilization

SPECULATE COLLABORATE LEARN

Projectinitiation

Adaptivecycle

planning

Concurrentcomponentengineering

Qualityreview

FinalQ/A andrelease

LEARNING LOOP

FIGURE 2 Adaptive lifecycle activities

AN

NIE

B

ISS

ET

T



Ju ly/Augus t 2000 Sof tware Tes t ing & Qua l i t y Eng inee r ing www.s tqemagaz ine .com27

A spreadsheet is often the most effective tool forcomponent-based cycle planning. (See Figure 3.) The firstcolumn contains all the identified components. There isalso a column for each cycle. As shown in the figure, asdecisions are made on the scheduling of each component,a team member checks the cycle column. Experience hasshown that this type of planning—done as a team ratherthan performed exclusively by the project manager—pro-vides better understanding of the project than a tradition-al task-based approach. Component-based planning re-flects the uniqueness of each project. While there may be,and should be, “best practices” for activities such asanalysis, object modeling, or design, what makes these ac-tivities unique to a project are the components to be deliv-ered to the customer.

Finally, for those who may be uncomfortable withouta task list, each component can become the target of atask: Develop component A. Additional tasks, not directlyrelated to components but necessary for project comple-tion, can also be added. There may be certain tasks addedto the project plan in addition to the components, but thebulk of the plan is a “component breakdown structure,”rather than a “work breakdown structure.”

C O L L A B O R A T E :Concurrent Component EngineeringConcurrent component engineering delivers the workingcomponents. Managers are more concerned about collabo-ration and dealing with concurrency than about the detailsof designing, testing, and coding. As mentioned earlier, formany projects today—involving distributed teams, varyingalliance partners, and broad-based knowledge—how peo-ple interact and how they manage interdependencies arecritical issues. For smaller projects, especially those inwhich team members work in physical proximity, concur-rency can be handled informally.Dependencies can be handled byhallway chats and whiteboardscribbling. In larger projects, how-ever, managing concurrency re-quires an advanced adaptive life-cycle whose description is beyondthe scope of this article.

For small single-site teams,collaborative development can beenhanced by practices promotedby Extreme Programming. Pairprogramming, for example, en-courages two people to work close-ly together: each drives the other alittle harder to excel.

Collective ownership, anotherExtreme Programming practice,provides another level to the col-laboration begun by pair program-ming. This approach, in which any-one on the team can change thecode, encourages the entire teamto work more closely together.Everyone—each individual, eachpair—strives a little harder to pro-

duce high-quality designs, code, and test cases. Relationships are the new bottom line in business, as

Roger Lewin and Birute Regine write in their new book TheSoul at Work: Embracing Complexity Science for Busi-ness Success. Relationships are important, they point out,“not simply for humanistic reasons, but as a way to pro-mote adaptability and business success.” Building alliancesacross organizations, collaborative problem solving and de-cision making, and sharing tacit knowledge are replacingrigor, control, and process as the building-block skills re-quired to deliver successful projects.

L E A R N :Quality ReviewThe basic adaptive management approach is to maintain afocus on the project scope and objective, assign compo-nents to the delivery team, stand back and let the team fig-ure out how to deliver the components, and maintain ac-countability through quality reviews. Quality evolves—notfrom micromanaging the process, but from establishing ap-propriate exit criteria and review practices. These feedbackpractices are key to learning.

There are four general categories of things to learn atthe end of each development cycle:

■ Result quality from the customer’s perspective

■ Result quality from a technical perspective

■ The functioning of the delivery team and the practices they are utilizing

■ The project’s status

Providing visibility and feedback from the customers isthe first priority in most projects. One vehicle for this is a

C I C 2 C 3 C 4

Cycle Delivery Dates 1-Jun 1-Jul 1-Aug 1-Sep

Primary Features

Order Entry XOrder Pricing XWarehouse Picking XPartial Order Ship XCalculate Reorders XSystem Interfaces XPricing Error Handling XSecurity & Control X

Technology Components

Install Visual Basic XInstall Comm Lines X

Support Components

Client/Server Arch XDevelop Conversion Pln X XHigh-Level Data Model X

FIGURE 3 A sample Component Cycle Plan




customer focus group. Derived from the concept of market-ing focus groups, these group sessions are designed to ex-plore a working model of the application and record cus-tomer change requests. They are facilitated sessions,similar to JAD sessions, but rather than generating require-ments or defining project plans, customer focus groups aredesigned to review the application itself. In the end, cus-tomers relate best to a working application, not documentsor diagrams. Where prototyping sessions involve individu-als or small groups in helping to define an application, fo-cus groups are more formal cycle milestones.

A second key to delivering quality products is review-ing technical quality. A standard vehicle for technical quali-ty assessment is the technical review. A design review mightoccur at the end of a cycle, whereas code reviews or testplan reviews might occur during the cycle. The focus of re-views should be to learn—not to find fault.

The third feedback process is to monitor the team’sperformance. This might be called the people-and-processreview. Project postmortems and end-of-cycle mini-post-mortems are needed.

There are four basic postmortem questions:

■ What’s working?

■ What’s not working?

■ What do we need to do more of?

■ What do we need to do less of?

Postmortems tell more about an organization’s abilityto learn than nearly any other practice. Good postmortemsforce us to learn about ourselves and how we work.

The fourth category of review is not strictly related toquality, but is instead a review of project status. This reviewleads directly into a re-planning effort at the beginning ofeach subsequent cycle.

The basic questions are:

■ Where is the project?

■ Where is it versus our plans?

■ Where should it be?

Determining a project’s status is different in a com-ponent-based approach. In a waterfall lifecycle, complet-ed deliverables mark the end of each major phase (a com-plete requirements document, for example, marks the endof the specification phase). In a component-based ap-proach, rather than having a single completed documentor other deliverable, the status often reflects multiplecomponents in a variety of states of completion.

Recognize that not everyone will feel comfortable withthis method. Many managers experienced in traditional ap-proaches, for example, may feel a distinct loss of controland influence. Their “gut feelings” about progress have tobe re-initialized.

The last of the status questions is particularly important:Where “should” the project be? Since the plans are under-

stood to be speculative, measurement against them is insuffi-cient to establish progress. The project team and sponsorsneed to continually ask, “What have we learned so far, anddoes it change our perspective on where we need to be?”

Toward the FutureOptimizing cultures believe in efficiency, control, andprocess rigor. But the Internet era has altered the fundamen-tal premise on which these beliefs depend: predictability. Noone would labor under the delusion that the results of atwelve-month e-commerce project (why one would be thislong is another issue) could be predicted with any degree ofaccuracy—there are too many variables, changing too fast.

Optimizing cultures tend to see the world as black orwhite. Adaptive cultures, on the other hand, recognize gray.They understand that planning is tenuous and control nearlyimpossible. Adaptive cultures understand that successevolves from a succession of trying different alternatives,and learning from both success and failure. Adaptive culturesunderstand that learning about what we don’t know is oftenas important as doing things we already know how to do.

Not every project is a complex one. In fact, in many orga-nizations complex projects may be less than twenty percent ofthe total (but a very critical twenty percent). Solving thosecomplex software development and testing problems does notmean abandoning good software management and engineer-ing practices, but it does mean adopting a new perspective ontheir use. It means understanding that software developmentis not a mechanical process, but an organic, non-linear,non-deterministic one. It means altering some basic princi-ples of how organizations work to solve complex problems,and adopting new practices geared to those beliefs. Shiftingfrom an optimizing culture to an adaptive one means gearingup for the future, rather than lounging in the past. STQE

Jim Highsmith ([email protected]) is Presidentof Information Architects, Inc., author of Adaptive Soft-ware Development: A Collaborative Approach to ManagingComplex Systems, editor of E-business Application Delivery,and helps IT organizations and software companiesadapt to the accelerated pace of development.



agile dinosaurs

Documents