Click here for info on PMP Salaries in 2013

Hello and welcome to the final part of the agile project management (APM) series, in which we conclude by analyzing the various methods used to manage projects in an agile manner. These methodologies all adhere to the Agile Manifesto first mentioned in Part I, which focuses on people, communications, the product, and flexibility. They include the likes of extreme programming and scrum, which will both be covered in this final part of the series. So far we have covered the principles of APM and the various phases of APM. This article therefore follows logically by bringing the principles and phases together in a more applicable manner, in the form of the methods mentioned earlier.

Extreme Programming (XP)

Extreme programming is a type of software and one of several agile methods, also known as “XP.” It originated from software developer Kent Beck, based on his years of practice as an object-oriented software developer. It has emerged as a methodology (repeatable process for developing software) for programming and is based on trial-and-error programming. Therefore, without necessary testing and refactoring, it cannot be used. You may be asking, Why not design the program first before testing? This is simply because the method is based on an incremental process, as has been described in previous parts of the series, to be a fundamental aspect of APM. XP is known to be visible and accountable, with developers making concrete commitments about what they will accomplish, displaying progress in the form of deployable software, and, when a milestone is reached, describing exactly what they did and how they dealt with unforeseen circumstances.

So Why Is It Labeled “Extreme”?

By “extreme,” we refer to the high intensity with which the core practices of extreme programming are utilized. Extreme programming ignores any practice that falls outside its jurisdiction of core practices, resulting in stable and sedate projects. There are 12 core practices widely agreed on by agile specialists, which are grouped into four distinct areas derived from the best practices of social engineering. They are:

Fine-Scale Feedback

  • Pair Programming: Consists of one core programmer whose job is to focus on the actual coding of the project in great detail, while the other programmer focuses on the wider picture, ensuring that the code produced by the first programmer is without error. The two are able to exchange roles every few hours, promoting collective ownership and collaboration.
  • Planning Game: This is the main planning process within XP, and consists of both release and iteration planning. Release planning is used to determine what is released in the short term and includes the input of both customers (shortlist requirements) and developers (commit to requirements). On the other hand, iteration planning takes place without the involvement of the customer. It is used solely to plan the tasks and activities of the developers.
  • Whole Team: In XP, every contributor to the project is a significant part of the entire team. The team revolves around the “customer,” who sits with the team and works with them daily. For example, a team developing a financial administration system should include a financial administrator. The customer in this context does not pay the bills, but sits and works with the team daily.
  • Development Tests: Tests are conducted to test the functionality of pieces of code. Tests are written before the code is coded, in order for the programmer to stimulate conditions where the code may fail and act as a pre-emptive exercise.
Continuous Process

This area encompasses three core practices (continuous integration, design improvement, and small releases).

  • Continuous Integration: The development team ensures that any updates made by individual developers are uploaded to a central code repository to prevent delays and ensure that everyone is working on the most updated project.
  • Design Improvement: This simply refers to maintenance of code.
  • Small Releases: The delivery of software is done via frequent releases of functionality to create great value. The small but regular releases enable the customer to gain confidence in the project.

Shared Understanding

  • Coding Standard: XP teams follow a common coding standard, so that all the code in the system resembles the work written by a single and competent individual. The specifics of the code are not important; what is important is that all the code should look familiar, in support of collective ownership.
  • Collective Ownership: XP avoids the problem of team members working blindly on products they may not understand. The problem is avoided through programmer tests to capture mistakes and pair programming with an expert when working with unfamiliar code. This practice helps to spread knowledge throughout the team.
  • Simple Design: Refactoring should be used to make complex code simpler.
  • System Metaphor: This is a naming concept for methods that make it easy for a team member to guess the functionality of a particular method, from its name alone. For example, a bank system may create “loan records,” and if the customer were to go into overdraft it may perform a “make overdraft” operation. For each operation, the functionality is clear to the entire team.

