Distribution

Agile testing in distributed teams

This is the story of two QA Managers, Laura and Milo, working in a typical onsite-offshore outsourcing IT practice. While Laura hails from Spain and works in Oslo, Milo is from Goa and works in Mumbai. Our Diversity can be summed up as “We work for an british company having a division in Norway, an offshore office in India and with citizens from all around the world as our colleagues”.

We have been doing “Pair management” for more than one year at Fronter  AS (a Pearson division) and thanks to our colaboration we have managed something that a lot of companies struggle with: Agile testing in distributed teams. So if you work in one of these companies, here you will find a few tips to make it work.

Gone is the era of size being might. Contemporary business houses believe in early delivery, reach the end customer first and capture market. There are umpteen examples available. Size need not be the only criteria. Lately, companies are releasing beta products to a subset of users rather than waiting for the entire product to be developed and then taking customers feedback. These beta products is what we call an MVP –  Minimum Viable Product. Fronter is one such company.

The advantage of early beta releases is that companies start getting early feedback about the potential larger product awaiting a release. The early feedback helps companies make quality judgments and decide on their next moves. The following image represents the evolution of Fronter releases during 2013. From bi-annual releases to project releases, to a first attempt of continuous user-story based releases.

But we didn’t stop at these point and we implemented “One idea one commit”. So to this point it’s pretty clear that Fronter is focused on Agile but… how does testing fit into it? Especially how did we manage to ensure the final quality when Product Owners, Software Architects and half of the developers are in Oslo but all the QA team is in Mumbai?

Here is some advice:

PATIENCE: What you are trying to do is feasible but it takes time. We would estimate the effort in 6 – 9 months. So if you have been trying only for 3 months, don’t give up!

PAIR MANAGEMENT: The manager in the client (aka Laura) would point the direction, provide context and remove impediments. The manager in the offshore office (aka Milo) would find the best way to adapt to the needs and raise difficulties found on the way. Together we built and continuously improved the QA Strategy. We had a call every day. Even if there was nothing specific to be discussed we didn’t miss our 15-minute daily call. Topics would always appear. If a longer discussion was needed, we would schedule a longer meeting.

DEDICATED ROLE: The QA Manager role is a 100% dedicated role. We don’t think this model would work if one of the QA managers has another role in the company or in the development process  (Product Owner, Tech lead, Scrum master). Not only because that person would lose perspective but also because the role needs a high dedication. The QA Managers would define the different roles in QA (test engineers, automation engineers, performance engineers), their mission and would set clear, small and achievable goals for them.

VISIT THE OTHER OFFICE… and meet the team. No matter how many calls, presentations or e-mails you exchange. Nothing provides better context and reality as seeing the situation with your own eyes. In this case Milo visited Oslo once and Laura visited Mumbai 2 – 3 times a year as the whole team was based in Mumbai. Don’t go with a very tight agenda of things to be solved. Just go there and do your normal tasks, watch and observe how are things around you. You will start understanding a few things and you would realise that some of your suppositions were wrong.

JOIN THE AGILE COMMUNITY: If there is an Agile or Lean community in your company, join it. We QAs are afraid that the “Agile fashion” will kill our profession. Our advice is: don’t fight against it but join the flow. Quality will always be there, just with a different shape. Milo and I joined the Fronter’s Lean Task Force called Fibonacci Kittens, our learnings were huge and working in a community with a common goal and without “departmental battles” is very rewarding. Milo perfectly described his metamorphosis in this blog post

YOU CAN FAIL… if you learn from it. If you have read about LEAN you probably know that allowing failure is one of its principles. QA was not excluded. In order to allow our Test Engineers adapt to the new agile processes, and don’t be scared to try new things we should let them fail. So we relaxed a little bit the testing scope and we allowed minor bugs in production for the sake of learning.

CROSS-FUNCTIONAL TEAMS: We moved from the classic QA department, following a waterfall model,  to agile cross-functional teams. Each team had manual testers and test automators together with other scrum roles (PO, Scrum Master, Tech lead, Developers,…). The cross-functional team takes responsibility for the quality they deliver and they share the testing tasks. The QA Managers take the role of Guild Master which consists more in mentoring than ruling. The QAs of the team are empowered to take decisions and own the quality process of their team. This is easy to say and difficult to make it happen, mostly because of cultural issues. And this is when cultural awareness takes place.

CULTURAL AWARENESS: We all think that our culture is the normal one or even the best. There are not better cultures than others just different ways to react in different situations. Learning and understanding the culture of your client or offshore team is essential. Luckily Pearson integrated in it’s intranet a cultural awareness tool that makes everything easier but if you don’t have access to such tools you can always prepare an internal training. Don’t try to change a culture, learn it and learn how to use it for the best

CONSTANT FEEDBACK: This one is obvious. You can’t complain about someone not performing up to expectations if you never told him/her. Also give positive feedback when things are going well, your team will be more motivated. The “no news is good news” doesn’t work with all cultures.

We still have a lot to do but when we look back we realize all our progress and we are proud of it.