BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Stretching Agile in Offshore Development

Stretching Agile in Offshore Development

Bookmarks

To remain agile while offshoring software development, you have to invest time to make agile practices work under conditions where they are not supposed to work. Giving up is not an option, argued Xavier Rene-Corail and Ionuț Baloșin; you need to stretch agile practices by going back to the principles and collaboratively find ways to scale them and make them work effectively in a distributed environment.

Xavier Rene-Corail, Software Engineering Lead and Agile Catalyst at Murex and Ionuț Baloșin, Certified Scrum Master and Software Architect at Luxoft spoke about stretching agile at the XP Days Benelux 2016. InfoQ is covering this conference with Q&As, summaries and articles.

InfoQ spoke with Xavier Rene-Corail and Ionuț Baloșin about why they decided to adopt agile, how they apply agile practices in a distributed way, and why people give up when it becomes difficult to do agile practices and what you can do instead to stretch practices. InfoQ also asked them for advice to make collaboration work between companies with different cultures.

InfoQ: What made you decide to adopt agile?

Ionut Balosin: Several years ago I was involved in a couple of waterfall / mini-waterfall projects. At that time, the difficulties we encountered by following these approaches mostly had to do with collecting feedback from stakeholders (e.g. especially users) which was provided very late in the process, usually after a big amount of development was already done. Also, products were released too late and with a low frequency. The conclusion was that something needed to change, hence we moved towards more agility and pragmatism which helped us to respond quicker and better.

Xavier Rene-Corail: I first learned about software craftsmanship when I discovered the book "The pragmatic programmer" (Hunt & Thomas), that seemed to answer all the questions I had at that time about writing clean code, and about testing. Then, following the author’s suggestion, I read about the Agile Manifesto. These principles appear to me as common sense given the situation I was facing at that time: very long development cycles in a fast pace changing world. Since then, whenever I face the same conditions, I know that agile practices are the way to go.

InfoQ: Do you have some examples of how you apply agile practices in a distributed way?

Rene-Corail: Within Murex, the product division is already distributed (Paris, Dublin, Beirut). We make sure to run the daily stand-ups with videoconferencing, we run the retrospectives by using a virtual board instead of a physical one, and we do remote pair programming. In a distributed team, most agile practices immediately become a challenge. So it always come to the same question at the beginning: "Do we abandon the practice, or do we invest a bit more to make it effective?". Choices like "Can’t we run the stand-up without the Beirut developer?" or "Doing a videoconference for only one guy, it’s too much, no?" often occur, and as a Scrum Master, you really must explain the value of the practice, and ask the team to give it a try so that they can see themselves that it’s worth to invest time.

Balosin: Another good example of flexibility is the way that we are organized. We are split into teams, but people from other teams can easily be asked to give a hand if we have to manage a project that doesn’t fit into the current’s team capacity. This way we break the inter-teams silos and enhance horizontal collaboration.

InfoQ: People sometimes give up on agile practices when they experience difficulties. Can you give some examples?

Rene-Corail: Well, a simple example is "We cannot do pair programming, we are not in the same country". Classical examples are difficulties encountered at scale: "Too many people in the retrospective … let’s cancel this retrospective", "Too many people in the daily stand-up, it takes too much time and not all the participants need all information".

Balosin: We also faced a situation when somebody decided to switch to another project because he did not like to work using agile and all the practices around it. It was an isolated case which did not even discourage us. On the contrary, we decided to continuously improve our agile practices by reducing the flaws and making the processes more efficient.

We had to deal a lot with team’s scalability as well. In regards to this, we re-organized the meetings in terms of number of attendees and occurrences, hence we ended up in having Scrum of Scrums, retrospective of retrospectives (e.g. each team has its own internal meeting, after that there is another retrospective meeting including all distributed teams representatives to gather and enhance the outcome of the first one), follow up meetings, etc.

InfoQ: You mentioned in your talk that instead of removing practices that were difficult, you decided to stretch them. Why did you take this approach?

Balosin: The financial crisis from 2008 had a big impact on software development market. Taking into account the economical, political and technical constraints we needed to make our practices stronger and more scalable, since there were not many options or ways to go. We needed a way to support distributed collaboration, to enhance our technical expertise and to make room for technical innovations by offering a more flexible and predictable development pipeline.

Rene-Corail: We were in a fast pace changing business: Murex is building software for capital markets, and the business changed very fast after the subprime crisis, with more and more new regulations under aggressive deadlines, and with new technological challenges. We simply just couldn’t afford going back to waterfall under these conditions. So the only possible choice was to make the agile practices work, under conditions where they are not supposed to work: distributed teams, offshoring.

InfoQ: How has stretching agile practices worked out for you? What did you learn?

