Agile method and Extreme Programming: Differences and Similarities

4 July, 2008

Agile method

Agile is a mindset, not a method

Saying we use an Agile method lacks precision. We should say that we use an Agile method such as Extreme Programming (XP), Scrum, or Agile Unified Process (AUP) for example.

Agile values

The Agile mindset promotes evolutionary changes throughout the SDLC. It does so by emphasizing:

  • Rapid development and delivery of small chunks of useable software
  • Quick integration of changes in requirements: changes have to be dealt with appropriately without having to go through the lengthy process of a change management board
  • Close collaboration between users, analysts, and programmers: they have to be available all the time at the same location and communicate face-to-face
  • Empowering team members: responsibility is based on trust, not on authority
  • Self-organizing teams: thanks to trust and close communication, team members can easily step up or down according to the issue at hand. There is no guru, and no fifth wheel.

Agile methods are lightweight software development processes

Although Agile methods rely on well-defined processes (change, risk, analysis, testing, etc.) and plans, they highlight that everything can be easily changed if the needs arise. In other words, the underlying processes are not edged in stone and can be adapted to the reality at any time.

The downsides of Agile methods

  • Even more than with non-Agile methods, the success of the project heavily depends on the motivation, know-how, team abilities, and common sense of team members. This is a direct result of empowering team members to make decisions that can deeply affect the project without going through “committees” and “boards”.
  • The success of Agile methods depends on its fit with the organizational culture.
  • Agile methods are often perceived as synonyms to cowboy-style, opening the door to excess of creativity. Although this is (generally) a misconception, it means that team members have to be (re-)educated concerning the Agile methods before starting the project.
  • Agile methods lack credibility for senior management. As a result, it may require strong negotiation power and increased risks for the project manager to use Agile methods for strategic projects. Most companies will only allow Agile methods for small exploratory projects at first. CIO magazine has a good real-world story about a CIO being converted to Agile.
  • Agile methods may not be appropriate for large-scale projects (this is an open topic).

Agile Unified Process

Agile Unified Process (AUP) is a simplified version of the IBM Rational Unified Process (RUP). It describes a simple, easy to understand approach to developing business application software using agile techniques and concepts yet still remaining true to the RUP. The AUP applies agile techniques including test driven design (TDD), Agile Modeling, agile change management, and database refactoring to improve productivity.

Unlike the RUP, the AUP only has seven disciplines:

1. Model. Understand the business of the organization, the problem domain being addressed by the project, and identify a viable solution to address the problem domain.

2. Implementation. Transform model(s) into executable code and perform a basic level of testing, in particular unit testing.

3. Test. Perform an objective evaluation to ensure quality. This includes finding defects, validating that the system works as designed, and verifying that the requirements are met.

4. Deployment. Plan for the delivery of the system and to execute the plan to make the system available to end users.

5. Configuration Management. Manage access to project artifacts. This includes not only tracking artifact versions over time but also controlling and managing changes to them.

6. Project Management. Direct the activities that takes place within the project. This includes managing risks, directing people (assigning tasks, tracking progress, etc.), and coordinating with people and systems outside the scope of the project to be sure that it is delivered on time and within budget.

7. Environment. Support the rest of the effort by ensuring that the proper process, guidance (standards and guidelines), and tools (hardware, software, etc.) are available for the team as needed.

Extreme Programming

Extreme Programming (or XP) is a software engineering methodology (and a form of agile software development) prescribing a set of daily stakeholder practices that embody and encourage particular XP values . Proponents believe that exercising these practices—traditional software engineering practices taken to so-called “extreme” levels—leads to a development process that is more responsive to customer needs (”agile”) than traditional methods, while creating software of better quality.

Proponents of Extreme programming and agile methodologies in general regard ongoing changes to requirements as a natural, inescapable and desirable aspect of software development projects; they believe that adaptability to changing requirements at any point during the project life is a more realistic and better approach than attempting to define all requirements at the beginning of a project and then expending effort to control changes to the requirements.

However, XP has been noted for several potential drawbacks, as compared to more document-based methodologies, including problems with unstable requirements, no documented compromises of user conflicts, and lack of an overall design spec or document.

XP values

Extreme Programming initially recognized four values in 1999. A new value was added in the second edition of Extreme Programming Explained. The five values are:

  • Communication
  • Simplicity
  • Feedback
  • Courage
  • Respect

Agile vs. XP: The Differences and Similarities

XP is a set of practices that conform to the values and principles of Agile. XP is a discrete method, whereas Agile is a classification. There are many Agile methods, XP is just one of them.

Having said that, none of the other Agile methods are as well defined, or as broad in scope as XP. Scrum, for example, is roughly equivalent to XP’s Planning game practice, with elements of Whole Team. While there are differences in the details, it is fair to say that Scrum is a subset of XP. Indeed, many Scrum teams augment their process by adding in many of the XP practices such as Acceptance Testing, Pair Programming, Continuous Integration, and especially Test Driven Development.

Of all the Agile methods, XP is the only method that provides deep and profound disciplines for the way developers do their daily work. Of those disciplines, Test Driven Development is the most revolutionary and impactful.

Stuff:

State of Agile Development” Survey (Released August 2007)

Agile Tools

References:

[wikipedia.org]

[http://brunocollet.com]

[http://www.xprogramming.com]

[http://www.objectmentor.com]


Bookmark and Share

Entry Filed under: Agile, Extreme Programming. Tags: , , .

1 Comment Add your own

  • 1. Pages tagged "agile"&hellip  |  4 July, 2008 at 1:20 pm

    [...] bookmarks tagged agile Agile method and Extreme Programming: Differences … saved by 1 others     NARUTOJ33K bookmarked on 07/04/08 | [...]

Leave a Comment

Required

Required, hidden

Some HTML allowed:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Trackback this post  |  Subscribe to the comments via RSS Feed


Elegance is not a dispensable 
luxury but a factor that decides
 between success and failure

Tags

Top Posts

Recent Posts

Recent Comments

Links

Feeds

Communities

Get the Source
OSGi supporter
JUG Milano

Upcoming Events