Page 72 - DCAP405_SOFTWARE_ENGINEERING
P. 72

Unit 5: An Agile View of Process




          Agile projects are not controlled by conformance to plan but by conformance to business value.  Notes
          “The major problem with planning,” say Shona Brown and Kathleen Eisenhardt (1998), “is that
          plans are virtually always wrong.” If we accept the notion of constant change and turbulence,
          then plans are still useful as guides, but not as control mechanisms. In high-change environments,
          plans—and the traditional contracts that are derived from plans—are worse than useless as
          control mechanisms because they tend to punish correct actions. If we deliver a working software
          product, with features our customers accept, at a high level of quality, within acceptable cost
          constraints, during the specified time-box, then we have delivered business value. Developers
          don’t get to say, “This is valuable.” Customers do. Every three to six weeks, customers tell
          developers that acceptable business value has been delivered—or not. If it hasn’t, the project is
          cancelled or corrective action is taken. If it has, the project continues for another iterative cycle.

          We may look at the plan and say, “Well, because we learned this and this and this during the
          iteration, we only got 23 of the 28 planned features done.” That is useful information for planning
          our next iteration, but not for control. When we started the project three months ago, we only
          planned 18 features for this last cycle, and half the features we did deliver were different than the
          ones in the original plan. We accept that talented people, who are internally motivated, who
          must work in a volatile environment, who understand the product vision, will do the best they
          can do. If they don’t conform to the plan, the plan was wrong. If they delivered business value,
          then whether the plan was “right” or not is immaterial.


               !
             Caution  If they conformed to the plan and the customers aren’t happy with the delivered
             business value, it doesn’t matter that they conformed to the plan.

          An entire generation of project managers has been taught, by leading project management
          authorities, to succeed at project management by conforming to carefully laid-out, detailed task
          plans. Conformance to plan means locking ourselves into a outdated, often irrelevant plan that
          some project manager cooked up in great haste (which, of course, precluded talking to developers)
          18 months ago when the world was different. Conformance to plan may get a project manager
          brownie points with the tightly wound project management authorities, but it won’t deliver
          business value in volatile, high-speed environments.

          An exploration perspective contrasts with that of optimization. Take, for example, the use of
          schedule deadlines. While a schedule may appear to be a schedule, each perspective utilizes
          dates as a control mechanism in different ways. Optimization cultures use dates to predict and
          control—they view schedule as achievable, along with the other objectives, and see deviations
          from the plan as poor performance. Exploration cultures, however, view dates much differently.
          They basically see dates as a vehicle for managing uncertainty and thereby helping to make
          necessary scope, schedule, and cost tradeoffs. Exploration cultures, to be sure, use dates as
          performance targets, but the primary focus is bounding the uncertainty, not predicting dates.

          Balancing Flexibility and Structure

          It would be very easy to either “plan everything” or “plan nothing,” but the really interesting
          question is how to juggle the two, how to define the context narrowly enough to get something
          meaningful done, but not so narrowly that we fail to learn and adapt as we go along. The
          fundamental issue remains one’s primary perspective: to anticipate or to depend on resilience
          and responsiveness. Aaron Wildavsky, a social scientist, writes about this issue and offers an
          example of the difference between Silicon Valley and Boston. Basically, he believes, the reason
          Silicon Valley is the primary technology center of the world is that it depends on its resilience
          to be able to respond to rapid change, whereas the Boston crowd leans more heavily toward




                                           LOVELY PROFESSIONAL UNIVERSITY                                   65
   67   68   69   70   71   72   73   74   75   76   77