- Where Do the Practices Come From?
- Using Practice Descriptions
- Adopting the Practices: Iterative Development, Levels of Ceremony, and Agility
- Key Development Principles
- Unified Process Lifecycle
- OpenUP/Basic
- Rational Unified Process (RUP)
- eXtreme Programming (XP)
- Scrum
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Adopting the Practices: Iterative Development, Levels of Ceremony, and Agility
A key aspect of this book is to allow you to move incrementally from where you are today to where you would like to be a couple of years from now, adopting the practices at your own pace.
Levels of Adopting the Practices
Each practice can be adopted at three levels: basic, intermediate, and advanced.
Each practice can be adopted at three different levels: basic, intermediate, and advanced. The basic level represents a level of adoption we think most projects can adhere to with limited investments, that is, with a limited skill set and with no or small amounts of tool investments. This level thus represents a reasonable starting point on your journey toward improved ability to develop software effectively, but it is not necessarily an acceptable end goal. As you move to the intermediate and advanced levels of adoption, you will have to make additional investments in building skills and/or tools. For some teams and practices, the basic or intermediate adoption level is preferable. Other teams should aim at adopting advanced-level practices for maximum productivity.
Process Map
To understand the level that is appropriate for your team, we will use a process map (see Figure 1.1) characterized by two dimensions discussed below:12
- Low ceremony/High ceremony13 dimension on the horizontal axis. Low ceremony produces minimum supporting documentation and has little formality in the working procedure; High ceremony has comprehensive supporting documentation, traceability maintained between artifacts, Change Control Boards, and so on.
- Waterfall/Iterative dimension on the vertical axis. Waterfall is a linear approach with late integration and testing; Iterative is a risk-driven development approach with early and continuous implementation, integration, testing, and validation of software that delivers concrete value to the stakeholders.
)
Figure 1.1 Process Map for Process and Practice Comparison.
By organizing processes and practices along two dimensions—Low ceremony/High ceremony and Waterfall/Iterative—you can compare them and analyze which are more suitable for your project or organization. Agility translates to being in the lower-left quadrant on the map.
(Adapted from Kroll 2003.)
Agility and Ceremony
Agility is the ability to respond rapidly to risks and change.
We define agility as the ability to respond to risks rapidly; changing requirements or stakeholders needs, or other changes impacting the application we are building.14 Agility translates to being in the lower-left quadrant in our process map. Iterative development provides us with the rapid and timely feedback we need to understand when and what to change, and the low ceremony provides us with the ability to execute changes rapidly.
So, do we always want to be in the lower-left "agility" corner? If you are two developers building an application with a short life span, you may choose to save time by not documenting many of the requirements or the design. This may allow you to be more productive and to make rapid changes to the application. However, if you are doing distributed development with twenty people in different time zones, you will probably be more productive if you document the requirements and key design decisions. But the added ceremony will add time and cost when you have to implement a change. You therefore choose to move to the right on the process map to gain productivity, while losing agility. By deploying the right tools, however, you can counter this loss and reduce the cost of change, allowing you also to move down on the scale.
Most projects15 benefit from being as low as possible on the waterfall/iterative axis to ensure rapid feedback, but not so low that the cost associated with the overhead of each iteration becomes prohibitive. One of the aims of iterative development is to reduce the overhead cost of each iteration so that you can do more iterations, and many of the practices in this book help you achieve that goal. As Professor Barry Boehm points out in Get Ready for Agile Methods, with Care,16 each project should choose the appropriate level of ceremony to fit its specific needs (Boehm used the term "agile" to mean roughly the same as what we refer to as "ceremony.") This means that each project should be as agile as possible based on its specific characteristics, but not more agile.
Most, but not all, advanced practices lead to higher levels of ceremony. If your project is better off following a low-ceremony process, you should probably not adopt an advanced practice if it leads to higher level of ceremony. On the other hand, there are many reasons why projects may benefit from more ceremony, including large project size, regulatory requirements, distributed development, complex projects, long application life span, or complex stakeholder relations. In some cases an advanced adoption level leads to less ceremony and shorter and more frequent iterations, which is probably beneficial for most projects that are willing to take on the investment.
Where Does a Level of Adoption Take You on the Process Map?
We describe the levels of adoption for each practice, as well as giving an indication of the direction in which the adoption level will take you on the process map. Let’s look at examples of some of the symbols we use:
If the arrow goes down and to the left, it means that adopting the practice at this level will lead to, or enable you to have, shorter iterations with a decreased level of ceremony. This is typical for many of the practices at the basic level but could also be true for the intermediate and advanced levels.
If the arrow goes down and to the right, it means that adopting the practice at this level will lead to, or enable you to have, shorter iterations, while increasing the level of ceremony or learning curve for new team members. This outcome may be desirable if your project needs more ceremony, or if team members need to build more skills, but if that is not the case, your project should consider not adopting the practice at this level.
If the arrow goes up and to the right, it means that adopting the practice at this level will increase the level of ceremony you are working with, as well as the overhead associated with doing shorter iterations, potentially forcing you to increase the iteration length. These are typically not good changes for a project, but the benefits of implementing the practice may be valuable enough to counteract the drawbacks.