Blog

Agile and Nearshore

The Nearshore Americas conference in Mexico City was a great opportunity to talk to the wisest people in the onshore/offshore debate – folks who are living it on the ground from both “shores”. A lot of folks touched on the challenges of meshing modern software development – I’ll call it “agile” so we sort of know what I’m talking about – in a cross-border model.

The model has not always been a success when executed with cross-border teams. Significantly, teams and organizations which were very productive with onshore-distributed agile often – very often – saw significant velocity hits when delivering with offshore teams or even mixed on/off.

Thinking about this leads me back to one of my favorite truisms: that harnessing technology for useful purposes in today’s world is only partly about creating software, and creating software is only partly about engineering. Technology deliveries have become social projects, and successful projects work as social units as much if not more than as lines on a project plan.

A successful agile delivery involves creating a social unit called a team, where everyone feels that they are contributing. But what that really means in practice – what constitutes a positive contribution, vs. a negative one – is not the same in all contexts, in all cultures, in all circumstances.

For example, just about everyone-everywhere agrees that managing risk is important. Many, especially in the Agile community, would agree that it’s everyone’s role to look out for unforeseen risks. Some practitioners I have worked with would say that it’s a positive contribution to call attention to problems in the delivery quickly and early, in the daily standup or Sprint Planning. Others might say it is a negative contribution to characterize the work of teammates as presenting a risk, in front of the entire group – and it’s negative for the entire team.

For many really talented deliveries, in big parts of this wonderful world we live in, the “others” would be correct. A different kind of practice, where project assessments could be made collectively and critiques presented indirectly, might achieve a more cohesive team and better results. This doesn’t mean that personnel issues don’t exist, that risks should be soft-pedaled – but their intersection with the social project of delivering technology is not the same in all places and contexts.

Sometimes “reality” pushes these issues into everyone’s face. It’s a reality that different legal systems, labor regulations/expectations, and tax regimes can force some differences in how people in different countries can participate. That’s a genuine problem that doesn’t go away simply with good intentions. The social project of delivering technology value in the US has a lot of implicit reliance on a shared set of assumptions about things like the enforceability of contracts and protection for intellectual property.  When people feel that they cannot accurately gauge some of these risks, the tendency is to rely on top-down controls that make things less agile; when the controls distinguish between the folks on the team based on their location, things become even more challenging.

Teams need to build ways of interacting that can work around these top-down challenges. For the social group to deliver effectively they need to not just socialize but cooperate – the real magic – and that requires trust. There is no substitute for real-time interactions, and they need to happen on-demand, not as part of a top-down structure. Real, respectful, trusting relationships can go a long way to mitigating friction caused by top-down “reality”.

Fundamental is that face-time is important. At least voice-time.  The need for spontaneity makes desktop teleconferencing – group and one-on-one, open all day (like an office door) – a critical tool for distributed agile teams. It’s best when it’s integrated with chat so that the same spontaneity can spread across a wider communication range. Lots of stuff starts with a chat, escalates to a call, and ends up dragging in another participant or two, and then it’s back to work, using chat to clarify if needed. We use Skype, there are many others.

It also means that a large workday overlap is actually really critical to making the social project work. Folks in media and finance have made 3-hour and 5-hour timezone differences work for decades, by sharing the time-shift burden, but getting that to work on a large scale across 10 or 14 hours is a significant stress on the social fabric.

If you want to have success in working with an Agile approach – co-located, distributed, or global – you need to start from the premise that everyone has something to contribute and no one has a monopoly on innovation. This doesn’t really help you decide what your team dynamic and practices will be; but it does help orient them toward respect for all, which is the closest to a universal I have found so far.

Ready to be Unstoppable? Partner with Gorilla Logic, and you can be.

TALK TO OUR SALES TEAM