Agile methods... do they make sense outside of IT?

Photo by Annie Spratt on Unsplash

"Agile" - a type of work methodology that you must have heard about over recent years - was first defined in the IT sector in 2001. That year a group of 17 developers made waves in the world of software development when they wrote and published the Agile Manifesto. The status quo was challenged: a rejection of formal bureaucracy, a revolt of doers over thinkers, a new way of working, a new way of relating with each other, etc.

All the ingredients for a (pacifist) revolution were present and the revolution did happen. Nearly twenty years later, practically everybody has adopted agile in one way or another and there is a pretty unanimous understanding that it has made things better: better for team spirit, innovation, well-being, relevance and productivity.

Today agile methods are sought after by companies in other sectors searching to foster these values in their workforces. In this article I will look at the four founding values of agile in this context of their possible application in non-IT sectors. The four values are:

1. Preferring individuals and interactions over processes and tools
2. Preferring working software over comprehensive documentation
3. Preferring customer collaboration over contract negotiation
4. Preferring responding to change over following a plan

Agile also has twelve principles that are more precise than the above four values, which I will cover another time as they are less directly transferable outside the IT sector. In this article I will put the birth of agile into context, which will help as we reflect on how this methodology might be useful beyond the IT sector.

The four values of agile

The Agile Manifesto is based on four fundamental pillars that outline a hiearchy of value among elements linked into twos. While the elements on the right hand side are valued, the authors of the manifesto declare that their experience in software development leads them to value more the elements on the left hand side. Let us look at each of these pillars in context and come up with some open questions to help assess their flexibility to be mirrored in sectors outside of IT.

Preferring individuals and interactions over processes and tools

Building non-trivial software is as complex as it is creative. A crucial component to this work is the definition and understanding of requirements (with a focus on problem-solving). Writing software requires creativity (to explore all possible solutions). While the theoretical foundation of software development was laid down between the 1960s and the 1990s, the tools and processes that came about at the same time slowly proved themselves to be... a bit too theoretical. The whole thing - the whole way of working - tended to create a chasm between those who understood the problems (the users and/or clients) and those who built the solutions (the developers). This was also a physical distance: everyone stayed in their offices, behind their respective computer screens. There was a hierarchy wherein programmers were at the bottom with analysts at the top.

Then the agile manifesto came along and upended everything: human interaction is the main solution to complex problems requiring creativity. All boundaries - temporal, physical, and hierarchical - needed to be broken down.

An agile team is typically made up of 4 to 8 people with well-defined roles, organised horizontally and generally located in the same place, autonomous in its decisions, and ideally suffused with a spirit of trust and mutual respect.

How are things in your sector, project or organisation?

• Are there silos to deconstruct? Is there a lack of good interaction?

• Do you think it would help to reconsider the typical timeline you have for a project?

• Do you recognise any ways in which users or clients could become closer to those who are creating the solutions to their problems?

• Can you see any hierarchical lines that are cutting through a team's capacity to work and build solutions in an atmosphere of trust?

Preferring working software over comprehensive documentation

for many years software development was inspired by other engineering disciplines where a problem and its solution are carefully analysed and designed at length before beginning to think about creating the solution. As a complete understanding of the result of this stage of analysis had to be transmitted to the developers of the solution, the analysis phase naturally led to the production of a lot of written documentation. Unfortunately very few human beings can reflect accurately in a purely abstract way when the subject matter is intangible (as for software). It was therefore common for analysis to be incomplete or mistaken, and for documentation to be partially-read or even ignored by the development team. It was also difficult for users and clients to get through mountains of documents and review hundreds of pages of specifications. This approach rarely worked well.

The agile manifesto again challenged the entire paradigm. Human beings excel in confronting theory with practice. So best create software in an incremental manner (something discovered well before agile, for example by F. Brooks), then put it into the hands of real users who will actually use the software and be best placed to give feedback on the required adjustments.

This is how modern software development came to insist on successive iterations of development, each iteration ending ideally by making available to users a tangible, valuable result. The importance that agile development accords to testing (automated) is linked to the same objective: incrementally to build quality software without regressing along the way.

How are things in your sector, project or organisation?

• Can things develop in a more incremental way? Is there a way to put results into the hands of users and clients for validation more frequently?

• How do you make sure that your analysts' ideas are properly tempered by reality?

• Is it possible to build things without having to undo them / possible to build things without regressing along the way?

Preferring customer collaboration over contract negotiation

The amount of money required to develop non-trivial software is significant and so there needs to be a precise list of specifications, strict deadlines, and a well-defined budget, in advance. However in reality the specifications are never accurate enough, deadlines are never met, and the budget never enough. Another way of approaching things is needed.

Again, the agile manifesto declared a new way to do things, even if this founding pillar of the manifesto is the one least-often strictly adhered to. The idea is simple (in theory): rather than spend hours negotiating all the fine details, why not aim to develop mutual confidence and trust. The client, through being involved directly in the project, will steer it in a direction that generates value for himself, for his company or for his own clients; the service provider undertakes, through their professionalism and agility, regularly to provide successive quality versions of software aimed at generating the required value.

How are things in your sector, project or organisation?

• Do you spend a lot of time negotiating? If so then are these hours really creating value?

• What risks justify the time taken to negotiate and the time taken to put the outcome of these negotiations down into documentation and contracts for reading and signature?

• Are you invested in mutual trust, and if so then do you regularly review this relationship of trust?

Preferring responding to change over following a plan

In any big project it is common to see plans to follow detailed specification manuals, master plans, gantt charts and other kinds of theoretical concepts that lay out an ideal path of development. In the past, deviating from the master plan in software development was seen as a serious error. The client saw any change of idea or opinion as something that called everything into question and messed up carefully negotiated budgets, deadlines and agreements. From the developer's point of view deviating from the master plan meant circumventing or ignoring the specifications, deadlines and budget... and that made things dangerous from a contractual point of view.

But following a carefully laid out long term plan is not ideal when it comes to software development: there are too many uncertainties, too many facets to the problem, and too many aspects to the solution to have the time to know and deal with all of them on paper. Agile shifts the perspective: since everything is uncertain, let's say that having a plan is good but that being able to adapt to reality is better. On the basis of mutual trust, and respecting a few rules that dictate at what stages change can happen, agility advocates for plans that are less precise but are reviewed more regularly.

How are things in your sector, project or organisation?

• Is there a tendency often to come up with long plans that prove over-ambitious or unrealistic?

• Would it be possible to make less detailed plans, and then to adapt to what's going on on the ground more often?

• What needs to happen for people to start seeing change as an opportunity rather than as a problem?

• Is it possible to develop mutual confidence in systematic wethods to manage and use uncertainty in the development process?

Conclusion

This article on agile has looked at the four pillars of the methodology. These pillars make a distinction between values - a hierarchy of value. The idea isn't to reject processes, tools, documentation, negotiation and plans; the idea is that when possible we should prefer interactions between individuals, concrete results, trust and collaboration, and incremental development based on feedback and adjustments.

The agile manifesto is nearly 20 years old. While many sectors today borrow values and methods from agile, it is important to revisit the founding hypotheses from a critical viewpoint, to make reasonable and clear analyses as to the real value inherent in agile. The open questions listed above should be helpful to gain some first insights into what might be applicable to your sector and what might not.

During an event for the pharmaceutical industry in which Klaro is used, I had the opportunity to give a talk on the history of software development and the place of agile in this history and in innovation. Here is a quote from this presentation to elucidate a way to consider any possibility of using agile methodology in sectors outside of IT:

Agile was born in a sector in which managing uncertainty is important in general, even central to the success of a project.

Agile methods are particularly efficient when the risks of a trial-and-error approach are low, and can even be transformed into opportunities.

Probably more than any other method, agile is based on trust in a team or between teams, and on human intelligence.

I will write another piece on the intrinsic risks posed by the hierarchy of values that make the foundation of agile. Subscribe to our newsletter below to be kept up to date.