We can conclude from the various core practices of XP that extreme programming is a discipline of software development based on the values of courage (to be decisive), simplicity, communication, and feedback. It works by bringing the whole team together in the presence of simple practices, with enough feedback to enable the team to see where they are and to tune the practices to their unique situation.

Fig 1: Core Values of XP

Now that we have gained an insight into one method of agile project management, we turn our attention to another method, known as “scrum.”

Scrum

Scrum is an agile methodology that can be applied to nearly any project; however, the scrum methodology is most commonly used in software development. It is most suited to projects that are changing rapidly or that have highly emergent requirements. Scrum software development progresses via a series of iterations called sprints, which last from one to four weeks. The scrum model begins with a brief planning meeting and concludes with a review. In scrum development, a sprint-planning meeting is described in terms of the desired outcome (a commitment to the features that are to be developed in the next sprint) instead of any entry criteria, task definitions, validation criteria, exit criteria, etc.), as would be the case with other methodologies. Also, scrum teams are supported by two specific roles. First is a scrum master whose responsibility is to help team members use the scrum process to perform to the highest level. The second role is the product owner, who represents the business, customers, or users, and guides the team towards building the right product.

So What Exactly Is Involved in a Scrum Development Project?

The methodology suggests a planning meeting at the start of the sprint, in which team members decide how many tasks they can commit to and then create a sprint backlog, which is basically a list of the tasks to perform during the sprint. During the agile scrum sprint, the scrum takes a small set of features from idea to coded and tested functionality. At the end, these features are completed, meaning coded, tested, and integrated into the evolving product or system. Finally, at the end of the sprint, the team should conduct a sprint review, during which the team demonstrates the new functionality to the product owner. The meeting should be no more than 15 minutes and, during that time, members share what they worked on the prior day and what they will work on that day, and they identify any impediments to progress. Thus, the scrum model views daily scrums as a way to synchronize the work of team members as they discuss the work of the sprint. The diagram below illustrates a sprint iteration within a scrum project.

Fig 2: Sprint Iteration (Agile Development Software with Scrum by Shwaber et al.)

As can be seen from the diagram, the team must first agree upon the diagram backlog tasks. Within the 30 days it takes to complete a sprint, there are daily scrum meetings in which feedback is communicated and tasks altered before finally delivering a potentially shippable product.

Now that we know what scrum development is, it’s also of benefit to understand the key differences between scrum and extreme programming.

Key Differences between Scrum and Extreme Programming (XP)

  1. Scrum teams will usually work in iterations (called sprints) that are from two weeks to one month long. XP teams typically work in iterations that are much shorter, at one to two weeks.
  2. Scrum teams do not allow changes into their sprints, unlike XP teams, who are more amenable to change within their iterations. With scrum, once the sprint-planning meeting is completed and a commitment is made to deliver a set of product items, those sets of items remain unchanged through the end of the sprint, whereas with XP, as long as the team hasn’t started working on a particular feature, a new feature of equal size can then be swapped into the XP team’s iteration in exchange for the other feature.
  3. Extreme programming teams work in a strict priority order dictated to them by the customer. Features to be developed are prioritized by the customer and the team is required to work on them in that order. In contrast, scrum teams determine the sequence in which they will develop the backlog items (usually arranged by highest priority).
  4. Scrum does not prescribe any engineering practices unlike XP, which advocates things like pair programming, and simple design. This may be confusing to teams because, on one hand, you’re trusting them and, on the other hand, you’re forcing them to adhere to certain core practices.

In conclusion, both methodologies clearly demonstrate the importance of collaboration, flexibility in their respective forms, and feedback that are the cornerstones of agile project management development. It is clear that the core values and principles laid out in the Agile Project Manifesto provide effective method variations for project teams to make use of. Thus, regardless of which methodology a project manager decides to use within his or her team. He can be guaranteed effective results with minimal wastage in time and resources.

I hope you have enjoyed learning about the agile management process, and I look forward to writing further articles about the project management world.