Page 94 -

TRANSITION TO AGILE SOFTWARE DEVELOPMENT IN A LARGE-SCALE PROJECT 79
• Fourth, in the agile project, all team members may potentially work on the specifications—all have
been trained to do so—a fact that promotes the separation of specifications into more modules,
so that more people can edit them in parallel. This tends to make modularity and refactoring a
practical necessity, ensuring their ongoing realization and consideration in practice.
• And finally, the complexity measures may be higher for the plan-driven project because
most of its specifications are not standard features in the framework, and accordingly are
specified via free-text business logic, which implies higher complexity. This hypothesis is
referred to in the sequel by examining the ratios of complexity to size (in contrast to number
of modules) in the two projects.

Further observation of the two graphs shows that the agile project managed to keep modules
simple over time. This is true even though the agile project grew faster than the plan-driven
project during the examined period. Putting aside the agile project’s first month, which included
major one-time setup work, it can be observed that from February to September the number of
modules and the overall size of the specifications grew by 65 percent and 70 percent, respectively,
while keyword-based complexity grew by 4.3 percent. In contrast, while the plan-driven project’s
number of entities and total size grew by 6 percent and 8 percent, respectively, its keyword-based
complexity grew at a larger rate—by 5.7 percent.
This means not only that the agile project is more modular, but also, in addition, it is devel-
oped in a manner that maintains its modularity better than that of the plan-driven project. Again,
this can be attributed to the same factors mentioned above: the project’s stage and the analysts’
experience, in addition to the agile practices of refactoring and collective ownership, which in
this project were applied to the specifications as well.
Figure 6.4 presents the logic-based complexity of SpecP and SpecA, averaged over all modules
of each project. The graphs show a very similar picture to that shown by the average keyword-
based complexity graphs. Once again, the complexity values of the plan-driven project are four to
five times greater than those for the agile project. The results, and hence the possible explanations,
are consistent with those given for keyword-based complexity.
The difference in absolute complexity can be explained by several factors that do not stem
from the development method. For example, the agile project could be inherently simpler than the
plan-driven one. However, developers’ evidence in both projects revealed that this is definitely
not the case. As an explanation, it was suggested that the agile project reuses more features built
into the framework and therefore can be specified in a way that enables automatic code genera-
tion. By presenting the ratio of logic-based and keyword-based complexity to the size measure,
thereby measuring the proportion of complexity to specification size, Figure 6.5 supports the
above explanation.
In both the “logic-based and the keyword-based complexity versus size” graphs, the project
values are relatively constant over time, and are 20–50 percent higher for the plan-driven project.
This means that in general, the specifications of the plan-driven project use more free-text business
logic and fewer framework-ready features in order to convey the same size of specifications.
A combination of setting and process can explain this phenomenon. From the setting point of
view, the agile project started after experience in specification had been gained in the plan-driven
project, and therefore business analysts knew more about how to utilize the framework. From the
process perspective, the agile project’s focus on simplicity and ongoing refactoring drives toward
the writing and maintaining of specifications that are as simple as possible. We do not have quanti-
tative data to assess the relative contribution of each of these factors to the results, but interviews
with the project team members indicate that both factors influence them.