Agile Foundations

Principles, practices and frameworks

Peter Measey

• Publisher: BCS, The Chartered Institute for IT
• Year: 2015
• Print ISBN: 9781780172545
• eBook ISBN: 9781780172569
• Topic: Business
• Subtopic: Project Management
• Index: Business

Agile practices transform the way organisations carry out business and respond to change. But to realise success, an Agile mindset needs to be adopted throughout an organisation. This book is aimed at those working in an Agile environment or wanting to understand Agile practices. Giving a comprehensive introduction to Agile principles and methodologies, it will enable the reader to apply core values and principles of Agile.

PART 1 INTRODUCING AGILE

1 WHAT IS AGILE?

1.1 THE HISTORY OF AGILE

‘Standing on the shoulders of giants’ is a particularly apt term when discussing the evolution of Agile, as Agile thinking is founded on the concepts and ideas behind many different IT governance and delivery frameworks. Table 1.1 shows the evolution of these frameworks (see Chapter 14) since the late 1940s, leading to what is now generically referred to as ‘Agile’.

Table 1.1 History of Agile frameworks

Some Agile thinking is based on the ‘Toyota Production System (TPS)’ (Liker, 2004) or ‘Lean’, as it is now more widely known. For example, the concept of Visual Boards (see Section 8.7) is taken from TPS. However, as the name suggests, TPS is mainly related to manufacturing products on a production line. Agile thinking is more focused on Lean product development than it is on Lean manufacturing, because the dynamic environments in which Agile is implemented are more similar to a dynamic innovative Lean product environment than a Lean manufacturing environment where variability is specifically discouraged and repeatability encouraged. Innovation and creativity, two fundamentals of effective product development, are enabled by variability and disabled by focusing on repeatability.

Tom Gilb’s ‘Evo’ and Barry Boehm’s ‘Spiral’ approaches were incorporated into Agile thinking in the early 1990s into what became known as Rapid Application Development (RAD).

Many RAD frameworks up to this point had concentrated on product delivery with no great focus on project governance. The exception was DSDM (see Section 14.3), which was created in the mid-1990s and focused on delivery within projects.

In 1999, another key Agile framework was created called eXtreme Programming or ‘XP’ (see Section 14.1). While XP focuses more on the values and practices associated with the technical programming aspects of engineering software, many of the practices are now also being used effectively in generic product development.

An important point in the evolution of these frameworks occurred when the term ‘RAD’ became associated with delivery failure, and finally disappeared in the late 1990s. One of the reasons for this was that, in the late 1990s, many organisations were using the term RAD to describe their delivery method, whether it was actually RAD or not, because it had become the ‘cool’ name in town. This meant that teams and organisations pretended or imagined that they were doing RAD, but did it without actually changing any of their delivery and management culture and behaviours. This led to a lot of failed initiatives that were shaped in a traditional ‘Waterfall’ way (see Section 2.6.3) being described as ‘failures of RAD’ – even though they hadn’t initially been properly set up as RAD projects. Fundamentally, a key point was misunderstood by many people: while RAD itself was easy, transforming to RAD could be extremely complex.

Also, the word ‘Rapid’ in ‘Rapid Application Development’ meant that the immediate and lasting impression was of speed rather than a balance of regular value delivery and quality, which proved inappropriate.

It was not until 2001, when the Agile Manifesto (see Section 1.2.1) was formulated, that a collective generic name and terms of reference that supported all the frameworks was defined, and Agile as a concept was born.

In the same year the first Scrum (see Section 14.2) book was authored by Ken Schwaber and Mike Beedle (Schwaber and Beedle, 2001). The book evolved the basic concepts of Scrum from a seminal paper in the 1986 Harvard Business Review, written by the godfathers of the Scrum Agile Process, Takeuchi and Nonaka (Takeuchi and Nonaka, 1986). Scrum has since grown into by far the most implemented Agile framework in the world.

Since that time, further evolution of Agile thinking has been achieved, and notable more recent frameworks include Lean software development (see Section 14.6) and Kanban (see Section 14.5), amongst others.

1.2 THE AGILE MANIFESTO

As mentioned in the Introduction, the Agile Manifesto provides the single definition of Agile and underlies the development and delivery of Agile frameworks. While its title ‘The Manifesto for Agile Software Development’ suggests that it is only applicable to software development, the values and principles described in the Manifesto can easily be applied to the development of many types of product.

