After review and analysis of many Agile methodologies, some of which were described in section 3.2, we come to find that they all share common characteristics. The project teams that employ these methodologies in effect practice a variety of remarkably similar “agile techniques.”
When seeking to identify the basic set of common attributes that these Agile methodologies share, we can start to develop a set of characteristics that we can call “the Genome of Agile” – We have distilled these into the following seven genes.
Story/Feature Driven
A principle of the Agile Alliance is that “Working software is the primary measure of progress.” Most Agile teams break up their projects into manageable sets of “features”, “stories”, “use cases”, or “capabilities,” rather than architecting the complete system upfront as is done in classic Big Design Up Front (BDUF) approaches. The terminology differs across the various methodologies, but the concept is the same. Feature Driven Development is perhaps the most obvious example of such a methodology, as it involves building a feature list, then planning, designing, and implementing the software feature by feature. Note that not all features are equal in size, complexity, or priority. In most agile methodologies, features are sized or weighted depending on an estimate of the amount of effort required to implement the feature. Feature planning activities must also take into account feature inter-dependencies, and plan accordingly.
From a management perspective, the implication of using this approach is that management can have a concrete measure of progress by-feature (i.e. 9 out of 10 features implemented means 90% complete, assuming all features weighted equally.) This differs from traditional EVM-like measures of progress, based on arguably arbitrary milestones, where for example, the completion of the design phase translates to claiming forty percent of the project complete. One of problems with using a waterfall method paired with EVM management methodology is that a project can report to be at 90% completion, yet still have no functioning software.
Another advantage of the feature-driven approach is that, as features are developed and integrated into the software, they become available for early customer demonstrations as well as early integration and test activities – all of which help reduce uncertainty and detect defects early in the development cycle, as opposed to waiting for a complete integrated build.
The downside of a featured approach is that over time, the software’s architecture and code start to exhibit signs of having “high coupling” and “low cohesion,” making it harder (and more costly) to maintain and evolve. Coupling refers to the degree to which software modules, components, etc., depend on each other – in a system with high coupling there is a high degree of dependency, meaning that changes to one software element is likely to have ripple effects and impact on the behavior of other elements. Cohesion is a measure of how strongly related the responsibilities of a single software module or component are – low cohesion is an indicator of lack of structure in the system. (for example, a software library or component that provides a large set of completely unrelated functions or services is said to exhibit low cohesion, whereas one that only specifically provides string manipulation functions is said to be highly cohesive.) The segmentation of a system by feature can lead to “high coupling” and “low cohesion.” Higher coupling and lower cohesions means that there are a lot of software interdependencies; changes to one area of the software will have more impact on other parts of the system, and thus makes future changes more costly and difficult to make. This is why Refactoring (see section 3.3.3) is called for by most feature-driven methods.
