There is an interesting discussion on LinkedIn on “minimally viable agile“. What is the bare minimum that a team should do in order to be considered agile? Should a team do standups to be agile? What if they don’t do standups, does that mean they are not agile, or is it possible to be agile without it? What does it even mean “to be agile”?
This is a topic that comes up every so often without fail. Here are some approaches that are inevitably put forth. I have ordered it in terms of my personal preference, from my least preferred approach to my favourite.
It’s agile if it includes these practices
This school of thought professes a set of practices, like standups or retrospectives, which need to be followed in order to be agile. So, if you aren’t doing retrospectives, then you aren’t agile. The problem with this approach is twofold. First, there are many different agile processes–Scrum, XP, Kanban, FDD, Crystal–and each has its own set of practices, with only very small overlap. So it is hard to nail down a set of practices which MUST be followed. Secondly, there are so many teams that follow ALL the practices, but someone who observes them would not call them agile. Maybe they are co-located, but they dont talk much. Maybe they are developing software incrementally, but rarely release to production and get user feedback.
It’s agile if it follows the manifesto
Another school of though is that it’s not agile if it doesn’t follow the manifesto. Individuals over Process, etc. But there are problems with this approach because it is just too vague. How do you really tell if a team is following the manifesto? The manifesto is a very high level vision statement rather than something actionable where you can go and say, “Yes, this team is following the manifesto”. It can also lead to strange situations, for example a team doing cowboy coding, because the team members just feel like it, would be better aligned to the letter of the manifesto. After all, it is the individuals who have decided to dump the process. But it is hard to think of such a team as being setup for success.
The 7 properties of successful projects
If a set of practices is too constricting, and the manifesto is too vague, then what is the solution?
My guide has been Alistair Cockburn’s excellent 7 properties of successful projects. Crystal Clear was one of the very first books I read and it made a very strong impression on me, and I’ve been carrying this list around ever since. Unlike other thought leaders who are mostly working from anecdotal experience, Alistair’s list comes from specific research into successful projects. Based on this research he identified 4 core properties that most successful projects possess, and 3 additional properties that improve the chance of success, but are not totally critical (ie, it is harder, but possible, to succeed without them).
Here are the 7 properties (top four are the core properties):
- Frequent Delivery: Do you deliver software to production, at least once a quarter?
- Reflective Improvement: Do you take time to look back at how you are doing, and where you can improve?
- Osmotic Communication: Does it take less than an hour to get the answer you are looking for?
- Personal Safety: Can you give people bad news?
- Focus: Does the team know what their top priorities are?
- Easy access to expert users: Does it take less than three days to get an answer from an expert who understands the customer?
- Strong technical environment: Does the team have automated tests, frequent integration, etc
There are two things that I love about this list.
First, they are outcome based. Take Osmotic Communication for example. Maybe one team might want to make it happen via colocation. Another team might be distributed, but ask all the team members to be online on team chat. Both practices can deliver on the goal: Does it take less than an hour to get the answer you are looking for? Conversely, there may be a team where everyone is sitting together, but they work in isolation without talking. If a team member has a problem, he tries to solve it himself for days without asking anyone. Such a team might be colocated, but they don’t have osmotic communication.
The second thing I love is that it is easy to evaluate. It is not a pie in the sky vision statement. It is specific, and you can easily go to a team and say whether the delivery frequency is good or not, whether communication channels are good or not, etc. It is a great way to figure out where a team stands on the path to agility.
Best of all, it is practice agnostic. This list is applicable whether the team does Kanban, or Scrum, or some custom hybrid.