Agile essentials 4: Teamwork

Agile teams are multi-disciplined and communicate closely, which avoids miscommunication, builds trust and makes sure that things happen quickly when they need to. If your team isn’t working like that, you need to find a way to deal with it or any Agile processes you have will struggle.

In my first tech job, an operations role, my boss said, “Never email anyone you can call; never call anyone you can go and see”. It remains one of the best pieces of professional advice I have ever received. Incidentally, when I asked him if we were Agile (in late 2002), he replied that we followed the JFDI methodology, so even though he knew some things about great communications he was pretty far from your modern Agile guru.

In an ops role, my manager’s rule applies both when times are easy and when you’re in a crisis. If you ever hope to successfully orchestrate a big upgrade with multiple teams, or if you ever hope to wake someone up at 3am for third line support, you need to know people in each team and they need to know you. That means, when you have the time, you talk to the people you work with to understand what they do, and you make sure they feel appreciated and listened to. When that big outage happens, you call people and get everyone together and they show up because they trust you, and that makes things happen faster – misunderstandings are cleared up quicker, everyone understands the urgency, and so on.

On an Agile development project things are surprisingly similar. Your concept of “the team” should include everyone you need to complete the work you’re doing, and every day they work together like people work together to fix a big outage (but, you would hope, less stressfully!). Large, discursive documents and contracts are replaced by short, regular meetings, which result in concise descriptions of what’s needed right now. When you realise you don’t understand something or think something might have been missed, you tell the rest of the team. Adhoc meetings happen with all of the people you need, when you need them. Misunderstandings are cleared up quicker, timescales are clear, and so on.

For me, when this sort of communication isn’t possible that’s one of the big signs that a project or a team is not functioning well. However, it’s not sufficient to say “make sure everyone in the team is like this” any more that it’s sufficient to say “you shouldn’t do big upgrades”. We don’t live in a perfect world. I fundamentally reject the assertion that if things aren’t ideal you just throw in the towel and stop trying, or leave.

Availability problems

Sometimes teams are distributed, separated by space and possibly time zones. Worse, sometimes not everyone is committed 100% to the project and can’t be available when needed. When people aren’t always available, I try to make sure I find the times in the week when everyone can make it and make sure we have a regular meeting in one or more of those slots. This is not an ideal solution, so keep telling your managers why this is an obstacle for your project.

Latency problems

In the worst circumstances, for whatever reason, part of the project team might not even want this type of teamwork. I’m thinking particularly here of teams that are only accessible via a ticketing system or similar. So, your project needs a new server or an API change and they have to raise a ticket and wait. In this kind of situation, you make the best of it. I would tend to go around the obstacle and use that resource as little as possible. Can’t have a new server for a month? OK, we’ll build and manage our own servers (maybe virtual ones) and use yours when they become available. Again, this is far from ideal but, in my experience, you just can’t work effectively if you’re always waiting for someone outside the team.

Prioritization

There’s a caveat to the latency problem described above: An excellent book called The Phoenix Project describes some practices under the heading of Devops, which include something like a ticketing system in the sense that many different teams want to make changes and there needs to be a process of ordering and prioritizing those changes.

This is often unavoidable – sometimes your team needs to wait a little or fit in with someone else’s schedule for the good of the whole, for example when making structural changes in production. Readers of The Phoenix Project will note, however, that dialogue regarding scheduling and prioritizing work aren’t done via an automated system or long email chains. Rather, there’s an effort to hold meetings for these tasks. That’s not the kind of ticketing system I have an issue with. It’s also worth noting that developments towards microservices and so on are aimed at minimising cross-cutting dependencies so that independent teams don’t need to coordinate so much.

Remote teams

It doesn’t necessarily follow that, because team members are remote, communication with them will be poorer. However, in my experience it’s certainly more of a challenge. Remote team members miss out on the conversations that happen when you walk past someone’s desk. They won’t naturally overhear that conversation you’re having about a feature and, perhaps more importantly, they won’t usually talk to you about what they’re watching on Netflix or what they did at the weekend.
My solution to this in the past has been to create a central place for conversations that everyone can see and keep it running all day, every day. When I first tried this, we used a Skype group chat and it was a roaring success. I thought I’d cracked it. I would arrive at my (home) office every morning and say “Hi guys” and everyone would say “Hi” back. Issues would arise and we would all notice, then we’d solve them in a group. At some point someone would post a link to something on the web and we would chat about non-work stuff. In short, it made me feel like we were all part of a close knit team even though we were all remote from one another.
Then I joined a company where my tactic was a total washout. Here’s why I think that happened:
  • Security concerns meant the company didn’t like us using Skype and their internal messaging solution didn’t allow us to create a continuous “place” we could all access in each morning. When you have to create your group chat anew every day it’s more effort
  • Not everyone was remote, just a couple of developers. This meant that we didn’t all have to rely on the chats and so we weren’t as proactive about using them
  • The team was a little larger that I’d tried this with before, so when a lot of people were using the tool, it was sometimes a little crowded*
*this last point has been dealt with to a huge extent by solutions like Slack (for teams that can use public cloud solutions) and Mattermost (for stuff behind the firewall). Both seem excellent to me.

Doubters

Finally, sometimes people who are otherwise unencumbered on your project will not understand, or not like, the idea of working in teams like this. I’ve seen it from developers, managers and business people. There are endless reasons for this.
I suppose the thing I would urge is empathy – sometimes doing something different is scary. However, you can’t let it disrupt the team so you need to be a little bit pig headed; force the issue and encourage the team, celebrate success and identify failure without blame. Most of all, make sure the team keeps on functioning. Trust that when your team has a few wins under its belt, which it certainly will, the doubters will hopefully come around.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s