Rene-Corail: I learned it’s quite expensive: we have a dedicated team of 3 developers in charge of providing the customized tools that support these adapted practices (custom visual management, extensions to the test automation framework ...). We also needed even more meetings than the initial SCRUM ones. However, I learned a lot about how collaboration can work under difficult conditions. Finally, the most important lesson for me is that it works! When you can truly understand the principles behind the practices, you can reinvent and stretch them, to achieve the goal. As an example, we used to apply BDD (behavior driven development). The developers were automating the acceptance tests given by the PO before implementing the story. In the offshoring context, with a distance between the PO and the developers, it didn’t work well: the automated acceptance tests were not 100% reflecting what the PO expected, so even if they were green, the business requirement was not met. We knew that the important principle behind the practice is to ensure that the PO & developers collaborate when writing user stories, it’s not just about automation. And we were missing this collaboration due to the distance, so we adapted our practice so that the PO could directly write the automated test, allowing both the PO and the developer to work and iterate on the same object, and eventually come to a shared understanding of the business requirement, nothing gets lost in translation. Another example is how we improved our visual management practice: the classical dashboards were not giving effective information. After a while, no one was looking at them. So we went back to the basis of the andon principle as in the Toyota Production System, and redesigned custom dashboards, that show clear red alarms when (and only when) we have to stop the production line and fix the issue.

Balosin: Stretching Agile is not easy, especially when factors like distributed development and teams with different culture come in place. In my opinion, how you communicate with people is fundamental if there is a need to create awareness and self responsibility. Another advice is to put robust working agreements in place, created and reviewed with involved parties, not enforced or imposed, so everybody will understand their benefits.

InfoQ: What advice can you give to make collaboration work between companies with different cultures?

Balosin: First I would say it is primordial to understand the culture and how other people behave, react and talk. Second, it is important to have frequent face to face meetings and trips between sites. After getting to know people we tend to work together in a more collaborative way, that’s how humans behave. Time zones and the cultural similarities might bring other challenges, but nevertheless they can be managed if the first two are well tackled.

Rene-Corail: I would use the metaphor of a dancing couple. First, you have to practice, and accept that you’ll hurt each other’s feet at the beginning because you don’t know each other; you will discover the other as you practice, and adapt. Second, you have to be obsessed by synchronization; have the same understanding of the situation, real-time. Visual management is key for this. Finally, you have to give the other some room for improvisation. If one of the teams (e.g. company) imposes everything, the collaboration cannot benefit from the creativity of the others, but if the leader gives the partner enough room for improvisation, then you’ll be able together to invent some new dancing steps and put on a great show.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • This wasn't what I expected

    by Mark Chapman,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I read this expecting some insight into the challenges of Agile in offshore, but this doesn't even begin to cover it. The issues aren't logistical (remote, scaled teams), the problem is cultural. In waterfall you can treat offshore as some kind of black box (deliver X by date Y), but the cultural differences can make a HUGE difference when trying for the more collaborative environment of Agile. For example India tends towards a deferential environment with a clear chain of command, and this can affect both work and communication. Add to the mix where the offshore is from a partner (rather than inhouse) and the problem multiplies, rapid staff turn over, multi tasking on projects, "do what it takes, even if you make assumptions " to deliver on a fixed date as the next project is scheduled. The other stuff is easy.

  • Re: This wasn't what I expected

    by Xavier RENE-CORAIL,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I would agree that the usual major problem when offshoring is the cultural difference. And indeed this article does not cover this problem. Simply because in our case, we didn't have it. As a matter of fact, we deliberately restricted the partnership selection to Europe, in order to simply mitigate this problem and keep these differences as small as possible.
    In our case, it was a partnership (not in-house), and being Agile in this context is not easy. You really need to be more Agile when you are 2 entities, with different goals and strategies, and with cultural differences (even if they were small in our case).
    Finally, I suppose that by "The other stuff is easy" you mean compared to the cultural differences problem? I wouldn't say "easy", but it's certainly not as difficult as would be handling big cultural differences.

  • Re: This wasn't what I expected

    by Ionut Balosin,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Hi Mark, thanks for your comments. The article is focused on the way we stretched Agile under a distributed environment, by detailing our offshoring solution. It is written from the perspective of mentioning practices that worked in our case, focusing on the positive side and offering insights or hints, as a possible recipe, for the readers. It also mentions that culture might be a challenge but it also states that understanding how to behave and react on it is very important, since the team's culture is not subject of an easy change and we did not even target that. The article explicitly describes "the only possible choice was to make the agile practices work, under conditions where they are not supposed to work: distributed teams, offshoring", this was our common assumption since the beginning.
    The context you have detailed is a bit specific and focused on cultural problems, which was not supposed to be a topic for this interview.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT