We sometimes talk about “bad smells” from digital teams: indications that not all is well. This is a list of the ten most pungent odours I’ve encountered. I wrote this because I hoped that it might help people identify issues and improve things. Please feel free to take this and iterate it; I’d love to know how you used it and improved it.

1. Do you know what you’re delivering?

My favourite question to ask at the beginning of a service standard assessment is “can you sum up this service in a user story?” Can you say that you know the scope of what you’re delivering and what this will allow to happen and for whom? “As [this organisation], I want to [deliver this service] in order that [users can achieve this outcome]”. Teams that can’t answer this question are usually – often for good reasons – trying to deliver too much in one go and are struggling beneath the weight of everyone’s expectations.

As I’ve worked with more teams, I’ve come to a view that clarity around a shared goal is a key part of team health. That’s not the same as group think, or a single view of the world, but it is a shared commitment to an outcome. Without that, then you have room for confusion at best and politics between multiple visions at worse. Worse, no single view of what you’re delivering means you also have a scenario where success is never possible, and that’s not a good place to be. If you asked three different members of the team what they’re delivering and for whom, will there be a consensus in their answers?

2. Do you all agree on your status?

I once took over responsibility for a project we’ll call project x. It had been running for around a year. I went and spoke to the people involved in project x to find out about it. I spoke to the project manager, I spoke to the senior sponsor, I spoke to the external company who had won the contract to deliver it, I spoke to the agile coach, I spoke to the organisational product owner, I spoke to a tester, I spoke to the head of digital. And they all told me different things. When I say ‘different things’, I mean that their verdict on the status of the project varied from “it will deliver on schedule next week” to “at no time in human history will this project ever deliver”.

It took me a while to realise that this was a feature and not a bug. Lots of people knew what they wanted the status to be in order to fulfil their needs, but no-one knew what the status actually was. When I looked more closely there were at least three entirely separate sets of backlogs, plans and associated progress reports. What we did was to combine them all and agree one physical backlog on a board, where any changes or progress were transparent and visible to all. Not entirely surprisingly, this uncovered some issues that weren’t on any of the multiple existing plans. There were attempts by people with power to ignore or diminish this new approach in favour of their preferred approach but that’s difficult when everyone can see and verify a source of truth.

Only once we had the board did anyone have any clue about what we were actually going to deliver, and when. If people don’t agree on your status, you’ve no chance of getting anyone to agree on what happens next. And if people don’t agree on what happens next, then you’re likely to get stuck. Next time you hear a different story about a project from two different sources, don’t criticise it; find out why.

3. Do you know what the most difficult bit is?

The riskiest assumption in a piece of work can vary. For some services, it can be infrastructure; for some, it is service design; and for some it’s nothing to do with the service itself, it’s getting users to come to the service in the first place. I’ve seen UK-wide services demoed that:

• look brilliant but have a significant architectural restriction on running for more than 20 concurrent users;
• don’t allow the majority of users to make it from one end of the service to the other;
• were created with a “build it and they will come” ethos, so haven’t thought about how users will find the service in the first place or even why their service is better than other competitors (usually, these people end up spending a lot of money on Google Adwords).

What doesn’t vary is that the riskiest assumption is the factor that can spell disaster for your work most easily. If you want to check whether your team is blindly following orders down a rabbit hole, or is empowered to take decisions to ensure the delivery of a good service, then ask what the most difficult bit is.

4. Have you delivered recently?

In case anyone thinks that this is where I talk about Agile, how it’s amazing and how it ensures that your team works perfectly, it’s not. I think this one relates equally to Waterfall and Agile environments. In both methodologies, teams commit to delivering things at certain points and you can either deliver or you can come up with excuses.

The only thing that changes between methodologies is the type of excuse. In Waterfall environments delays tend to get explained away by an ever increasing focus on a far off delivery date (“this is all academic, anyway, it doesn’t affect anything – as long as we deliver the REALLY IMPORTANT THING in two years time, everyone’s happy”). In Agile environments, what tends to happen is other stuff gets dressed up as deliveries (“we didn’t meet our sprint goals but we did discover SOME REALLY INTERESTING FACTS about this random technology, so that’s OK”).

