“We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.”

The Agile Manifesto

The remainder of this chapter is a brief introduction to some of the better-known software development methods within the agile, or lightweight area.

XP – Extreme Programming

XP, or eXtreme Programming is perhaps the best known of the “lighter”, or agile methods. It defines a way in which developers and customers work closely together in a team that promotes communication and problem solving. Requirements are written on “story cards” which is then used to set up a rough release plan, which can be changed after every iteration. Releases are small and each iteration lasts 2 – 3 weeks, and produces visible functionality for the user.

XP promotes good quality, fast programming by having developers pair, each checking the other’s code while it is being programmed. Code should be as simple as possible, and only solve issues in the current iteration. Extensive use of continuous integration and automatic testing promotes changes to be made to the code base by any developer when that change is needed.

The principle behind XP is that if something is worth doing often, then XP will do it extremely often – continuously. Since testing often is good, XP will test continuously. Since building often is good, XP will build continuously. And since often code reviews are good, XP will review continuously, while the code is written – with pair programming.

XP require a strong level of discipline from its programmers with strict programming standards, and testing standards to be followed. XP was designed for small teams of up to 10 people, but have been successfully used (with changes) on projects of around 50 people.

Although XP popularly has been referred to as “a hackers dream” it is in fact a very strict method that require very disciplined programmers in order to work. It is probably the method that demands the most changes in the way that most of our programmers work, with two and two programmers continually communicating, test cases written first, and following strict coding standards.

FDD – Feature Driven Development

Feature Driven Development is an agile and adaptive approach for developing systems. It focuses mostly on overall design and iterative building of the new system. It emphases quality aspects throughout the process and includes frequent and tangible deliveries, along with accurate monitoring of the progress of the project.

FDD consists of five processes, where the first three concerns the entire project, and the last two are the iterative part of the method.

In FDD an overall model is first created, based on given requirements like use cases, user stories, requirement lists etc. The overall model is then used as the basis for a list of client valued features to be included in the system.

A high-level plan is created, based on feature priority and dependencies. Sets of features are assigned to Chief Programmers, which will be responsible for development of the feature sets.

A small group of features is selected from the feature sets, and feature teams to develop these are formed. The design by feature and build by feature iteration should not take more than two weeks, but there can be multiple feature teams concurrently designing and building their own set of features. The feature building processes includes such tasks as design inspection, coding, unit testing, and integration and code inspection.

After a successful iteration, the completed features are promoted to the main build, while the iteration of designing and building starts with a new group of features taken from the feature set.

Scrum

Scrum is a more project management oriented method than both XP and FDD. Its rationale is that developing systems is unpredictable and chaotic. It considers development to be an empirical process that can only be controlled through frequent feedback.

In Scrum, the development team accepts a list of features to be developed over the next iteration, which last for exactly 30 days. The list of features is not changed over the 30 days, and its implementation is demonstrated to the customer at the end of the iteration. An iteration in Scrum is called a Sprint, both terms borrowed from the sport rugby.

The project manager maintains a list of features, or customer requirements, in a Product Backlog. Every new iteration (Sprint), picks out as many items from the Product Backlog that can be developed in the 30 days the sprint lasts, and enters them into the Sprint Backlog. The customer is encouraged to change the content, or priority, of the Product Backlog, but not the Sprint Backlog, once established. The Sprint Backlog must be constant during a Sprint. New high priority customer requirements will be part of the next Sprint.

Scrum says very little about how the development team should work during a Sprint, other than a required short meeting every day for all developers (the Scrum). This short status meeting is used as frequent feedback to the project manager, with the three questions shown in Figure 3. The project manager will then use this information to better the working conditions of the team. He can reallocate resources within the sprint, remove organizational obstacles, and act as a shield for the development team against the rest of the organization. Also other stakeholders can be present on these meetings, but only for listening to get an impression of the state of the sprint.

This is probably the “easiest” method to implement in most organisations, as it does not impact the day-to-day work of each individual like XP does, but merely gives the developers the undisturbed time to do it.

Unified Process (UP)

The Unified Process (UP) is probably most known as Rational Unified Process (RUP) after the company that created the method. UP is marketed as a process framework, where every company (or project) can modify parameters to make the process fit.

On the outset, UP has been conceived by many as a heavy waterfall process, but this is strongly opposed by its followers.

The lifespan of an UP project is divided into four major phases, as can be seen in the figure. These are split into iterations, each having the purpose of producing a demonstrable piece of software. The duration of an iteration may vary from two weeks or less and up to six months.

In the inception phase scope, boundary conditions, and acceptance criteria of the project are established. Critical use cases that will drive the functionality of the system are identified, and schedule and cost are estimated for the project.

The elaboration phase is where the problem domain is analysed, bearing in mind the entire system that is being built. UP assumes that this phase will yield sufficiently stable requirements and plans and will describe infrastructure, process, and development environments in detail. The end of this phase will include a demonstrable prototype of the architecture.

In the construction phase, all remaining features are developed and integrated into the product. UP consider this a manufacturing process, with emphasis on managing resources, controlling cost, schedule, and quality.

The transition phase is entered when the product is found to be stable enough to be released into the user community. This phase includes all beta testing, user training, product roll-out, and producing user documentation.

