What is agile in today’s workplace?

What is “agile”?

The word “agile” has come a long way in the past two decades. For many of us, it crept into our consciousness as the title of a collection of practices packaged as a response to the perceived lack of success of traditional, “waterfall” system development methods. Today it is used to describe almost everything in business, usually in terms that emphasise its absolutely essential nature. When I read statements such as…

Agility is the ability of an organisation to renew itself (McKinsey)

Business agility is fundamental to market resilience (Raconteur)

Staying agile is essential to business survival (Raconteur)

Agile ways of working: the only way forward? (Raconteur)

…I begin to worry that I might have underestimated it. It also seems to be everywhere (“Is DevOps possible without Agile?” (PMO Perspectives) – short answer – No!) And then when I have almost convinced myself that it is the most essential thing in the world, I discover that

Agile is not enough (MIT Sloan Review)

Agile seems to now mean three quite different things:

• A system development (and project management) approach;
• A way of personal and corporate working based on employees making decisions about where and when they work, and organisations supporting these through flexible policies and facilities.
• The strategic capability of an organisation to change direction rapidly in response to market conditions (a synonym for “nimble”, a word which seems to have gone out of fashion).

Agile system development

Agile was officially born in 2001, in Utah, USA at a meeting of 17 great minds in software development. United by a dislike for the heavy-duty, documentation-driven system development methods that had been the standard for the past 30 years or so (and given the collective label “waterfall”), they produced the Manifesto for Agile Software Development, and formalised the new revolution in system development.

Waterfall methods are so called because their visual depiction shows the system development activities in a downward cascade, all the requirements development being done before all the design, which is all done before the build, which is all done before….well, you get the picture (and if you don’t, here it is…)

At the heart of waterfall methods is the belief that all the requirements can be known, elicited and documented before any action is taken on that knowledge.

Agile comes from a different place – it does not believe that all the requirements are, or can be, known at the beginning of the project. So, its approach is one of incremental development (hundreds, thousands, maybe more, of small waterfalls, each delivering a small increment of functionality). Where Waterfall makes features or scope the fixed element around which it manages the other elements (time, cost), Agile fixes time, allocating finite amounts of time to solve a planned number of increments (timeboxing). Agile learns as it goes, learns by doing.

Agile is based on four values and twelve principles. They’re well worth reading – I’m not going to repeat them here, but they emphasise the customer, and the continuous delivery of working software to that customer, built by self-organising teams of business and technical people working together and ready to incorporate change no matter how late in the process it occurs.

Agile proponents claim that it is a better, more realistic approach to change (by recognising it can occur at any stage in the development project) and to risk (reducing it by placing more bets on small releases of functionality, rather than big bets on a few).

It’s probably worth mentioning that things aren’t as black and white as the Agilists claim:

• First, Waterfall was not as waterfall as it sounds – I certainly worked within a waterfall method in the 1980s that advocated breaking systems into much smaller releases, usually at the design stage. This gave many of the benefits of Agile, and it solved one problem I see with Agile – that of having no over-riding model or architecture of the system being built. In this regard, Waterfall was a mixture of traditional waterfall in the early phases (requirements, system architecture), followed by Agile for design, build, test, implement. Further, Waterfall did accommodate change – you just went back to where it needed to start and then worked forward again. Project managers learned to leave contingency in each phase for re-work, and learned to incorporate activity, at the end of each phase, to update all preceding phases as appropriate.
• Second, there were certainly Agile-like practices long before that momentous meeting in Utah. My first Agile-like project (we called it Rapid Application Prototyping then) was in 1987 – the build of a job cost control system for a major Canadian building materials firm in just three days, with a small team (user/owner, analyst, programmer).
• Third, Agile has had plenty of its own failures, to rank up there with anything Waterfall managed to do. The DWP’s Universal Credit  is an example (although there is a case to be made that it wasn’t agile enough…); the BBC’s Digital Media Initiative is another. To be fair to Agile, the main reason it seems to fail is because organisations adopt it too superficially, paying inadequate attention to their own culture, and practices (such as procurement), that all reinforce the old world Agile is trying to change.

