What, exactly, is agile?

Today in class, one of my students asked the seemingly straightforward question, “what is agile?”. This got me thinking – what is the most fundamental aspect of agile? My unorthodox view is that agile is simply the name given to the bundle of values and principles that result in more successful outcomes in software development. Agile is the better approach, by definition.

The agile concept has become muddied by implementations driven by misinterpretation. For example, many managers are sold on agile by the promise of getting more work out of their staff in less time. They end up building scenarios that focus on wringing as much work out of the dev team as possible, burning them out in the process.

With that in mind, let’s take a step back. What are some of the practical indicators of a team practicing real agile?

• Small projects, where it is easy to fully comprehend all parts.
• Team members genuinely caring about the project. They have a connection to the work and to the customer.
• Team members working in physical proximity to each other.
• Automating as much rote work as possible, resulting in very little manual rote work. Most activities are novel and creative.
• Having plenty of time to do the work, with extra time left over for trying innovative techniques, reorganizing, refactoring, and reflection.
• Professional pessimism is common – there is always a better way to do things.
• Having total autonomy and trust from management to change the team’s process and tools.
• Keeping things as simple, lightweight, and easy as possible
• Possible to completely describe the depth and breadth of the work to be done in an iteration.

This is not the whole list. However, these patterns are some of the most uniquely agile.

In contrast, here are the characteristics that are typically seen by companies following “agile in name only”

• Teams driven to get more done in less time.
• Old roles with new names – for example, “project manager” becomes “scrum master”.
• Too many meetings
• Feeling disconnected from the customer, and rarely or never coming into contact with them.
• Not caring about or understanding the value of the product.
• A general sense of irony or hypocrisy. For example:
• Mission statements extolling the benefits of continuous improvement while scrum masters tell their team that the requested improvements cannot occur because “we have to learn to live with what we have”
• Directives that imply autonomy while simultaneously enforcing the traditional command-and-control corporate hierarchy.

This is not the whole list, but there are some of the patterns most unique to companies trying to follow “agile in name only”

Given this reality, it occurred to me that a company is able to make progress towards agile by adding the good parts in piecemeal fashion. How hard would it be to get your dev team in contact with real customers? Could you have more people co-located? Perhaps trying for a real MVP – minimum viable product – as an exercise. (In particular, crafting an MVP is a great opportunity to see how wildly different agile pacing is, and needs to include an experienced practitioner). Perhaps an upcoming big feature could be an opportunity to create as its own separate project, having its own build pipeline and release schedule.

Strategies for greater effectiveness had been discussed and applied since the earliest days of software development. What set agile apart was the shared understanding on these techniques by some of the most mindful and collaborative developers of their generation. They convened to decide on the intersection of their respective views at Snowbird ski resort, Utah in 2001.

Some of the programmers involved in these discussions, like Kent Beck, had spent time experimenting with novel techniques to increase productivity and morale. Kent’s book, Extreme Programming Explained (a short read, and well worth your time, by the way), went a long way towards promoting creativity and innovation in the field.

After lengthy consideration and vetting, the discussions resulted in a shared understanding of a set of values and principles which make up the Agile Manifesto (see http://agilemanifesto.org).

The benefits paid by adherence to agile techniques was a repudiation of the cumbersome and numbing approaches that business had traditionally applied to the software development process. To a great degree, agile allowed teams to achieve their business and personal goals, opening the door to compounding innovation and continuous improvement.

Purely by good luck, I started my career in an organization that primarily followed the strategies described by Beck. All the promised results were seen:

• Morale was high.
• A team of seven developers was successfully competing with companies employing ten times that number.
• We had a sense of community and valued each other highly.
• There was little sense of the isolation and disaffection that I have often encountered in several subsequent positions.

Since then, I have seen many companies that claimed to be agile but were not really. Rather, they carried out actions that reinforced misunderstandings and hurt the teams.

For instance, many companies decided that to become agile meant solely renaming roles – the team lead became the “scrum master”, the product manager become “product owner”.

In those companies, the ceremonies were often misunderstood and pointless. For example, retrospectives as pressure release valves, to complain about things the team could not change, and to give kudos to one another for good work carried out in the otherwise difficult circumstances. Standups that were thirty minutes long.

Does that seem familiar?

Where I have seen agile implemented properly, practices were followed that were non-intuitive but effective. A couple examples will help:

It is a known statistic (2015 Chaos report) that the smaller the project, the higher the likelihood of success – by a significant margin.

” It was clear from the very beginning of the CHAOS research that size was the single most important factor in the resolution of project outcome.” — 2015 Chaos Report

Relatedly, brain experts have shown that human minds typically have a small capacity for short-term memory, and do not function well with multitasking.

Therefore, agile promotes small teams, working on the simplest possible thing, on small timeframes. This means that it becomes possible to wholly understand a thing. Interactions with the team resembled that of dealing with a vendor and their product. The ethos is “small is beautiful”.

The minimum number of tools and frameworks are used, in order to remove cognitive load. Overloaded teams have a much harder time producing quality work than teams that are appropriately loaded. It turns out that software is actually a really hard thing to get right. By having more reasonable load, teams can focus on quality instead of quantity.

A second example: business experts have shown that team members who have a strong sense of empowerment and autonomy are likelier to have innovative solutions, and to have higher morale. Disenfranchised employees tend to have higher stress and lower morale, and burn out more often.

Therefore, per agile, teams are allowed to have significant autonomy with their environment and process. Keeping the overall company mission in mind, they often rebuke attempts to directly control their actions or tools, and they are supported in doing so. This stands in stark contrast to the typical command-and-control management style, wherein a manager gives an order and expects it to be carried out expediently, exactly as requested. Management of these agile teams required a nuance and appreciation for the productivity that results from empowerment.

These examples – smaller projects, simple work, and empowered teams, reflect several of the principles in the Agile Manifesto:

From the values:

• Individuals and Interactions over processes and tools

From the principles:

• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Simplicity–the art of maximizing the amount of work not done–is essential.
• The best architectures, requirements, and designs emerge from self-organizing teams.

(See the Agile Manifesto for the entire list of 4 values and 12 principles)

Bundling these ideas together, taking them to their logical conclusions, and considering the supporting concepts, leads to agile.

Succinctly stated, and to repeat, agile is simply a name attached to a bundle of practices that have shown to be far superior in industry than the ideas that stemmed from early era industrial practice, which themselves originated from a culture of mass production and low-skilled factory workers. That simply doesn’t describe the work environment surrounding software development.

The question is: knowing this, how is it possible to jump the gap? The fact is, agile is a very sociological thing. It can only exist when the right combination of elements work together. Unfortunately those elements are rare and fleeting.

It has been my good fortune to have seen it functioning in its ideal state throughout an entire company – but that company was founded and run by a developer who believed in his people and in the tenets of Extreme Programming.

Separately, I have seen it come together on a team in a typical corporate environment, but the leader of that team was dealing with stress as a result of the contrast between the inside and outside cultures.

In both situations, agile eventually degraded into a lower form.

In the first case, the company grew larger and the founder sold it, leading to an organizational shift to traditional corporate governance. In the second, the team’s lead quit in frustration, and the subsequent manager had no inclination to maintain an agile culture, causing its loss.

It’s a rare thing to see real agile, and it requires vigilant tending and careful appreciation of the myriad aspects that make it up. In small ways, you can create pockets of good practices that can be very empowering. If you start or run a company, you have the chance to make those pockets into enduring company-wide cultures. But I won’t lie and say it’s easy. It’s a constant battle.