The working methods in the cyclical phase are borrowed from XP. In this phase, a number of cycles are performed in succession. A cycle lasts no more than one to two weeks. The following activities take place within each cycle:
- Examination of Functionalities
- Design of Functionalities
- Implementation of Functionalities
- Testing of Functionalities
- Delivery of Functionalities
At the end of the design phase, an estimate is made of the number of cycles that will be needed to achieve the project goal. This occurs according to the functional and technical design. Cycles are never long; they usually last between two and four weeks. A cycle always includes the activities of planning, investigating, designing, implementation, testing and delivery. Each cycle, therefore involves only a few functionalities (or sometimes only one).
The procedures for planning are as follows. The desired functionalities are written jointly by the project leader and the customer on ‘story cards’, starting with the functionalities that were determined in the definition and design phases. Using the story cards as a guide, the programmers create a task list, which is a list of tasks that are involved in implementing a functionality. These tasks should generally not last longer than a few hours. If a task takes longer, it should be divided into a number of sub-tasks, or the story card must be divided into several story cards. Story cards that contain too much work to be completed in one cycle should be returned to the customer, who must divide the requests and distribute them over additional story cards. The programmer estimates the amount of time that will be necessary for each task, thus producing a time estimate for each story card. Customers can now work with the project leader to determine which of the functionalities they would like to be implemented first in the next cycle.
How long does it take to create a website and fill it with fifty pages of text and a number of photographs? A quick answer from the designer is that it would take ‘about two weeks’ is much too rough. It could well take much longer. Dividing the task reveals the necessity of creating a CSS, consulting with the client about the design, programming the design in XHTML, shortening the texts for the Internet, filling the pages with the texts, adapting the photographs for the Internet and placing them, allowing the customer to examine the website and removing the last remaining errors.
Dividing the work into smaller parts reveals that the task involves much more work than was initially thought. The client also realises that he is also expected to do a number of things. Estimating the amount of time that is necessary for each task yields a much better total estimate (and shows that it is not possible within two weeks).
Once the programmers begin, they keep a record of the hours that they have used to perform each task. They often need more hours than they had originally estimated. Because they have the opportunity to refer back to their own estimates, the programmers learn to make increasingly accurate estimates.
Experience has shown that, as a project progresses, a relatively constant difference factor emerges between the estimates and the number of hours that are actually needed. After a few cycles, this factor, which is known as the ‘drag factor’, can be determined according to the average difference between the estimated and the actual number of hours. The drag factor is used for planning future cycles and in reports. Multiplying the number of remaining story cards with task lists by the drag factor provides a particularly reliable indication of how much time is needed to implement the rest of the project.
Because the number of hours for the project is limited, choices must be made. The availability of a reasonable estimate of the time needed to implement a story card allows a good deliberation between the various story cards. Some story cards are simpler to implement than others are, and some story cards may be eliminated. An important starting point for determining the order is that risky story cards must be handled first, in order to eliminate the most important risks as soon as possible.
The MoSCoW rules are also applicable, or a simple prioritisation from one to five.
Investigating and Designing Functionalities
The initial investigation of a functionality takes place during the creation of the task list for planning. By deciding ahead of time which sub-tasks will be needed to implement a functionality, the programmer gains more insight into the functionality itself. The involvement (presence) of the customer is essential for the further investigation and design of the desired functionality. Customers should specify exactly what they want. In the beginning, customers have much more contact with the programmers than they do later in the project, although caution must be taken to ensure that the programmers do not start thinking for the customer, thereby making erroneous assumptions.
Implementation of the Functionalities
After the customer and the producers have agreed on a design for the desired functionality, it is built. Programmers always perform this work in pairs (in XP terms, this is known as ‘pair programming’). Although this may seem nonproductive, pair programming offers the following advantages:
- The knowledge of two programmers is combined.
- Less time is spent transferring knowledge or code within a project.
- Fewer errors occur in programming.
- Problems are resolved more quickly.
There is an additional advantage to working in pairs: the greatest problem is getting started with programming. Once the work has been started, it can proceed.
Programming in pairs allows the programmers to encourage each other to get the work started.
Joel Spolsky, a programmer for Microsoft, realised that he worked effectively for only about three hours each day, and often even less. Other colleagues apparently had the same experience. The rest of the time was spent drinking coffee, reading e-mail, surfing the Internet, chatting with colleagues and looking at the beautiful office courtyard. Working with a partner can increase motivation, thus making it easier to get started.
Despite its advantages, pair programming also places considerable demands on the concentration of the programmers, and not all programmers like that. Further, not all combinations of programmers are capable of working together well. To minimise these disadvantages, a team might decide to use pair programming for more than half of each working day.
Testing and Delivery
It is essential that every cycle culminates in the release of a new component of the software and that each component that is delivered is tested Testing consists of a unit test (conducted by the programmers) and an acceptance test (conducted by the customer). The customer is thus needed for this task as well. The assumption behind including testing in each cycle is that it becomes exponentially more expensive to repair errors in relation to the time that it has taken to discover them. A basic assumption underlying the delivery of software in each cycle is that customers are able to see value for their money as quickly as possible and that programmers can receive feedback from the users as quickly as possible. Customers are able to see the progress of the project clearly. This is particularly important psychologically, and it can improve the customer’s attitude considerably.
Activities in the Cyclical Phase
- Work through a number of cycles, each of which involves investigation, design, implementation, testing and delivery.
- Prepare story cards.
- Choose among the story cards.
- Plan the cycles.
- Ensure progress (control factors).
- Prepare a concrete estimate of the control factors for the follow-up phase (at the end).
- Project leader
- Client or customer
- Current or potential end users for testing and design
- Programmers and designers
Wouter Baars has a Master of Science degree in Industrial Engineering and Management Science. He has been a project manager for several years for The European commission, Waag Society, KPN (Dutch telecom provider) and many smaller organizations. He is specialized in creative projects such as serious game development, e-learning and software development. Currently he is teaching project management and coaching organizations that are working on their project management. More info on his work: www.projectmanagement-training.net.
Originally published by DANS – Data Archiving and Networked Services – The Hague