When Offshore meets Agile

This post belongs in both of my blogs “Leading Agile Transformation” and “Succeeding with Offshore Management”, so I’ll publish it in both…

When companies look at Agile the question of location often comes up: people are afraid to implement Agile with offshore teams due to the distributed nature of the teams. Of course it’s great when you have face-to-face communication, but I see no problem with implementation of Agile in distributed environment (ok, maybe some challenges).

There was a research done on the subject of communication in different office settings, and what they found is that best communication happens when people are sitting in the same area or in adjacent cubicles. Next best setup is an offshore model and the worst setup is when people are located in the same building but not in adjacent areas. The difference in communication efficiency was significant between 2^nd and 3^rd categories, but insignificant between 1^st and 2^nd. One of the reasons for these findings could be that people in the 3rd category think they are collocated and do not need to invest in improving communication channels and communication efficiency. On the other hand, folks in distributed setting are well aware of the challenges of communication and are investing a lot of effort in constant improvements.

Agile fosters frequent communication and helps distributed teams to advance to the next level of efficiency. Yes, there are challenges that are exacerbated with Agile: more communication requires more discipline and sometimes changing the ways we communicate and may require additional tools to support it. This is not different from any other problem that Agile helps to put a spot light on and that requires resolution. Agile will emphasize what we as an organization need to focus on to make sure required communication levels are met.

One thing we’ve been struggling with before was choosing the right timing for onsite visits: the environment was pretty chaotic and it was difficult to plan for a visit and to tie it to a certain event (planning/design review, etc). With clarity of SCRUM it’s obvious how we can leverage the framework to plan for visits: Release/Iteration planning and Demo sessions are a natural fit for this.

As part of our Agile transformation I’m making sure to have not only Agile enthusiasts on  the other side of the ocean, but someone in coaching capacity to augment my efforts on site and help teams when I’m not available due to time difference or any other reason.

Learning Pays Off

There is no entry in this blog since December ’09 not because I was lazy, but because so many things have happened in context of our Agile Transformation, that I decided to wait and organize my thoughts.

In February I’ve held a 2-day offsite workshop for the entire Product Development team. It was a workshop and not a mere PowerPoint overview of Agile practices. We’ve analyzed our challenges, our vision and goals, learned through games and read articles about Agile adoption. We’ve discussed success factors, success criteria and recipe for failure. This was my first public speaking in front of such a large audience for such long period of time, so as much as it was educational for the entire group it was quite an experience for me as well.

It was extremely beneficial to walk the entire team through the vision and the goals and showing how with help of Agile we can get there. Once the group understood that we are not doing Agile for the sake of “doing it”, but Agile is just a means to an end everyone became more comfortable with the idea of adopting it. Especially it resonated with senior engineers, some of whom had pretty bad experiences with Agile in previous jobs, where Agile was shoved down the throat by the management. Everyone has appreciated the fact that we’ve learned Agile for almost 12 months and didn’t want to rush with it right after reading a book.

Armed with the basic understanding of where we are marching to and how will we get there we had additional onsite education for Engineering Management, Product Management and key engineers on the roles of Scrum Master and Product Owner. These were lead by external coaches. Not to forget about our offshore team in Ukraine, we also made sure to organize SCRUM training over there (some delivered by me, and some by local coaches).

As our major release was coming to an end we were at the right place as organization to begin our 1^st pilot project.