UP is not generally considered particularly “agile”. The method was originally developed to cater for the entire software production process and contains extensive guidelines for process phases that are irrelevant in an environment that is likely to call for an “agile” approach. However, the method is marketed as a “process framework” and there has been successful individual adjustments of UP towards agility. This is a rigorous task in which the more than a hundred UP artefacts must be screened in order to keep only the essential ones.

One of the critics of UP is that it leaves the tailoring to the user entirely, which raises the question of how much of UP can be left out, before it is not UP anymore?

EUP – Enterprise Unified Process

The Enterprise Unified Process (EUP) is an extension to UP. It adds two extra phases and two new disciplines to the Unified Process in order to handle the total lifecycle of a system within an enterprise viewpoint.

The two new disciplines, or activities, are “operations and support” and “enterprise management”. Operations and support is what it says, to operate and support the produced software, with support plans, help desk procedures etc. Enterprise management focus on activities required to develop, evolve, and support the organisation’s infrastructure artefacts like organization-wide models, standards, guidelines, and reusable artefacts.

The two extra phases are the production phase representing the time the system is in production, while the retirement phase is focused on the part of the lifecycle where an application is permanently removed from production.

OSS - Open Source Software Development

The Open Source Software development is not strictly speaking a defined development method, but this way of working has produced some remarkable popular products widely used all over the world. The Apache web server, the Perl programming language, and Linux operating system are well known examples.

Most OSS development projects are focused on development tools or back-office infrastructure where developers often also have the role of users, or customers. There is therefore little need for outside customers, feedback is based on postings back to the project. The systems are built by potentially large number of developers and where work is not assigned; people themselves choose the task they want to work on. There is no explicit system level design, and no project plan, schedule or list of deliveries.

For OSS projects the Internet is crucial for survival and success. Its developers needs to communicate, but will probably never meet face-to-face. New versions are distributed over the net and code contributions are checked in and out over the net.

The interesting thing with OSS is that is shows that working, stable, usable software can be produced without any explicit responsible, or funding organization.

The OSS method of software development could perhaps be investigated for use when developing and maintaining sets of supporting, home made development tools. Examples of such candidates within Braathens CBD environment would be the report generator and merge tool for UML/XMI models. An OSS like environment could be set up locally in an organisation, with web based cvs, discussion groups, issues to be solved etc. Developers could then, on an individual basis choose to work on these tools between other assignments.

Similarities and usability of Agile Methods

As shown in the start of this chapter, all agile methods (with the exception of UP and OSS) share the same set of collaborative values and principles, and they value having a barely sufficient methodology. Each method is however approaching the problems faced in software development from a different angle.

XP represent practice-oriented viewpoints, and contains a number of practices that over the years have been found to be useful by developers. As such they are very valuable. FDD does not cover the early start of a project, and assumes that there are use cases or user stories available before starting on the overall model. FDD also, more than the other methods, promotes getting an early overview of the entire system before starting coding. FDD proponents believe that an overall model will take away some of the need for re-factoring, so heavily used in XP. Both XP and FDD lay down strict guidelines (practices) for the day-to-day work of developers.

Scum is a project management approach that relies on self-organizing, independent development teams implementing software projects in 30-day cycles called Sprints. Scrum leaves a lot of the every day work to the teams themselves.

UP (RUP) is not considered a particularly agile software development method, but it can be one. It also stands out from the others by being a method covering the complete lifecycle of a computer system. This is particularly evident in EUP, which is a specialization of UP.

The common denominator for all approaches is the iterative development process, allowing requirements to be introduced, changed, and removed in successive iterations.

If we see the methods from a modelling point of view, only FDD and UP suggest creating and using an explicit model, and where the model is intrinsic to the success of the method. XP does not recommend an explicit model in a modelling tool, but says models can be made on whiteboards etc to explain a concept there and then (but not kept). Scrum leaves the use of a model up to the development team, as long as code is created.

When it comes to the form of communication promoted by the method, then XP is at the one end with loads of verbal communication, and only one artefact – the source code. On the other side there is UP, specifying loads of artefacts to be produced, possibly to minimize the need for verbal communication. FDD is somewhere in the middle with a few “must have” artefacts (overall model, feature lists). Even Scrum have at least two required artefacts (project backlog and sprint backlog).

From a managerial point of view, XP seems like the “worst” method to control (except OSS), while UP, FDD, and in particular Scrum has strong elements of process control included in the process. UP and FDD can be controlled more along the lines of traditional project management, with a bit of up front design, and then planned iterations until the project is finished. This requires a fairly stable project environment since both methods expect requirements to be reasonable stable after the initial project phase (inception phase). Both Scrum and XP have the built in assumption that requirements can (and will) change during development and therefore make no assumptions (whatsoever) about the future. In Scum requirements are locked during an iteration, while XP are more loose on this point, but have shorter iterations, and more individual iterations. In Scrum, the project manager can be fairly administrative (as long as the team is self driven), and govern iterations by requirements and short meetings. XP on the other hand require a “coach” more than a project manager, and expects the coach to participate in the daily (technical) work of the team.

As a final conclusion both UP and FDD has a project wide, or system wide view with their assumptions of reasonable stable requirements, and is best used over the entire project period. Scrum and XP, on the other hand does not rely on such an overview, and will be most successful when applied to “unstable” projects, to extensions of existing systems, or even part of larger projects.