Agile standup meetings are a struggle for the teams I observe and manage, all of which have people in more than one location. I'm not sure we're collaborating the right way for the work we do and the way we work.
Teleconferencing with more than three people is painful. It's one thing to get six or ten people together in the team aisle for 10 minutes for a quick round of "what changed since yesterday." Standing up actually makes sense, in that scenario. But conference-room speakerphones change that dynamic radically. Even videoconferences aren't great; the latency, poor audio quality, and limited field of vision make it much lower bandwidth. No one who regularly uses remote conferencing technology, at least the sort my teams have access to, would call it a team-building or bonding experience.
The rules for standup are unnatural. The standup is not supposed to be a status report; but the difference between a status report and a story update is too subtle for most people. Unless we have great discipline, people talking one by one naturally turns into a status report, and status reports are boring and useless. Similarly, the standup is not supposed to be a problem-solving session; once an issue requiring collaboration is identified, we are supposed to park it for later. But engineers like to solve problems, so unless we have great discipline, talking about our challenges naturally turns into a technical problem solving session.
How could we honor our instincts? Why do we work so hard in standup to avoid doing the natural thing to do, especially when it's a thing that is beneficial? We want collaborative problem solving, and we want to feel connected to each other and to the team's progress and problem-solving flow. How can we structure our meetings so that what we want to do is the same as what we should be doing?
One idea might be to schedule an hour every day, immediately after standup, for small-group collaboration. Use the standup to identify the collaboration that needs to happen, and then spend the next hour doing the collaboration, in twosomes or threesomes. If you don't need to be involved you don't have to be; if you do, you've already got it on your schedule. This would make the "parking lot" more real; for distributed teams, once you hang up the phone it's hard to regroup.
Another idea would be to have our webcams on fulltime. If you're at your desk, no matter what city it's in, your coworkers can see you. Working from home? Wear your clean pajamas. The problem with this, again, is that our technologies aren't up to par. Ideally I'd have a little row of realtime video thumbnails across the top of my screen, one for every coworker, and any time I wanted to ping them I could just click. I'm not aware of a product like that. Would someone like to build me one?
Monday, February 17, 2014
Tuesday, February 4, 2014
Specialists vs Generalists
This weekend one of the teams I manage had to work some very long hours to resolve a severe customer problem. (I got about seven hours of sleep over three days, and I'm getting a bit too old to recover easily from that.) One thing that made it take so long was that we had to submit database scripts to be executed on the customer's behalf; for good reason, there are a lot of restrictions and approvals necessary to do that, but my team wasn't very familiar with the process.
Thinking about it, I realized this is an example of a systemic failure, and I'm on the cause side as often as the effect side. I'll call the problem "specialist versus generalist."
The database administrators (DBAs) see dozens of requests a day for scripts to be executed. Executing these scripts is a core part of their job. They know their team and their communication channels are well established. They know the proper approval process and they know what to expect in a properly formatted script request. From the DBA perspective, script requests are a simple, straightforward process, that has been fine-tuned and improved over months and years; and they don't understand why developers so often screw it up, when it happens so often and is so important.
There are dozens of requests a day. But there are more than a thousand developers. Any individual developer might go half a year or even two years without submitting a request. When they do, it is in a situation where they've been pulled off of their normal job in order to work an emergency customer issue in production. They're under high stress and tight time pressure: by the time a problem is escalated through ordinary support and all the way to development, the customer has probably been suffering for several days already and is hopping mad and running out of time. The developer doesn't know what a proper script request looks like, nor who to talk to in order to find out, and all they know about the approval process is that it probably changed since the last time they did it.
The DBA is the specialist in this scenario. The developer is the generalist. The specialist understands the rules and the problem domain so well that s/he can't see what it looks like to the generalist, who only encounters the situation once a year.
But this is not just DBAs versus developers! The generalist in one scenario is the specialist in another. One of the dev teams I manage owns an infrastructure that lets other developers license the features they develop. We are deeply knowledgeable about how licenses work and how features are defined. From our perspective, it's hard to understand why the other developers continually screw up their definitions. We're the specialists. But any given developer only defines a new feature every year or so. They're the generalists, and to them, the system is confusing and every time they try to use it something has changed.
The more I think about this pattern, the more I see it playing out all around me. When you spend all your time providing a service, it's hard to understand that to the people who consume your service, you are just an occasional thing, and most of their attention is elsewhere.
Thinking about it, I realized this is an example of a systemic failure, and I'm on the cause side as often as the effect side. I'll call the problem "specialist versus generalist."
The database administrators (DBAs) see dozens of requests a day for scripts to be executed. Executing these scripts is a core part of their job. They know their team and their communication channels are well established. They know the proper approval process and they know what to expect in a properly formatted script request. From the DBA perspective, script requests are a simple, straightforward process, that has been fine-tuned and improved over months and years; and they don't understand why developers so often screw it up, when it happens so often and is so important.
There are dozens of requests a day. But there are more than a thousand developers. Any individual developer might go half a year or even two years without submitting a request. When they do, it is in a situation where they've been pulled off of their normal job in order to work an emergency customer issue in production. They're under high stress and tight time pressure: by the time a problem is escalated through ordinary support and all the way to development, the customer has probably been suffering for several days already and is hopping mad and running out of time. The developer doesn't know what a proper script request looks like, nor who to talk to in order to find out, and all they know about the approval process is that it probably changed since the last time they did it.
The DBA is the specialist in this scenario. The developer is the generalist. The specialist understands the rules and the problem domain so well that s/he can't see what it looks like to the generalist, who only encounters the situation once a year.
But this is not just DBAs versus developers! The generalist in one scenario is the specialist in another. One of the dev teams I manage owns an infrastructure that lets other developers license the features they develop. We are deeply knowledgeable about how licenses work and how features are defined. From our perspective, it's hard to understand why the other developers continually screw up their definitions. We're the specialists. But any given developer only defines a new feature every year or so. They're the generalists, and to them, the system is confusing and every time they try to use it something has changed.
The more I think about this pattern, the more I see it playing out all around me. When you spend all your time providing a service, it's hard to understand that to the people who consume your service, you are just an occasional thing, and most of their attention is elsewhere.
Subscribe to:
Posts (Atom)