It doesn’t matter if the last thing that should have been delivered was a work package, a chunk of Kanban work, or a sprint/iteration: was the last one that the team was supposed to have delivered actually delivered?

5. Have you delivered consistently?

In the short-term, it’s easy to cheat. You can inflate productivity by pushing a team, by threatening a team, by augmenting a team, by giving a team overtime, by telling the team to ignore all bugs and testing, by shutting a team in a room and not letting anyone else in, by telling a team that the fate of the organisation (or, you know, all humanity) hangs on their efforts, by buying a team pizza and beer, by – you get the idea. None of these factors works in the long-run. All product deathmarches finish somewhere; the only choice you get is whether you stop before you lose the goodwill of everyone involved.

When the authors of the Agile Manifesto talked about sustainable development involving teams that were able to “sustain a constant pace indefinitely”, they were making a far wider point about healthy teams. In my experience, mature teams are prized in organisations for being trustable but – above all – for being predictable. What were the last 3, 5, 10 deliveries from your team and how similar were they?

6. Have you pivoted recently?

Change happens. It takes most teams a while to realise that reacting to it, rather than ignoring it and hoping it goes away, isn’t a sign of poor planning but is a significant positive. Heck, it’s taken me a while to realise that I shouldn’t be apologising for constantly doing end of phase retrospectives where I say “and here’s where we made a big change because things didn’t turn out the way we thought they would”.

Well-lagged pipes protect against changes in temperature and keep running, good teams handle change smoothly without cracking. What was the last time you made a change in direction and how did it go? If you haven’t made one for a long time is that because you don’t need to, or because you’re not able to? Tip: if it’s because you can’t, then what you’re building is probably not what your users need.

(Again, I’ve used the term “pivot” here but you can take this to mean “change in direction” and this happens regardless of methodology. In Waterfall, the ability of your change control processes to assess, manage and implement change and not just ignore it, or prevent it, or sneak it in when no-one is looking is as important as the ability of Agile delivery people to properly manage and scope change.)

7. Have you talked recently?

Of all the possible “canary in the mine” tests in this list, I think this is the most important. Whether you want to call them retrospectives, team meetings or something else, an opportunity to come together as a team and reflect on how you work – not what you’re working on – exists in all methodologies. And the common pattern I’ve noticed is that it’s really, really easy to avoid doing these.

I once worked as part of an area with a number of agile multidisciplinary teams, where I discovered that there had been no retrospective on any team for over six months. It turned out that the delivery managers didn’t want to run them, mainly because they were concerned about the possible negative feedback. I agreed to run one: it was messy, it was difficult, it was too big, it ran over, and it established that some people were unhappy. More importantly it established that people needed a break and that – if we wanted to deliver anything – we needed a pause first to avoid burning people out. If we hadn’t done it, we’d have planned for something we wouldn’t have been able to deliver, and we would have harmed, rather than increased, the trust team members had in the planning process.

If the reason that people avoid talking as a team is that they’re concerned about what will happen, then it’s one of the most vital functions of leadership to make sure that those conversations do happen and that they happen in a safe space. If it’s messy, that’s because you’ve waited too long: the longer you wait, the messier it will get. I sometimes ask service teams in assessments “can you give me a recent example of a change that you’ve made to your ways of working as a result of your retrospectives?” That’s a good question to ask to check that your team is functioning well.

8. Is it safe to talk?

It’s not, of course, enough to just talk. How you talk also matters. Amy Edmondson talks about “dangerous silence”, where people have important and valid input that they don’t ever give because they don’t feel that it would be welcomed. People need psychological safety – “a belief that it’s OK, in fact it’s expected, to speak up with concerns, with questions, with ideas, with mistakes” – in order to be able to contribute.

