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
- 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*
virtualmackem 