pdfcoffee.com-systems…
5.4 Malting the Choice between Agile and Hybrid Construction using the Home Grounds Model
There is no single best way to plan and execute all software construction projects. In other words, agile is not always better than hybrid or vice versa. For example, we noted earlier that agile is better suited to small, simple projects with uncertain and/or rapidly changing requirements, while “plan-driven”—which we now clarify to really mean hybrid—is better for large, complex projects and a higher degree of requirements clarity and stability.
However, this is not always obvious from reading trade magazines or blogs. Advocates of agile and hybrid methods argue their respective cases with near messianic zeal. In particular, some advocates of agile—who tend to argue the loudest because they are trying to replace existing
plan-driven approaches—argue that the agile approach is always (or nearly always) better than hybrid. Despite this, there is good evidence indicating that hybrid approaches continue to be heavily and effectively used in large, complex projects.
Thus, for each project, we need to make an optimal choice based on that project’s size and complexity. But what do we really mean by “small and simple” versus “large and complex”? What specific characteristics can we measure to make sense of this and thereby home in on the optimal project approach?
This is not a simple question to answer. Software projects are highly complex. In fact, they are among the most complex of human activities. They encompass issues ranging from technical software coding techniques to aligning the IT team with high-level business strategies and values. In between lies a kaleidoscopically diverse set of issues.
For example, what do we mean by “size”? Does this refer to how many new features we need to build? How many users the system needs to support? The size of our IT team? In fact, these all pertain to “size.” Similarly, “complexity” is driven by multiple factors in its own right.
Fortunately, we can utilize a reasonably simple framework to measure the key characteristics of a project that will guide us to a sound decision. This framework is called the Home Grounds Model, which was first introduced by Boehm and Turner (2004) and later extended into the model presented here. This model helps us gauge a project’s size, complexity, as well as other factors having to do with how well we can understand requirements up front and how valuable creating those up-front requirements will be. In short, the Home Grounds Model provides an with a list of characteristics defining projects that will be best supported by agile approaches versus projects that will best be supported by hybrid approaches.
Home Grounds Model
A model that defines different sets of project characteristics, indicating where agile versus plan-driven approaches are most appropriate and likely to succeed.
Table 5-2 presents the Home Grounds Model’s key project characteristics. Each characteristic is grouped into one of three major categories:
• Functional requirements characteristics: What are the characteristics of the business functionality we need to create? The needs for business functionality are described by process modeling in Chapter 2 domain modeling in Chapter 3 user stories and UI modeling in Chapter 4, as well as additional requirements models that we cover in later chapters. This will tell us whether it is worthwhile to create big requirements up front (BRUF). • Nonfunctional requirements characteristics: What are the requirements for system performance in terms of number of users, uptime, security, and so on? And how complex are the technologies needed? This will guide us in terms of the amount of up-front architectural planning we need to do. (As we will describe in Chapter 8, “architecture” pertains to technical system planning for things that are difficult to change after the