2

Agile Concepts

As discussed in Chapter 1, agile project management is an iterative, adaptable, and collaborative method used to manage the software development process. This chapter examines agile concepts in greater detail. First and foremost, this chapter starts with a discussion of the Agile Manifesto, which is used as the foundation for implementing the agile project. The Agile Manifesto consists of two components: values and guiding principles. Figure 2.1 represents an illustration of the Agile Manifesto.

AGILE VALUES

Agile values represent those items that are valued more than others. Other values refer to those typically used in traditional project management. The reader is again reminded that the agile framework is compared to traditional project management throughout this book. This is done for clarification purposes and because traditional project management was in place long before the Agile Manifesto came about in 2001. A discussion of the four agile values follows.

(a) Individuals and interactions over processes and tools. This value statement means that individuals (people) and their interactions have greater value than do processes and tools. Traditional project management places greater emphasis on the utilization of processes and tools. The understanding that needs to be taken from this particular value is that people and the interactions between people are more important than processes and tools. The logic behind this value is that people take on the project (not processes and tools). People do the work and therefore are more valuable.

FIGURE 2.1
The Agile Manifesto.

(b) Working software over comprehensive documentation. This value statement simply means that working software is more valuable than comprehensive documentation. The Agile Manifesto places greater value on working software because this is what the customer values most. In addition, working software is the main reason that the project has been undertaken. Documentation has its usefulness, however, it has very little value when compared to working software. The customer is paying for software that works and comprehensive documentation is merely a bonus and has little or no value by itself.

(c) Customer collaboration over contract negotiation. This value simply implies that collaborating with the customer is more valuable than contract negotiations. Why is this so? This value is based on being flexible as opposed to being rigid and unwavering based on a contract. Traditional project management defines the project scope up front and at times this can be very time consuming and costly to modify. The agile framework supports the changing nature of software requirements, technology, and even the end client. The contracting process on an agile project has to remain more adaptable in comparison with that of traditional project management. There is no formal change management component on the agile project when compared to the traditional project. If a requested change adds value to the project, it is more than likely to be accepted. Negotiating contract changes with the client goes out the door and collaborating with the client to add value to the product is acceptable because it has greater value.

(d) Responding to change over following a plan. This value statement implies that it is more valuable to respond to change rather than to follow a plan. With traditional project management and as a result of changes, it can take considerable time to bring the project back into alliance with the project plan. With agile project management, it is more valuable to respond to project changes rather than adhere to a plan. The agile agenda welcomes and expects project changes. It takes more time to document and approve changes with traditional project management. Although planning on an agile project is minimal, the most valuable actions to take are to respond to change. This is more flexible and faster to do as opposed to following a plan and making changes.

TABLE 2.1
Agile Value Statements

We have covered the four agile values and it is time to recap the important concepts that have been discussed thus far. See Table 2.1 for a consolidated list of the four agile values.

Recap

The Agile Manifesto provides guidance on the agile project based on values that are the most important. As stated in the beginning of Chapter 1, these values are compared with traditional project management values because the author believes this will enhance understanding. Values that are less important on the agile project could possibly coexist with the more desirable values; however, in the case of a conflict, the agile project team must remember and focus on the agile values over the values associated with traditional project management.

AGILE GUIDING PRINCIPLES

