Methodology, Pre Sales, Software Services

Extreme Programming

Similar to Scrum, XP (Extreme Programming) starts the process by creating a backlog of work to perform during a sprint/iteration. XP creates the backlog by working with customers and creating user stories. In parallel with this work, the team performs an architectural spike, during which they experiment with the features to envision the initial architecture. XP classifies this work as the exploration phase.

The planning phase follows exploration. This phase focuses on identifying the most critical user stories and estimating when they can be implemented. Tasks are defined for each feature, to aid with estimating complexity. The team outlines an overall release schedule, with an understanding that a high level of uncertainty exists until the work begins. A release will have one to many iterations, which are typically 2- to 4- week construction windows.

When an iteration begins, the specific plan for the iteration is revisited. The team adds any new user stories and tasks that have been discovered since the overall release was outlined.

XP integrates customer testing into the development iteration. The customer is asked to identify the acceptance tests, and the team works to automate these tests so they can be run throughout the iteration.

The planning phase is followed by the productionizing phase, during which the code is certified for release. Certified means the code passes all customer tests plus nonfunctional requirements such as load testing, service-level requirements, and response time requirements. You can see an overview of XP in below figure.


Some of the characteristics of XP are as follows:

  • Specific practice —Unlike Scrum, XP is specific about the practices that should be used during a software project. These practices include pair programming, TDD, continuous integration, refactoring, and collective code ownership.
  • Modeling —XP teams frequently use modeling to better understand the tasks and architecture needed to support a user story.
  • Simplicity —Teams perform the minimum work needed to meet requirements.
  • Automation —Unit and functional tests are automated.
  • Quality through testing —Features are tested constantly, and developers check each other’s code via pair programming.

These are some of XP’s strengths:

  • Customer-focused (it’s all about user stories)
  • Quality via frequent testing
  • Constant focus on identifying and delivering the critical user stories
  • High visibility on project status
  • Great support for volatile requirements

It also has weaknesses:

  • Need for team maturity —Practices such as pair programming and TDD require responsible developers, and they aren’t always easy to obtain.
  • Dependency on testing —If developers know that significant testing will take place downstream, they may be less than diligent when they’re creating designs.
  • Scalability —XP may not work well for large projects.
  • Dependency on team member co-location —The team usually has a team room.

XP supports many of the critical goals of an agile process, such as dealing with volatile requirements and delivering prioritized, working software as soon as possible. XP also supports the principle of just enough, keeping with the lean philosophy of minimizing waste.

XP has sometimes been criticized for its lack of formality in system documentation and system design. In recent years this has changed, and XP teams now create the documentation needed to support a project’s customers.

Methodology, Software Services

Scrum Methodology

The Scrum process begins by reviewing a product backlog with the product owner. You identify the highest-priority features and then estimate how many will fit into a sprint. These features then compose the sprint backlog. A sprint is a predefined period of time, usually 2 to 4 weeks, during which the team analyzes, designs, constructs, tests, and documents the selected features.

The team holds a daily status meeting, referred to as the daily Scrum, to review feature status. Individual team members answer these three questions:

  • What have you accomplished since our last meeting?
  • What will you work on today?
  • Are you encountering any impediments or roadblocks in completing your work?

When a sprint is completed, the features are demonstrated to the customer, and the team and the customer decide whether additional work is needed or if the sprint work is approved to be released to a beta or production environment. Each sprint is followed by a retrospective during which the team lists items that went well or poorly; action plans are documented to keep the successes going and to improve the areas that performed poorly. Continue reading

Methodology, Software Services

The 12 Principles of Agile Methods

  1. Highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity — the art of maximizing the amount of work not done — is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

For more information about the 12 Principles of Agile Methods, please visit