I was talking with a company the other day about managing projects overseas, and it got me to thinking about another PM area that mother never told you about. In an Agile world, driven by use cases and high communication quick turns, how do you make that work with overseas teams?
Let’s be honest for a minute about Agile. At its essence, it is basically “You know what I’m talking about, just go do it.” In the dark of night, if the folks who created it, or most loved it were honest, it comes from a deep sense of frustration from engineering teams at being constantly dissed in their ability to contribute to the design of what they were building, and being instead treated like construction workers, given specific plans and expected to do their damn jobs, without adding any creativity or insight beyond clever ways to implement the code.
Now I actually love this. The best success I’ve had over my career has come from letting everyone in on what we’re trying to get done, and not being such a prima donna about separation of spec and implementation. I was always about trying to do the old acting trick of getting into the mind and skin of the people we were building for and communicating the emotional reasons why people wanted what we were building to the team so they could internalize it and know at three in the morning what the right choice was without needing to have papa check everything. So the transition to use cases, and telling the emotional story tied up with the functional things the user needs to get done was like coming home, and worked beautifully…except when it came to overseas teams.
In general, we want to think of these teams as either just extensions of our existing teams, or implantation machines, much more often the latter. It is completely true that use cases fail on a regular basis with these teams. As good as language fluency may be, communicating emotional states is mostly the job of metaphor or common cultural reference. No overseas team wants to admit they don’t get it, particularly on the level of nuance, so they will tend to take apart the use case mechanically, laying out each action and solving for that sequence without understanding the emotional importance of any part of that process. All of use who have done the time delayed emails or the 5 am calls know the frustration on both sides of mostly getting it, but never being quite sure. So we tend to go back to old-school exact specs to minimize the frustration on both sides, and more importantly to minimize the days wasted in what would otherwise be simple “Did you mean X?” back and forth chats if the communication was happening in real time. After all, we are paying them to get what we want done, that should be enough, right?
The unseen problem is that the overseas engineers are in the same place that the early engineers that came up with Agile in the first place were at. If they are any good, ultimately they are hungering to do more then punch a clock and just code (and then recode) what they were told to do, without any independent intelligence or investment in the ultimate service of the customer. In the place where we need those team members to most be able to act independently and “know” the right thing to do most of the time, we have instead disconnected them from that, and made them extensions of our own hands that act with a 12 hour delay both to get their signals and to send nerve impulses back.
So how do we solve for this problem? Most of the ways are frankly pretty difficult. The first and most ideal is to have at PM on the ground overseas who bridges both cultures. An ex-pat, or someone who both went to school and worked in the US long enough to get acclimated. (This can be tricky, because being here is not enough. Cliché as it may be, the best engineers are not often the most social of butterflies, and someone who came over to MIT and never left the tunnels may be a wonderful engineer, but won’t be able to create that cross cultural bridge.) With that person in place, get enough of the teams together face to face for long enough to get past the nodding stage and to the point where people can see the crinkle of a smile in the eyes behind the emails. Fly there, bring them here…whatever works with the budget. It IS PART OF THE COST..don’t leave it out of the equations.
The second option is to make sure to over staff with UX/UI. You need people who can work in sketch, who aren’t so worried about their stuff being pixel perfect that they are ok sending out quick versions of interfaces and flows. A picture being worth a thousand words is double true when you have teams across oceans. (This, by the way, is true of Agile in general. It most often fails when UX/UI falls behind and the engineers get frustrated and end up just doing the UX themselves. There are engineers who can where both hats, but there are a LOT more who can’t, think they can, and get hurt feelings when you have to repair or replace what they spend time doing.)
It’s virtually impossible to do standard Agile with an overseas team, but you can bring them deeper into the fold. If you do, the work will be better, and you will get less churn with the engineers, because they will be sooo much happier working on your stuff then going back to being coding drones.
Here are a couple of good related links:
Using an Agile Software Process with Offshore Development by Martin Fowler
Posts
