My preferred agile heuristic
What agile should be about and how to judge that
“Agile” is an increasingly worthless term. Almost everyone, from huge government IT projects to diagram retailers are claiming to be “agile”. Here is an incomplete list of things variously associated with agile teams:
- User stories
- Iterations
- Estimating small pieces of work
- Running tests on a central server
- Test driven development
- Work in progress limits
- Retrospectives
- Pair programming
- Regular software showcases
- Meetings where you stand up
- Having a product owner
- Scrummasters, certified or otherwise
All of the above can be useful! But there is an common tendency to categorise a team as agile or not based on their adoption of these sort of practices.
There is also significant top-down pressure to adopt these practices to become agile.
This has lead to a widespread agile cargo cult where practices are copied from other teams without consideration to what really needs to be achieved.
I would like to suggest an alternative heuristic for judging whether a team is agile:
Agile is when you can change how you work, from inside your existing system of work
For example, if a team decides to adopt an extra quality assurance step or bring a user researcher onto the team and is able to make that change without requiring external budgeting or approval, then you’re doing agile.
As a counter-example, if you find you can’t abandon stand up meetings because you don’t have the authority, then you are not doing agile.
The practices listed above were first tried out and then kept because teams could change their activities as they saw fit, using the knowledge they had about what was working and what was not. Any benchmark for agile needs to consider this as the central feature and not whether your legs are tired at 9:39 AM.