Photo by Jack Anstey on Unsplash

What I expect from an agile team

When teams are thrown into turmoil by inexplicable changes in direction driven by outside forces, I often hear them sarcastically laugh and exclaim “That’s ok, we’re agile”.

While I can’t blame them for trying to find humour in an exasperating situation, it does continue to reinforce the idea that agile ways of working involve having no plan, mindlessly zig-zagging all over the place at the whim of stakeholders, and not getting very much done — certainly not as much as you might with a more rigorous methodology and governance.

For those who have had exposure to agile done well, you know that this couldn’t be further from the truth. Agile is adaptive, sure, but it’s also significantly more rigorous in its analysis, evaluation, and retrospection than traditional ways of delivery.

I don’t want to talk about agile methodologies and techniques here but instead want to focus on this concept of “being agile” and the behaviours I expect to see from a team that claims to be agile.

Daily stand-ups, fortnightly planning sessions, and even Kanban boards are all very interesting observable ceremonies and tangible artefacts, but they’re not the first things I look for. Instead, I look for the kinds of behaviours in the list below. It’s not all-or-nothing, but the higher maturity your “being agile” is, the more you’re likely to exhibit these:

1. It’s ok to start something and not finish it, especially if you realise half-way through it isn’t as valuable or impactful as you first thought.
2. What’s urgent is not neccessarily what is important. Sometimes urgent tasks should be dropped in favour of doing the important stuff well.
3. Once the ball is in someone else’s court, you don’t have to follow up with them and chase them for action or response. Sometimes if things fail to gain traction you should let them die.
4. Route around blockers and impediments whether they be people, processes, technological, or physical.
5. Some things are worth doing really well and others deserve no more attention than the bare minimum to tick a box. For example, if the goal is to record the decision of a meeting then don’t bother with formal meeting minutes but just scribble it on a sticky note and place it somewhere obvious.
6. Don’t take someone else’s word that something is important. Everyone has their own agenda. Evaluate critically and probe its true value and impact.
7. The status quo of how information is captured and shared now will almost certainly have to change to support agile ways of working. People will be reluctant to switch from email to face-to-face, and using sticky notes instead of word documents. Push through that discomfort.
8. Ruthlessly eliminate waste; waste of time, waste of resources, waste of administrivia. This doesn’t mean getting coffee delivered to your desk instead of stretching your legs mid-morning just to recover a few minutes of productivity (you’ll probably find that approach has the opposite effect). But don’t accept all meeting requests. Re-evaluate what you can delegate and push back to other people.
9. Be forthright and proactive. Call out waste, call out assumptions. Hold each other accountable and don’t let the team do poor work just because you don’t want to hurt someone’s feelings or risk a confrontation. This is a hard one, but vital. Team leaders should set the precedent, starting by reading Radical Candor.
10. Adapt to new information and feedback. Be actively looking for signals that you’re on the right track and set to deliver the value and impact that was hoped for. The team remains empowered to make decisions, but doesn’t blindly pursue the original course of action when new information indicates a change of course or perhaps even a pivot is needed.
11. Show and share your work early and often. Invite participation, but avoid scheduling showcases and formal collaboration touchpoints. Just stick it up on a wall and make it clear you want people to contribute. Describe your intention, your thinking, and what specifically you want critiqued. People will often gravitate to the easy stuff like proof-reading when you’d really prefer they comment on the structure and relevance.
12. Redundancy. Don’t put your team in a position where they have to say “Oh, he’s had to take leave unexpectedly and I don’t know where he was up to with that so we’ll have to cancel the sprint demonstration”. Work in the open, make sure everyone is across everyone else’s work well enough to talk about it. Opt for smaller self-contained chunks than large artefacts that have no value until they’re completed, even if the latter seems more efficient. If you’re working with code then check it in frequently.

These are the sorts of behaviours I expect to see from teams who have adopted agile ways of working. If you’re doing sprints but barely talk to each other during the sprint then you might not actually be working agile, at least how I consider it.

What else might you add to this list?