This chapter is from the book
This chapter is from the book
This chapter is from the book
Understanding Agility
A historic marker indicating that agile methods no longer would be considered mere hype or a fringe movement was Scott Adams’ Dilbert comic strip on agility.7 With every passing year, agile concepts have become more firmly entrenched in mainstream business and, today, are largely accepted in the modern market. Of course, while noting the movement of agile methods from the realm of fringe, Adams also exposes typical misunderstandings, ill-formed expectations, and downright strange interpretations that some think still pervade the agile approach.
Agility has come into its own as a value system defined by the Agile Manifesto.8 Based on twelve principles created to ensure the value system,9 the Agile Manifesto demonstrates that there is more to agile development than just one specific methodology, such as Extreme Programming10 or Scrum.11 The first value stated in the manifesto favors “individuals and interactions over processes and tools.” The processes referenced in this first value statement include agile development processes, which means teams must ensure that their development process supports their needs in the best way possible. Using the principles in the manifesto, teams can find guidance on how to modify and adjust their development processes to best support their needs.
Core Value Pair Statements
The values expressed in the Agile Manifesto apply to all agile projects, superceding guidelines of any specific agile process. The core of the manifesto compares in four statements two values and argues that although each value provides a value in general, the first value is more important than the second and that the latter half of the each statement is only valid if it supports the former.
- Value Pair Statement #1, “Individuals and interactions over processes and tools,” highlights the idea that it is always the people involved in a project and how they collaborate that determine a project’s success or failure. The manifesto does not devalue processes and tools (otherwise, we wouldn’t talk about processes, and the agile community wouldn’t have created tools such as unit-testing frameworks, integration and configuration management tools, and others), but if individuals don’t work together as a team, the best tools and processes won’t help the project succeed.
- Value Pair Statement #2, “Working software over comprehensive documentation,” is perhaps the most often misunderstood of the four statements. People unfamiliar with agile development may mistakenly believe agile projects don’t document, or even disdain documentation. Not so. In the same way that processes and tools play a major role in successful development, documentation also plays a major role. However, this value comparison expresses that working software is the critical success factor for any development effort. Documentation might be needed to support or to understand the working software, but it can’t and shouldn’t be an end in itself.
- Value Pair Statement #3, “Customer collaboration over contract negotiation,” emphasizes that although you need a contract, it can never be a substitute for a good relationship with your customer. In order to deliver a satisfactory product, involve customers regularly throughout the development process.
- Value Pair Statement #4, “Responding to change over following a plan,” advocates the importance of reacting to changes (especially in terms of requirements changes), rather than sticking to an inappropriate or obsolete plan. We accept that both the customer and the project team will learn over time, and we want to acknowledge this learning and incorporate it into the development effort. If the finished product delivers what the customer and we planned for before confronting changes and disregards anything we learned during development, the product will be a failure, even if it fulfills a contract.
The agile value system accommodates collocation as well as distributed software development. Later in this chapter, I examine implications of agile principles regarding globally distributed projects.
Systemic Approach
Agile development promotes a systemic approach that is supported by a closed-loop routine of planning, doing (or performing), inspecting (or analyzing), and adapting, as follows:
- In Planning, plan immediate activities (having broken down a development project into deliverable chunks, begin planning for the first task). This is most often short-term planning, focusing on the next iteration, but it can also be long term, such as planning the next release.
- In Doing, perform activities planned in the first step.
- In Inspecting, analyze the performance of the activities planned in the planning step. Did all work as planned? Was there a specific process that worked well and would be appropriate to repeat in the future? Did a specific process or plan fail or require adjustments for the future?
- In Adapting, determine what kinds of adjustments the previous inspection step revealed are needed in order to improve development. In this step, decide necessary actions for the following iteration.
The last step in this closed-loop routine provides input for the first step in the next round, and so on.
Risk Reduction
The goal of an agile project is not only to deliver a product at the end of the project’s lifetime (called a deadline), but as well to deliver early and regularly. In order to do so, we divide the project’s lifetime into development cycles. A bigger cycle that produces much functionality (sometimes called a feature pack) is called a release. Within that, we use a smaller cycle to organize work in smaller chunks, and to deliver smaller functionalities. This smaller cycle is called an iteration.12 Both a release and an iteration lead to a delivery or a potentially shippable product.
A tremendous advantage of agile development is risk reduction through high visibility and transparency. By developing iterations of a working system, receiving regular feedback from the customer and from tests, and with tangible progress, you have access to the actual status of the project. Knowing the actual status of the project in turn enables you to make decisions regarding further deliverables and necessary actions. For example, if you encounter that the system does not fully satisfy the customer and it can’t be turned in the right direction, you have the advantage of being able to stop the project early, before all the money has been spent.
The Productivity Myth
Another common, and misguided, argument is that following an agile approach will greatly increase a development team’s productivity compared to other approaches. While this can be true, it is not always necessarily so. Agile development guides a team to deliver a working system frequently—“frequently” meaning in iterations lasting one to four weeks. A “working system,” on the other hand, is defined by the customer’s evaluation of usability. Thus, by providing a working, usable system periodically, say, every two weeks, an agile team ensures maximum business value for its customer.
Therefore, following this approach, your customer might decide to proceed with an operational system earlier. This will give your customer a market advantage. However, it does not necessarily mean that the project as a whole is finished—meaning all required features are implemented—earlier.
More Than Practices
Agility is more than a collection of practices. Every so often, I hear people mixing up specific practices with agility. Practices—for example, Extreme Programming’s pair programming or test-driven development—are a great means to preserve the agile value system; however, these practices are not the value system itself. For instance, you can successfully apply pair programming and use a linear (or waterfall) development approach.
Neither Chaotic nor Undisciplined
Many people consider the agile approach to be an undisciplined approach. Some regard agile as an ad-hoc approach that doesn’t require any planning, one in which people act independently according to whim. Sometimes, the agile label is used as an excuse for lack of preparation. For example, if a person has to conduct a workshop or deliver a talk and doesn’t prepare material, his or her presentation will consequently follow an ad-hoc approach. This person might argue that the approach used is agile, and therefore doesn’t require preparation or planning. Instead, absolutely the opposite is true: Agility requires a lot of planning, even more planning than a linear approach. As Lise Hvatum states, “Agile is highly disciplined and more difficult, requires more maturity, than waterfall.”13
The reality is, agile requires and embraces planning. In agile development, the artifact of a plan is not overly important; the activity of planning, however, is essential. Jakobsen contrasts a choice between an old management style—for example, Taylorism, where managers dictate procedure—and an innovative management style—such as Lean Jidoka,14 based on trust, respect, empowerment, and belief that it is the people who use a process who are best able to improve it.15
Improving processes means changing your original plan, and preparing for future re-planning to utilize what you learn as development occurs.