Page 102 -

TRANSITION TO AGILE SOFTWARE DEVELOPMENT IN A LARGE-SCALE PROJECT 87
Considering our previous analysis, this makes sense. Although the plan-driven project is nine
times larger than the agile project in terms of the size measure, it has only six times more modules
at the beginning of the examined period, and three times more modules toward its end. This means
that each module in the plan-driven project contains many more specifications than in the agile
one, and this in turn implies that even though the tests-per-size ratio in the agile project is higher,
its overall tests-per-module ratio is lower.

The Role of the Systems Analysts

In this subsection, we focus on the systems analyst role and the changes in its characteristics
during the transition period. Since everyone on both the plan-driven and the agile teams has been
exposed to the agile notions, we compare the responses of the systems analysts who work in the
examined project, with those of systems analysts from a major Israeli software company, who do
not work according to the agile concepts.
The data analysis reveals three working models that may clarify the transition process in the
examined project as well as its future management.
The first development model is a pipeline-distributed model, according to which a specific
software project consists of three different groups—the systems analysts group, the develop-
ers group, and the QA testers group. During the development process each group refers to the
output of the previous group as its input. This description is simplified and therefore does not
refer to the feedback loops between the groups, assuming that in an ideal pipeline process
feedback is not needed. In general, this model fits the development process of the plan-driven
project team.
The agile movement, and specifically Extreme Programming, refers to a working model that
is more concentrated in terms of space. The Extreme Programming notions of Sit Together and
Whole Team, along with the practice of Weekly Cycle, require the groups of analysts, developers,
and testers to share one space, to collaborate on a daily basis, and to produce common artifacts
on a weekly basis. In general terms, this model fits the way shaped by the agile team during the
transition period.
We suggest that on a small software team the concentrated model may work also for the
entire systems analysts group. However, this model did not work for the transition-to-agile team
that we examined. As has been mentioned before, during the transition process, one functional
systems analyst worked together with the agile development team and another systems ana-
lyst stayed a part of the external functional analysts group. The group of operational systems
analysts did not change at all. We refer to this model as a hybrid, in which its hybridism level
depends on project size and complexity as well as on the perspectives and cooperation of the
people involved.
In what follows we describe how systems analysts conceive of their role and what effect
the transition to agile development has on their perceptions. As mentioned previously, to learn
about these conceptions, we used two questionnaires. The first one is a Software Development
Culture Questionnaire (SDCQ) (presented in Hazzan and Dubinsky, 2005) and is shown in
Appendix 6.1. The second questionnaire is a Systems Analysts Questionnaire (SAQ), and is
shown in Appendix 6.2.
Below we compare answers to the SDCQ given, after a few months of the transition period,
by fifteen systems analysts of one of the major software companies in Israel with those of five
systems analysts of the examined project. Several illustrative examples of the differences are
identified. 1