I find it useful to treat agile software development as an outcome, rather than something we can adopt. Taking that perspective, we can invert the problem and ask:
What is making us less agile, right now?
The answer is often surprisingly tangible, and rarely about missing agile methods. It is about the concrete friction we encounter when trying to get work done. For example:
- Slow builds
- Deployment dependencies
- Cumbersome software architecture
- Recurring manual verification of changes
- Hand-overs
- Silos
- Gatekeeping
- Firefighting
In high friction environments, making decisions is risky. Change is slow, therefore making bad decisions is expensive, and therefore more time is invested in planning in order to avoid bad decisions. In the worst case, new controls are introduced, resulting in more friction. These environments become less agile over time, regardless of any agile method.
To break this cycle, fixing obvious sources of friction is often easier than reaching for new process:
- Reduce pipeline times
- Enable continuous integration
- Enable ad-hoc production deployments
- Enable self-service infrastructure
- Simplify development environments
- Fix regular sources of bugs
- Add automated checks
- Increase observability
- Disband committees
- Training
This list is widely applicable; none of these actions require organizational change, but will make most organizations more agile (as in, able to react and adapt to new information more effectively).
Interestingly, most agile methods are all about avoiding friction, if you read them carefully. One could even argue that friction is just the other side of the same coin.
However, reducing friction, as an explicit approach or as a goal, is inherently simplifying and empowering. It is a natural driver towards less overhead. It is descriptive and actionable, not prescriptive. It is easier to rally behind removing friction than to convince an organization to adopt new process, roles, or ceremony, which is almost always disruptive.
Note that friction is not a set of things to optimize individually. Some friction can be good in the long term, and there may be complex interactions between different kinds of friction. Mandatory code reviews, for example, can be considered an expensive slowdown, but can act as training.
Managing friction is a design problem, and should be a first-class citizen of any software development strategy. True agility emerges when friction is low, while process, roles, and ceremony should be of secondary concern. ∎