Loading ...
Sorry, an error occurred while loading the content.

XP and Adaptive Software Development (long)

Expand Messages
  • Jeff McKenna
    To my mind, the recent discussions in this forum on scaling and essence can be approached in a different way. For these questions I would highly recommend
    Message 1 of 1 , Dec 1, 2000
    • 0 Attachment
      To my mind, the recent discussions in this forum on scaling and
      'essence' can be approached in a different way.

      For these questions I would highly recommend "Adaptive Software
      Development" by James Highsmith. His work, with antecedents in RAD,
      takes work in complex adaptive systems (CAS) and applies it to
      software development. Of particular concern is the nurturing of
      emergent behavior. Emergent behavior is 'unexplained' behavior that
      emerges from the interactions of independent agents operating under
      simple rules. It often can be good. The key to nuturing emergent
      behavior in an organization is to keep the organization at the 'edge
      of chaos'.

      The ASD approach yields a set of very interesting answers to old
      management questions. Where do I put the control? Where do I allow
      freedom? The approach is summarized as: (1) controlling the part that
      should not change (e.g. the build process); and (2) not controlling
      the part that profits from the emergent behavior (e.g. the design).
      In the book Jim makes some specific recommendations on how these lines
      should be drawn and he makes some interesting points on scaling

      My view of XP is that it is an instance of his Adaptive Software
      Development Model. Based on his talk at OOPSLA I suspect that he
      agrees. Some other instances are RAD, Sutherland's Scrum and Coad's
      Feature Driven Development.

      XP suggests a lot of rigor in interesting areas: code review, testing,
      builds, work hours, standards, customer involvment. XP suggests very
      little rigor in seating, requirements and especially design. From the
      ASD point of view this suggests that emergent behavior, embodying new
      ideas and practices, is more likely to occur in the areas of design
      and requirements. XP agrees with this assessment and considers it
      desirable. XP suggests that lots of variation in code reviews
      (quality), testing (quality), builds (scheduling), work hours (worker
      satisfaction), etc. are not desirable and applies rigor to these

      Back to the original questions:

      XP SCALE: With modern OO practice, reasonable partitioning of
      problems into smaller teams is essentially always feasible. ASD then
      suggests that if the boundaries are not very rigorous, then chaos
      rules. Hence a need to apply more rigor to the boundaries, often the
      APIs. Usually this means more formality, more ceremony (hopefully not
      content and context free).

      For even smallish project that I have worked on this partitioning
      occurs. And I have discovered, the hard way I might add, that even
      these small partitionings have needed different operational practices,
      different degrees of rigor in different areas. As things get bigger,
      I would expect more variation in theses practices. A group working on
      persistance could easily have a different idea of fast builds than the
      web page designers.

      XP is a development practice developed by developers, not a project
      management practice. As someone else said, passing the values of
      communication, simplicity, courage and feedback on to the project
      management makes sense, but that is not a point that only XP makes.
      Asking XP to take on the project management function is out of scope.
      I might suggest that the Customer (us in this case) has not asked for

      XP ESSENCE: Since I view XP and an instance of ASD, then I want the
      essential items to be those that keep the characteristic of adaptive
      behavior. To me this means being able to quickly change. Interesting
      enough I see all of the practices with the exception of Metaphor as
      very important. (BTW, Metaphor as a communication aid is also
      important but the role it plays can be done, IMHO, with any commonly
      understood, high level 'model'. If a good Metaphor can be found, this
      job is easier.)

      Each practice of XP is up for discussion and improvement. Each
      organization has objectives, context, people and history that will
      impact if and how each practice could be implemented. This is not any
      different than any other 'formalized' practice. Perhaps this getting
      started activity can be the first phase: adoption. The begins the
      next stage: adaption. I suggest ASD as a way to think of what
      practices to adopt first and how to adapt them for your organization.

      Jeff McKenna
    Your message has been successfully submitted and would be delivered to recipients shortly.