Diverse teams are incredibly important in designing for a diverse world. We sometimes miss the fact that it’s not just important that your team is diverse; it’s important that your team has diverse voices that have an equal opportunity to voice an opinion. I’ve been in too many teams that are diverse by membership but narrowly uniform in leadership.

Is it safe to talk in your team? If it’s not you’re missing input and creating stress. When was the last time someone told you something difficult, and what happened?

9. Where is the data?

In any team, there are disagreements. In some teams these can carry on for a long time, washed to and fro on currents of subjective opinion. What I’ve noticed about the best teams is that they step towards the disagreements, not away from them, and that they find ways to inform the discussion.

How do you inform a discussion? With data. Data can come from a prototype, from user research, from analytics, from multivariate testing, or even – as I once did – by pulling a random front line member of staff into the middle of a planning meeting and asking them to describe what actually happened when they used the service in question. The next time you find yourself in the middle of a disagreement, ask what data you could find to help resolve or reframe the discussion.

10. What happens when someone leaves?

What’s the one event that can tell you more about a team than any other? In my experience, it’s how the team reacts when someone leaves. Perhaps because it’s a rare example of a scenario where you don’t get an immediate payoff for being kind, it’s an effective litmus test for how a team actually cares for people. It’s also an indicator of how well a team is able to handle change.

I’ve been in teams where a long-term member leaving has been announced at an all team meeting by someone as “and I have another bloody problem because person y is leaving” and I’ve been in teams that have taken time out to properly recognise the contributions of short-term contributors. I’ve been in teams that let people in the same role consistently leave without ever checking to see whether there’s a common reason for people in that role leaving and I’ve been in teams that ensure an independent exit interview is not only held but then reviewed and acted on before the job advertisement for a replacement is written. I’ve handed my notice in and been told not to bother to turn up to next week’s team meeting, and I’ve handed my notice in and had a handwritten letter from the head of the organisation I worked for to tell me how much they had appreciated my work on my desk 24 hours later.

Like a healthy immune system, good teams can handle losing or damaging a part of the team and will work to fix the gap over time so that even a big loss becomes an opportunity for change and improvement and people doing new stuff. Bad teams will take the opportunity to blame the change for problems. Next time someone leaves your team, watch closely.

Coda: here’s your cheat list of 10 questions

1. Do you know what you’re delivering? (if you asked three different members of the team what they’re delivering and for whom, will there be a consensus in their answers?)
2. Do you all agree on your status? (next time you hear a different story about a project from two different sources, don’t criticise it; find out why)
3. Do you know what the most difficult bit is? (what are your riskiest assumptions and what are you doing to turn them from assumptions into solutions?)
4. Have you delivered recently? (was the last one that the team was supposed to have delivered actually delivered?)
5. Have you delivered consistently? (what were the last 3, 5, 10 deliveries from your team and how similar were they?)
6. Have you pivoted recently? (what was the last time you made a change in direction and how did it go?)
7. Have you talked recently? (can you give me a recent example of a change that you’ve made to your ways of working as a result of your retrospectives/team conversations?)
8. Is it safe to talk? (when was the last time someone told you something difficult, and what happened?)
9. Where is the data? (for the next team debate, ask what data you could find to help resolve or reframe the discussion)
10. What happens when someone leaves? (does the team step up to fill the gap, or complain about it?)

There are a few things that could happen with these 10 questions. You could devise some exercises to talk through them with teams and find out which were particular problems, you could find training or awareness material (e.g. that TED talk linked in point 8), or you could try and split them down into sections*. I think these approaches will depend on context so I’m going to stop here for the moment – but please do let me know if you use this.

*I’m aware that some people would try and split these into “delivery” and “people”: I’m not a fan of that approach, partly because I don’t think you can split the interdependency between the two, and partly because we have an unhealthy industry tendency to prioritise delivery stuff and relegate people related stuff to the bin marked “later, when we have time”.

Header image: Marius.vrstr, CC BY-SA 4.0, via Wikimedia Commons