2 Agile philosophy and principles

This chapter covers the following topics:

• the origins of agile;

• the Agile Manifesto;

• the 12 agile principles;

• agile approaches;

• agile practices.

Introduction

Agile is a lightweight software development approach that evolved in the mid-1990s and resulted in an Agile Manifesto and an accompanying set of ‘12 principles of agile software’ published in February 2002. Since then, it has grown in popularity and is now an extremely common and fashionable umbrella term for a number of methods and processes. It is used by thousands of development teams across the world, and is the subject of numerous books, papers and training courses. In that time, it has evolved and changed, and is not only applied to software products, but also to other types of development.

There are many synergies between agile and business analysis. Agile favours highly collaborative working between the customer and product development team; a focus on the early and frequent delivery of tangible solutions; and an iterative approach that is highly responsive to changing requirements. While the major focus of the agile approach is on the development of software, the concepts can apply to business analysts working on change projects, where the project focus is on business rather than technology changes. However, to do this successfully, business analysts need to understand the rationale and philosophy that underpin the agile approach.

While the rest of this book will focus on how it may be applied to business analysis, this chapter explains how agile has developed and provides an introduction to the agile philosophy, principles and methods.

THE ORIGINS OF AGILE

Before the term, ‘agile’ was coined, software had been successfully created for decades. Until the early 1990s, linear planning techniques were commonly used, which isn’t surprising, given that software development originated from computer systems engineering. These linear systems are commonly referred to as ‘waterfall’, due to the way that they were drawn in Winston W. Royce’s influential article from 1970, ‘Managing the development of large software systems’. Interestingly, Royce did not actually use the term ‘waterfall’ in his paper; however, he is renowned for developing this approach and its resulting use ever since.

Royce represented a common approach to developing complex software systems, as shown in Figure 2.1.

 

Figure 2.1 Waterfall development approach

Unfortunately, Royce’s paper was widely misunderstood. He presented the above model as ‘risky and invites failure’, and was proposing modifications to make it much more iterative and incremental. However, that element of his work is largely forgotten, and his waterfall picture remains in common use, although the names of the stages have changed a little over time.

As discussed in the BCS publication Developing information systems, the waterfall method and its variations are effective for some types of development. However, as Royce himself stated, it is less suitable for many types of project, as capturing and baselining all the requirements early in the development life cycle, and expecting them not to change, is a significant drawback for many, if not most, projects.

The evolution of iterative methods

New methods began to emerge in the 1980s and 1990s as a response to some of the challenges that developers faced when using a waterfall approach. One of the first to become popular was Rapid Application Development (RAD), which involved creating prototypes and using them to elicit requirements, validate designs and evolve toward usable solutions. RAD began at the New York Telephone Company and was refined by IBM in the 1980s. A book, Rapid application development, by James Martin, with contributions from several others, was published in 1991.

Although RAD is a method in its own right, it also spawned a number of alternative approaches that are based on some of the same principles. One popular example is the Spiral model, developed by Barry Boehm (1988), one of James Martin’s collaborators. This model introduced the concept of incremental planning, definition, design and development of software so that each time around the spiral the risks are reduced and the end result is more predictable.

A different iterative development method emerged in the late 1990s that combined some of the rigour and whole life cycle elements of the waterfall life cycle, with incremental delivery and a particular focus on modelling. It was based on the research of three men who originally collaborated to create their most famous work, a modelling notation known as the UML. James Rumbaugh, Grady Brooch and Ivar Jacobson (known as ‘The Three Amigos’), developed ‘The unified software development process’ in 1999 with Philippe Kruchten, who provided the overall architecture for the iterative approach.

At the time, they were working for the Rational Software Corporation and their process therefore became available as the Rational Unified Process (RUP). RUP is risk driven, iterative and takes a use case- and architecture-centric approach.

The founding agile methods

Through the 1990s, a number of alternative ways to organise and structure the development of software products began to emerge and shape the thinking that eventually evolved into ‘agile’ in 2001. These approaches were referred to collectively as ‘Lightweight Methods’. The key developments are described in Table 2.1 below.

The Agile Alliance

It was Kent Beck who first sowed the seeds of the agile movement, with the publication of his book in 1999 and his invitation to various leaders in XP to join him at a retreat in Oregon. Significantly, he didn’t just invite XP thought leaders, but also several other people who had similar interests. These included Alistair Cockburn (Crystal), Jim Highsmith (ASD) and Dave Thomas (co-author of The Pragmatic Programmer) (2000). At this initial meeting, they discussed the similarity of XP with other methods and decided to meet again, with a broader range of people, to explore common ground.

 

Table 2.1 Agile development methods

On 11 February 2001, a group of 17 people met at ‘The Lodge’ at Snowbird Ski Resort in Utah to talk, ski, relax and try to find common ground between their thoughts on software development. They represented the leading thinkers from XP, Scrum, DSDM, ASD, Crystal, FDD and Pragmatic Programming, along with others who wanted a viable alternative to heavyweight, documentation-driven development processes.

Two days later, they had agreed on a name to replace the term ‘lightweight’ (which had been used up to that point but was not well liked), a manifesto that embodied the values they all believed in and a set of guiding principles. The Agile Alliance was born.

The agile mindset

One of the remarkable things about those two days at the ski lodge in Utah is that 17 people with very different backgrounds and perspectives managed to reach agreement on what agile means. They were applying different approaches, and had different ways of achieving similar outcomes. Yet, they were still able to agree a set of principles and values that they could all sign up to.

This is why agile should be regarded as a mindset – a way of thinking, and not a method to be learned. This mindset should be supported by methods and techniques that help projects to adhere to the principles and values, as shown in Figure 2.2.

If agile is thought of in this way, it is possible to see why there are different agile approaches and methods that can all support the same principles, even though they differ in execution. Unfortunately, this also means that it is not possible to instruct someone in how to be agile; they have to adopt the mindset. While you can teach a process, you cannot teach a way of thinking, and just applying an agile process or technique will not mean that you are applying the agile principles and values.

Agile is a philosophy to be felt and comprehended, such that it guides the way in which work is approached. It is not a method to follow.

 

Figure 2.2 The main elements of agile

Although this is not a universally held view, it is held strongly by the authors of this book. While it can be possible to treat agile as a recipe to be followed for straightforward projects, as complexity increases this becomes less and less likely to succeed. In practice, projects are not simple, and in order to succeed with an agile approach, the team must have or gain an agile mindset.

THE AGILE MANIFESTO

The most important and most visible result of that meeting in Utah, shown in Figure 2.3, was the publication of the manifesto for agile software development.

 

Figure 2.3 The manifesto for agile software development

The manifesto for agile software development (often shortened to the Agile Manifesto) is short but powerful; in a few words it manages to encapsulate a wide range of concepts, ideas, prejudices, values and experiences of software development. Although the key focus is on software development, once unpacked, there is very little that is actually software specific. That’s why various commentators over the years have proposed amendments and changes. Indeed, in Chapter 3, we shall propose our own version, reflecting a business perspective and more applicable to business analysts. However, the original words remain unchanged on the website, and, for the most part, still hold true for many situations.

Although simple, the Agile Manifesto is often misunderstood. In particular, the final clause is often forgotten or ignored: ‘That is, while there is value in the things on the right, we value the items on the left more.’ It is really important to remember that agile projects still require processes, tools, documentation and plans; it is just that these are not the most important artefacts or deliverables. It is the outcome delivered by the project that is the actual value.

Let’s look at the individual statements of the Manifesto in greater detail.