As part of the Agile Manifesto and in addition to the four agile values, agile practitioners follow 12 guiding principles. These values and principles are important in gaining the correct understanding of agile project management. Following is a discussion of the agile guiding principles in greater detail.

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. The understanding to be gained from this principle is that first and foremost, the goal is to satisfy the customer. How will the customer be satisfied? By the continuous delivery of valuable software. What does valuable software really mean? It refers to software that is valued by the customer. In Chapter 9 of this book we provide a thorough understanding of the term “value” as it applies to agility. Notice the focus on the word value. It is a very important word and it represents the main focus of the agile framework. The understanding that must be obtained from this guiding principle is that the agile framework has a customer and a value-based focus.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. This guiding principle demonstrates the agile framework’s flexibility and adaptability when dealing with change. Traditional project management is generally managed around a change management process and is sometimes viewed as being costly and enabling scope creep (i.e., small changes in a plan or project that necessitate other changes which lead to still more changes, etc.). In contrast, the agile process is more accepting of changes at any time, even very late in development. There is no such thing as scope creep in the agile realm because changes are always accepted. If, however, the change does not add value, then there is the possibility that it won’t be included in the product. It is important to understand that the focus on the agile project is mainly about value-added changes. The logic behind the acceptance of change is based on several factors:

   • Changes are considered to be the norm on agile projects.

   • Flexibility and adaptability enable and support a customer’s competitive advantage by welcoming changes that add value at any time.

   • Accepting change is faster than approving or denying changes. Remember that agility is all about speed! Once again, readers need to understand that only those changes that “add value” are candidates for inclusion into the product. The agile team must fully understand that they should limit change discussions and actions to value-added propositions only.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale. Early feedback is decidedly much better than proceeding on a project and getting feedback late. What is worse is that the project could end up heading in the wrong direction. Not only is going down the wrong path quite costly, it is also a great waste of time and effort. An iteration on agile projects should be between two weeks to one month, again with the preference always being the shorter time frame. Why do we want a shorter time frame? There are a couple of reasons:

   • Short delivery cycles result in regular feedback from the project stakeholders. This keeps the project from losing momentum by keeping everyone actively engaged. On a traditional project, slow feedback can result in a lack of engagement by the project team and has the potential to contribute to project delays.

   • Frequent delivery of working software is beneficial in that requirements can be quickly added or modified. Here again, speed is very relevant.

   • How do frequent small changes increase the amount of value-added for the customer? Small and frequent changes can minimize the likelihood that the customer will have the need to create a large number of change requests. This practice ensures that the project is satisfying the customer’s requirements on a regular and consistent basis.

   • The goal of the agile project is to deliver value throughout the project. Accepting changes is one practice that supports the goal of consistently adding value to the product.

4. Business people and developers must work together daily throughout the project. In order to deliver a project quickly, face-to-face interactions is the fastest way to communicate on agile projects. E-mails, phone calls, and documentation are considered to be less efficient and slower methods of communication. Daily face-to-face interactions between customers and developers enable a faster rate of transferring knowledge. This results in all project stakeholders being on the same page with no surprises. Product delivery on the agile project has a higher rate of success in meeting or exceeding customer expectations based on these interactions.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. Motivated and talented people make a big impact on an agile project. The successful delivery of the product depends on empowered team members. Agile methods are based on self-directed and self-organized teams who can be trusted to get the job done. There is no micromanagement on agile projects. The management style or lack thereof is based on team collaboration. This mind-set results in the project getting completed faster and effectively. The best team members on an agile project are those who can work with little supervision and are self-motivated.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Such conversations are the fastest way to communicate on agile projects. The flow of communication is more effective and efficient for face to face in comparison with other methods. Inquiries and inconsistencies can be addressed very quickly. This results in minimal delays and faster delivery of the product. Small team sizes make for ease in communicating face to face. In the case of larger project teams, face to face can be challenging, however, the method of communication can be tailored to meet the needs of the project.

7. Working software is the primary measure of progress. Progress on the agile project is determined by how well the software works. This is a results-based focus that cannot be easily disputed. Working software shows the customer results that can be approved and accepted. It also shows progress made toward the end goal of product delivery. When the software works, only then can it be approved by the customer as being completed.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Agile methods support the project team’s need to have a life outside of work. This means that the expectation for the team is to maintain a sustainable pace based on a typical 40-hour workweek. Long workdays are not looked upon favorably on agile projects. By working at a sustainable pace, the team can be more productive, which results in less project tension. The sustainable pace is a win–win situation for everyone involved in the project. This in turn is beneficial at the corporate level in that companies do not want overworked teams who are stressed out, burnt out, and unhappy.

9. Continuous attention to technical excellence and good design enhance agility. In order to deliver high value to the end client, it is often necessary for the development team to make changes to the design. This means that the design must be relatively easy to maintain. Technical excellence and a good design make for ease in understanding and making changes to the design. This in turn supports the ability to respond to change very quickly. A good product design and technical excellence enhance agile methods because continuous attention is given to the design of the software. The value of this guiding principle is having a design that is easily maintainable based on its technical excellence.

10. Simplicity—the art of maximizing the amount of work not done—is essential. The author believes that this guiding principle is the trickiest one to understand. At face value, the principle talks about work not done. The question then becomes: “Why is there a concern about work not done?” From the agile perspective, work not done is more reliable because there is nothing that could go wrong with it. The development team does not code work that is not done so it’s perfect because it has not been touched. It is believed that over 60% of software features are included in a product but are rarely if ever used.^* This is the reason why agile methods focus on simplicity. By focusing only on the necessary components of the product, there is less risk. Too much complexity increases project risk. The takeaway of this guiding principle is that simplicity is better than complexity. The development team should only build what is required by the customer. Gold plating (the incorporation of costly and unnecessary features or refinements into a product) is a big no-no. By focusing on simplicity, this in turn speeds up the actual delivery of the product.

