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.