The last reason why cyclical project techniques generate better results is that the
customer performs acceptance tests. Quality is further strengthened by using tests
as criteria for well-performing functionality from the very beginning. Programmers
must therefore define ‘failing tests’ (or unit tests) before they write their code. The
code is considered acceptable only if it passes the failing test.
Test-oriented work requires programmers to prove that there are no bugs in the
new code before they write new code. They do this by developing a test (failing test)
that would detect any possible bugs before they begin coding. For example, imagine
that a programme must be written for calculating the correct amount of change that
you must receive from a candy machine. First, the availability of a function to give
change must be tested. This function could be called ‘give_change’. A simple test
could be made and, when it is performed, it is determined that a ‘give_change’
function does not yet exist. If the programmer then makes the function but does not
yet give it any substance, the test will succeed.
The next step would be to test whether the machine gives the right amount of
money back when an item is purchased. Insert sixty cents into the machine and buy
an item that costs fifty cents. The test will not succeed, because the function is still
empty. The programmer then writes the code. In the ‘give_change’ function, he
writes that the amount of change to be returned is the amount of money that was
inserted in the machine, less the price of the chosen candy. The test should now
succeed. The process continues in this way; for each component of the software, a
test must be devised beforehand (example translated and adapted from Chromatic,
2003, p. 27 ff).
The code is not the only component that must be technically tested; the
functionalities must also be tested (i.e. acceptance tests). For these tests, the
customer determines the conditions under which the functionalities that are to be
built can be accepted, before coding begins (e.g. how quickly a computer must
respond to a certain action of a user). The prior specification of the conditions under
which the new functionality can be accepted has proven particularly difficult and
time-consuming. Nonetheless, the active role of customers in testing is an important
determinant in the success of a project.
More realistic estimation of time and money
With cyclical project techniques, the functionalities that are to be implemented are
not written in stone at the beginning of the project. The available time is specified.
Agreements are made concerning the direction in which the project will proceed, and
it is determined in the process what is actually needed, useful and realistic with
regard to the software that is to be made. In cyclical projects, the functionalities that
are to be implemented are not established as fixed goals, and they thus avoid the
risk that the necessary hours, and therefore money, can get entirely out of hand. To
prevent such a situation, the available time is used as a starting point, and it is
determined during the process what is realistic to expect in that amount of time.
Also for this reason, cyclical methods of project management are much friendlier for
the project team. The team does what it can do within the specified time, but is not
pressured to meet unrealistic schedules or to work within an inadequate budget.
Cyclical methods also facilitate the management of external suppliers. With the
waterfall method, a project can become bound to a single supplier until the end of
the project, regardless of the performance of that supplier. In the cyclical working
method, is theoretically possible to make new agreements for each cycle or even for
each component to be delivered and, if necessary, to change suppliers.
Conditions for cyclical project management
To apply cyclical project management, a number of conditions must be met:
1. Users/customers are actively involved.
In cyclical project management, the formulation of requirements, design,
implementation and testing take place in each cycle. This means that many decisions
must be taken in a cycle. If the software is to provide a good reflection of the wishes
of the customer, the customer must participate actively in the project team.
Customers must present their wishes as clearly as possible to the programmers and
designers. This generally involves weekly (or at least bi-weekly) presence in the
Within a project, customers are involved with determining the desired
functionalities and the planning of the cycles. They collaborate on the acceptance
tests, approve or reject intermediate results and collaborate on the general direction
of the project. The active involvement of the customer also leads to better results in
the waterfall method.
2. The team is authorised to take decisions.
Within a cycle, the project team must be authorised to do what they think is best. If
the project team does not have this power, the cyclical model of project
management will not work. If constant authorisation from superiors is necessary
during a cycle, this can lead to stagnation. Moreover, outsiders are often poorly
informed about what is going on, because they do not actively participate in the
project team; this makes it difficult for them to make sensible decisions.
3. Project result (software) can be broken down into smaller parts.
With cyclical project management, parts of the project are performed in a number of
cycles. This is possible only if the software that is to be created is divisible into a
number of more or less separate components.
4. The requirements that are imposed by management with regard to the software
are primarily global; management does not impose direct, concrete or specific
requirements. One of the strengths of cyclical project management is that the
customer, designers, programmers and any testers work closely together within the
cycles. If there are already specific and concrete requirements at the beginning of a
project, this impedes the freedom of the project team to use their better judgment
to make design choices. Many requirements on a project are revealed during the
process to be in need of adaptation and should therefore not be (too) firmly
established in the beginning.
5. The activities are intelligible for the customer.
If considerable technical work that is difficult for the customer to understand must
take place within a cycle, a risk emerges that the customer will not be in state to
participate well in the team. In such a situation, the customer has very little to
contribute to the necessary design choices.
A similar risk arises when the progress is not visible to the customer. For
example, much of the work may involve coding, with very little being done on the
user interface. It is important that customers have sufficient insight into the
substance and progress of a cycle in order to ensure that they are not pushed into
6. It should be possible to take a step backwards.
Even in cyclical project management, teams sometimes pursue paths that later
prove to have been wrong. In such a case, it should be possible to take a step
backwards. If a new module that is created in a cycle proves inadequate, it must be
possible to resume working with the old module. This imposes demands, particularly
with regard to the archival and documentation of the project materials. Concurrent
Versioning System (CVS) and Subversion are two helpful tools for these tasks (see
Appendix 3 for a list of tools).
7. In addition to programming, programmers should be able to communicate with
customers, and vice versa. Team members must be in state to think conceptually.
Discipline is necessary in order to persevere with the work.
8. The organisation in which the project takes place must also offer sufficient support
for this method of working. Systems for time reporting, archiving and scheduling are
necessary to support the projects. These registration systems ensure the
transparency that is necessary to ensure the adequate distribution of resources
across projects and time.
9. Projects should have sufficient priority, team members must be released for
projects. Requiring team members to work in too many projects at the same time
does not work. If an organisation is insufficiently adjusted to working with projects,
the flexibility of cyclical project management is likely to lead to chaos. The waterfall
method also benefits from an organisation that is arranged for working with projects
(see Wijnen, 2004, p. 111).
The director of a software house, who was more of a visionary than he was a
manager, had a brilliant idea nearly every month, and he was continually starting
new projects in his company. Older projects were consequently never completely
finished, and the employees were sometimes working on as many as five projects at
once. The charismatic director had once read a book on rapid application
development (RAD) and was quite enthusiastic about it – particularly about the
aspect of ‘rapid’. He posted the basic concepts of RAD over the copier and
subsequently assumed that everyone would start working according to these
concepts. After all, it was a wonderful method.
Risks of cyclical project management
Cyclical methods of project management sometimes allow insufficient time to
implement the desired functionalities. Because the amount of time is predetermined,
fewer functionalities will probably be made than were originally
This is indeed a real risk, but it is also inherent in the waterfall method. In the
waterfall method, the definition phase includes an extensive analysis of
requirements. This analysis could be expected to generate better time planning. This
is often not the case in practice, however, for the reasons that are mentioned above.
Functionalities are left out in this method as well, as there is not enough money to
In cyclical methods, requirements are handled pragmatically. For example, the
requirements in cycles can be divided according to the MoSCoW rules (Stapleton,
Must Have: requirements that are essential for the system
Should Have: important requirements that people really want
Could Have: requirements that are desirable, but which can be easily omitted
Want to Have: but will not have this time round: requirements that can wait until later
Regardless of the fact that there may be no more time for particular
functionalities, the DANS project managers agree that cyclical work yields more
customer satisfaction than the waterfall method does. At any rate, the expectations
are consistently better managed, and the projects deliver results that actually work,
even if they are less elaborate than originally hoped.
One frequently mentioned disadvantage of XP is that considerable power comes
to rest with the programmers. If they misuse this power, they can hide behind the
customer’s lack of technical knowledge. Preventing this situation requires a project
leader who can serve the interests of both the programmers and the customer. Such
project leaders assist their customers in choosing and planning the cycles, making
the technical background of choices intelligible and providing for administration and
Finally, another disadvantage of XP is that there is a steep learning curve for
programmers, managers and customers with regard to the introduction of the