11. The best architectures, requirements, and design emerge from self-organizing teams. According to agile methods, when people are given the chance to self-manage themselves, they produce better work. This includes the best architectures, requirements, and designs. The best work is developed by those who are the originators of the work. Why is this so? Self-managing teams with the ability to make their own decisions take pride in ownership of their work. One reason for this is because these teams are free to work in the manner that suits them without unnecessary interference from others such as the customer and the business people. These teams don’t have to sell their ideas to others and this saves a considerable amount of time. Simply put, the agile team is responsible for the outcome of the product and they are the best ones to have the freedom to create it. For clarity, readers need to understand that we are speaking of the development team. This is not inclusive of the customer or the business side of the project.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. This guiding principle is simply about lessons learned and when they occur on the agile project. Agile methods support the idea that it is best not to wait until the end of a project to address lessons learned. Lessons learned need to be captured and addressed during the project. For example, in the case of Scrum, lessons learned should be addressed at the end of each Sprint (iteration). Agile methods capture lessons learned as the project ensues rather than at the end of the project. The agile project team then tunes and adjusts its behavior for subsequent iterations. This gives the project team a chance to act on the lessons learned rather than just discussing the actions and hoping for a chance to apply the lessons on future projects.

DECLARATION OF INTERDEPENDENCE

The Declaration of Interdependence (DOI) was developed strictly for the project management side of the agile projects and it is not a part of the Agile Manifesto. As a matter of fact, the DOI was created in 2003, two years after the Agile Manifesto. There are six principles associated with the DOI. According to Griffiths (2012), the DOI is directed at project leadership and is not tested on the PMI-ACP exam.^* It is important to mention that the difference between the DOI and the Agile Manifesto is that the DOI is for the project management side of an agile project and the latter guides the entire agile project. Following is a discussion of the six principles associated with the DOI.

1. We increase return on investment by making the continuous flow of value our focus. This principle means that the agile project provides exactly what the business has asked for and nothing more. The logic behind this principle is that when results are provided that meet the needs of the business, then this makes a case for project continuation and approval. The continuous flow of value means that the project delivers the desired business results instead of simply delivering results that may be useless to the customer.

2. We deliver reliable results by engaging customers in frequent interactions and shared ownership. Not only is engaging the customer good business, it helps develop and build relationships. Frequent interactions with the customer support the delivery of a product that meets or exceeds expectations. When the customer is engaged and sharing ownership of the project, the results are undoubtedly reliable.

3. We expect uncertainty and manage for it through iterations, anticipation, and adaptation. Agile methods do not rely on plans to guide projects. Change is the expectation for agile methods and it is managed through iterations, anticipation, and adaptation. Software projects are known for constant changes and a good way to manage modifications is to develop software in iterations. The fact that agile methods are highly adaptable means that change is anticipated at any time during the project. The agile project adapts to change for value-added reasons and very little up-front planning is needed.

4. We unleash creativity and innovation by recognizing that individuals are the ultimate sources of value, and creating an environment where they can make a difference. Agile methods recognize the value of individuals on the team. The logic behind this principle is that each individual team member must be treated well; his or her needs should be satisfied and each should get the support needed to be successful on the agile project. In addition, the agile project environment should be the best possible one that can be provided.

5. We boost performance through group accountability for results and shared responsibility for team effectiveness. Shared responsibility for project success is the idea behind this principle. Self-managed teams are typically more satisfied and enthusiastic when working together to resolve issues. Team empowerment not only results in ownership of project glitches, it encourages team members to work very hard for resolutions. When the entire team shares the responsibility for project success, everyone on the team is a success.

6. We improve effectiveness and reliability through situational specific strategies, processes, and practices. It should be well understand that agile methods are flexible and projects are unique. This means that project conditions must be evaluated for the best solutions instead of attempting a one-size-fits-all approach. Based on what is available for the project, agile methods require adaptation for the best solution based on the environment and the circumstances that are present.

CHAPTER SUMMARY

The Agile Manifesto and the Declaration of Interdependence (DOI) represent the foundation for agile methods. There are several main ideas that need to be summarized:

• Agile methods support value-based delivery.

• People on agile projects work on self-directed and self-organized teams.

• Change is welcomed at all times.

• Agile methods are about speed.

• Agile methods support customer collaboration and frequent interactions.

• Agile methods support face-to-face time.

• People should be motivated on the agile project.

• The design should be kept simple and easy to change.

• Agile methods support adaptation on the fly.

• Adequate people skills (soft skills) are particularly important on agile projects.

• Agile methods are about simplicity.

• The software must work or there is no real progress.

• There is a sustainable pace; no long hours.

• Document lessons learned throughout the project; don’t wait until the end.