My view – Agile software development should, and will work, but it needs careful implementation, with attention to the culture of the host organisation, the training of the development and project management staff, and to the development of appropriate governance (yes, there is governance on Agile, it’s just different……).

One thing that is needed is some de-mystifying of the quasi-religious aspects of Agile and some of its ceremonies, beloved, and jealously protected, by its adherents. Agile is good enough not to have to be a cult to succeed.

Photo from Startae Team on Unsplash

Agile working

Work – is it a place we go, or a thing we do? Agile working proponents believe it is the latter. They define agile working as a set of employee-led practices designed to maximise individual efficiency and customer service and value.

To the uninitiated it can sound like “flexible working”, but that’s something different – an individually tailored work pattern that is a benefit to the employee (and often an irritation to the employer). Agile working, by contrast, is focused on the customer value, not the employee benefit, and should therefore be a win-win.

Agile working, done properly, will continuously reconfigure an organisation’s work force, its working methods, its delivery locations and facilities, and its supporting technologies in order to meets its customers’ needs and create value. By making the definition of agile working practices as employee-led as possible, organisations can simultaneously maximise both customer and employee satisfaction.

Some roles in an organisation will always have more flexibility with respect to location, working hours, role deliverable production, and to the need for supervision. But agility applies to just about all roles – agile working is a mindset that once adopted opens us up to many new possibilities.

Photo by Mia Baker

Agile organisations

McKinsey has been one of the most active commentators on agile organisations, which they see as the result of a paradigm shift from the organisation as a machine to the organisation as a living organism. (Readers interested in this shift may also want to consider the work of Arie de Geus, or read the excellent Transforming the Organisation by Gouillart and Kelly.)

McKinsey see agility as a necessary organisational response to the world in which we are increasingly living, with incessant change, disruptive technologies, accelerating digitisation, democratised data and a war for talent making the external environment one of constant flux.

McKinsey have identified five trademark features of such an organisation, and 23 detailed practices. My summary of their five trademarks:

1. A guiding purpose, that guides how value is created for all inside a wider ecosystem of stakeholders.
2. An organisation composed of a network of empowered teams.
3. A way of working based on rapid cycles of incremental development and production, supported by continuous learning and experimentation.
4. A people centred organisation with a high degree of people empowerment.
5. The continuous implementation, integration and adoption of new technologies, for use by multi-functional teams.

While “agile” runs the risk, in this context, of being a bit motherhood (who, after all, is going to say that they are not agile?), its focus on the changing elements of corporate strategy, operations, and decision-making is largely helpful, if occasionally over-dramatic.

Photo by You X Ventures

And after agile?

So, is Agile the apogee of human endeavour? History suggests not, something else will come along; and anyway, the many flawed implementations of Agile (particularly the system development variety) suggest it still has a way to go. But until that Next Big Thing emerges, Agile has a significant part to play in transforming the delivery of systems and technology, and in transforming the organisations that will take that delivery.

The types of failures it has experienced so far suggest to me that the internals of Agile are probably fine. What needs fixing are the external, contextual factors. What do I mean by this?

1. The culture of the organisation has to be right for Agile. This means work by the organisation to understand the problems that Agile is trying to address, and to ensure that the organisation eliminates those problems where they occur in Agile’s environment – this might mean fixing approaches and attitudes to project governance, systems procurement, vendor contracting, employee appraisal processes, etc.
2. Agile development is highly collaborative. Its principles emphasise small teams working face-to-face – agile working, ironically, can make this hard to achieve.
3. Agile is human-centred. (It is little accident that Agile and Design Thinking, with its focus on human-centred design and innovation, have blossomed at the same time.) Its emphasis on collaborative teams means organisations have to train and acclimatise all employees in scope of such projects, business-side as well as development-side.

Waterfall was largely unchallenged for 30 years; Agile has grown in the succeeding 20 years. The best may yet still be to come.

All three applications of “Agile” have commonality in being responsive to change, people centred, experimental, incremental and focused on quality delivery, small and often.