The beginners guide to agile

Barbara Roberts of the Agile Business Consortium looks at the fundamentals of agile and agile project management:

Before the 1990's, the IT world was limited by what computers could do. This was less of a problem in a world where stability and minimal change were normal. Solutions were designed by IT experts based on formal speciﬁcations and with little or no ongoing business input. As a result, they were all too often delivered late and over budget, and didn’t work.

The arrival of RAD

In the late 1980s, the arrival of the early PCs started a change. Suddenly, developers could build solutions quickly by talking directly to business people, and, after a series of conversations and feedback, actually deliver something that exactly ﬁtted the business requirement. This was termed rapid application development (RAD), and quickly became popular. But it soon became apparent that RAD had underlying issues.

Although the focus on rapid delivery and user involvement was a huge improvement on the traditional style of working (sometimes referred to as ‘waterfall’), the omission of factors such as control and quality led to a perception of RAD as ‘quick and dirty’, rather than a sustainable, mature approach.

Corporate-strength RAD

In 1994, the DSDM Consortium (now called the Agile Business Consortium), a UK-based not-for-proﬁt organisation, captured the best practice for RAD, based on analysis of good (successful) and bad (failed) examples from a wide range of organisations. From this, it built a mature, scalable and sustainable RAD approach that brought ‘rapid’ and ‘user involvement’ together with ‘control’ and ‘quality’, applicable not only to simple, small pieces of work, but also to complex projects in the corporate environment.

Between the 1990s and 2001, RAD continued to grow in popularity, leading to the birth of similar approaches,such as scrum, extreme programming, lean, feature-driven development and many others.

Although each approach has a different focus, all share common values around:

active business engagement throughout;
collaborative teams – ‘one team’ culture that includes technical and business people;
conversations and feedback loops to evolve the solution;
incremental delivery of the solution, rather than the ‘big bang’ approach; and
an expectation that change is expected and treated as ‘normal’, rather than something to be avoided wherever possible.

RAD becomes agile

There was growing unease in the RAD community that RAD was the wrong term. Having ‘rapid’ as the ﬁrst word led to a perception that the most (or only) important factor was speed. Some also took this further, expecting RAD to deliver the impossible in half the time, ‘because it is RAD’. So representatives of the key RAD approaches worked together and launched agile to replace RAD.

The basics of agile were deﬁned in the Agile Manifesto. This highlights the importance of:

Individuals and interactions OVER Processes and tools.
Working software (solutions) OVER Comprehensive documentation
Customer collaboration OVER Contract negotiation
Responding to change OVER Following a plan

This does not mean the items on the bottom are unimportant, but rather that the items on the top take precedence. And although the manifesto refers to ‘software’, agile is equally applicable to any type of solution.

Why choose agile?

In the modern world, agile approaches are far better suited to our demanding, fast-paced world: an environment where change is the only constant – eg changing technology, changing business models and changing customer needs. Unlike the more static business world of the 1990s, 21st-century businesses need to be ﬂexible, adaptable and responsive to change if they are to survive and be successful. Agile is not a binary ‘yes/no’ concept whereby ‘agile = good’ and ‘not agile = bad’. In reality, there is a spectrum of choice, ranging from extremely agile (sometimes called ‘edge of chaos’) to extremely traditional (heavy bureaucracy and process).

The important thing is to position projects at a point on this spectrum that balances beneﬁts against risks. For example, anyone working in a highly creative space does their best work when there are few rules. Edge of chaos is a wise choice here. By comparison, an organisation creating aircraft equipment cannot afford to work outside stringent rules, as people’s lives are at stake – so formality and control are far more important than extreme creativity. In these examples, each choice is sensible and valid.

Even in the most safety-critical environment, using some agile techniques can add value without introducing risk. Agile should be all about making the right choices.

Agile projects

The Agile Business Consortium has always focused on agile in the context of project delivery – unlike many other agile approaches – because it has always considered software in the wider context of business change. In 2008, it created the project management-focused AgilePM®, which brings together all the elements of a project in an agile context:

principles (the behaviours);
people (roles and responsibilities);
process (the life cycle);
products (what is produced and when); and
practices (timeboxing, modelling, iterative development, prioritisation and facilitated workshops).

This is supported by additional information on what agile means for topics such as requirements, estimating, planning, risk and preparing for success. Together with the Consortium’s track record of successful agile in even the most complex regulatory environments, this has helped dispel the misconception that agile is only suitable for SMEs.

Agile project management principles

These principles highlight the types of behaviour needed for delivery of a successful agile project:

Focus on the business need: Achieved through active business engagement and ongoing prioritisation
Deliver on time. Time (and cost and quality) is ﬁxed; features are negotiable (driven by business priorities)
Collaborate
Never compromise quality
Build incrementally from ﬁrm foundations. First establish the foundation, then create the solution and the value incrementally
Develop iteratively: Use regular feedback to reﬁne the solution
Communicate continuously and clearly. Conversations and demonstrations as the ﬁ rst choice
Demonstrate control. This applies to everyone in the team, since they own the plans and the estimates

Benefits of using agile

There are many documented beneﬁts of using agile. Examples include:

business-focused solutions – putting business in the driving seat;
delivering a solution that ﬁts at the point of delivery, not what people thought they wanted at the start;
ability to change as you go on (within reason);
delivering value early and often;
delivering a basic working solution and then builds on it, which reduces risk;
building a collaborative environment, which is more productive and more motivating; and
getting the best out of people and teams.

Some agile myths and misconceptions

You can deliver the impossible in half the time.

Clearly, this is untrue, as the laws of physics always apply. If a solution contains 18 months of work, agile cannot compress that time frame into three months. What it can do is:

- shorten the communication channels – building in short feedback loops ﬁ xes issues early before they become project stoppers; and
- prioritise to deliver high-priority/high-value items sooner;

You can change your mind whenever you want

Although agile welcomes change, not every change is viable. A good analogy is a building project. The initial stage agrees rough ideas and a rough budget. This is then elaborated into a plan that is submitted for approval. Once the council approves the plans, certain elements are then ﬁ xed and cannot be changed lightly – eg footprint (shape and square metres), height (two-storey building/bungalow) and materials (brick/stone). This forms the foundations of the project, and changes to any of these need serious consideration and, once the build has started, may actually be non-negotiable.

Finally, consider DSDM’s wise words: “You can use all of agile some of the time; you can use some of agile all of the time.”

Read about more agile myths and misconceptions

This article was originally published in the Summer 2017 edition of Project journal