The Manifesto describes 4 values and 12 supporting principles. The values set out in the Agile Manifesto are:

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.

Typically an Agile audit or health check will be performed against the 4 manifesto statements and the 12 manifesto principles. It may also be further refined by the key values and principles of whatever combination of Agile frameworks (see Chapter 14) is being implemented.

In this chapter, we will take a closer look at the manifesto’s values and supporting principles.

1.2.1 Agile values

The four Agile Manifesto statements or values are described next and are further expanded in Chapters 9–12.

1.2.1.1 Individuals and interactions over processes and tools

While processes and tools provide significant value to software development teams and enable them to be Agile, the best processes and tools will not help them to deliver value to the customer without enabled and motivated people who interact effectively as a team (see Chapter 9).

1.2.1.2 Working software over comprehensive documentation

The vast majority of software products require supporting documentation; for example most software deliveries require technical user documentation (see Section 8.6) as without this documentation it will become extremely difficult to support and maintain the software product in the future and throughout its lifecycle. (See also Chapter 10.)

However, while fit-for-purpose documentation is key in an Agile delivery, the focus is on providing working software, and therefore adding value directly to the customer. This means that Agile demonstrates progress through regular visible incremental deliveries of a consistently working product (see Section 10.3). Each and every time a new increment of the product is delivered the customer can be assured that good, agreed progress is being made – and/or be aware in advance of any hindrances to progress. In Agile product development the documentation is kept as Lean as possible (see Section 8.6); only documentation that adds value to the stakeholders is produced and the production of the documentation is synchronised with the incremental delivery of the working product.

1.2.1.3 Customer collaboration over contract negotiation

In Agile it is important to create a consistently collaborative and open relationship between the customer and supplier (see Chapter 11 and Section 11.1), and to ensure that the customer and supplier acknowledge that an effective product cannot be developed without that collaboration. Obviously there are still contracts between customers and suppliers, however, contracts tend to focus on clarifying the collaboration and the working approach between the customer and supplier to ensure they can work together to a mutually satisfactory conclusion. This means that the Agile contract concentrates on enabling inspection and adaptation of the product, prioritisation and collaboration between all stakeholders.

This stands in contrast to a traditional ‘Waterfall’-driven contract, in which the analysis and design stages will produce detailed documents that become fundamental parts of the contract (e.g. the requirement specification, functional specification etc.). The interaction between customer and supplier then becomes a negotiation based on the detailed documents that have been produced. This can create significant friction; for example, it may lead to each party trying to get the other to pay for changes to the contracted specifications. This can become a very significant problem where there is a large amount of change required to the contracted specifications.

1.2.1.4 Responding to change over following a plan

According to About.com, German military strategist Helmuth von Moltke wrote:

‘No battle plan survives contact with the enemy.’ As a result, he sought to maximise his chances of success by remaining flexible and ensuring that the transportation and logistical networks were in place to allow him to bring decisive force to the key points on the battlefield.

(Hickman, 2014)

This principle is replicated in an Agile development: while there is a significant amount of focused planning (see Section 7.3; Chapter 12), this planning is designed to enable inspection and adaptation.

In essence the majority of Agile frameworks align to the following concepts:

• If programme/project plans are required, they are defined at a high level – these are baseline plans that are expected to change.
• If stage (or release) plans are required, they are defined at a mid level – again, these are baseline plans that are expected to change.
• Detailed work package or sprint/iteration plans (see Section 12.1) are commitment plans, the commitment being against an agreed goal (for example, an agreed increment of the product).

This means that up-front project plans and stage plans are not commitment plans; rather it is understood that these plans are forecast best guesses based on experience or factual evidence and change is anticipated as the projec...

Table of contents

• Front Cover
• BCS, The Chartered Institute for IT
• Title Page
• Copyright Page
• Contents
• List of Figures and Tables
• Contributors
• Section reviewers
• Glossary
• Preface
• Introduction
• PART 1 – INTRODUCING AGILE
• PART 2 – A GENERIC AGILE FRAMEWORK
• PART 3 – APPLYING AGILE PRINCIPLES
• PART 4 – AGILE FRAMEWORKS
• References
• Further Reading
• Index
• Back Cover