In the last two posts we have tried to show how our every days look like, with a special interest in the various sprint meetings. In this post we will continue with this subject. We will also give you some ideas for additional useful meetings and explain how working distributed looks like from a perspective of a QA.
The part of development process that is necessary in maintaining code quality is definitely code review. The review in the distributed environment can either be performed by the colleagues sitting in the same office or can also be distributed. In our projects we do both, but the distributed one we do far more often.
We usually pair team members from the on and off-site parts of the team in order to spread the knowledge across the whole team. The review itself is usually a 1-1 session. When you need somebody to review your code, try to find the best candidate for it, based on domain knowledge or technical skills.
Sometimes we also do code review in a group – usually not the whole team – in order to spread the knowledge and to hear the opinion of a larger audience.
Experience from another project is as follows:
The code review was changed so that always three team members attended the code review. One was the developer, who had his work reviewed. Second was the team member who had the most knowledge in the reviewed code area, and third was the distributed team member who needed to gain the knowledge. In the case where the newly joined team member did the review, two more experienced team members were present in order to increase the background knowledge of the new team member. In time the domain knowledge was split across the team, and it was compulsory to always have at least one distributed team member attending each review so that the knowledge about the code base stays distributed on all sides.
Knowledge sharing is one of the biggest problems a team may encounter when collocated, but it is even more complicated when the team is distributed. A solution to this problem lies in constantly sharing everything you learn through various meetings. Apart from already described scrum meetings (planning, estimation, grooming…) our teams came up with some new ideas on when, where and how to distribute knowledge:
Dev Exchange sessions
At least two times a week we organize a session where team members share some important knowledge with the rest of the team. The topic varies. Mostly we use that Meeting for a developer to explain how he implemented a new Feature, so that in the future others can work on his code with ease. Other times technical debt is discussed and if possible, the plan for dealing with it is drafted after the discussion. In addition, topics from the management may be presented, updating the team about managerial plans or issues. Whatever the topic is, discussion is always welcome. It is a great place to ask questions about the topic being presented and to express your opinion, all with the goal of perceiving all approaches for a problem and coming to the best possible conclusion on how to handle it. This is a time boxed session – around 30 minutes. During the meeting everybody is sitting on her/his place, connected to the conference call with shared screen from a presenter. In our setup, the off-site part of the team is responsible for gathering the topics and organizing the Meetings, to take care that majority of the team can participate.
Cross-location pair-programming sessions
Pair programming is a well-known technique of knowledge sharing,. But as some of our team members have noticed: it is actually more fun to do it between locations.
How to do it? – You both start a meeting. Then one of you opens the IDE, shares the screen and keyboard control. Both participants now have a direct view to the code and can easily take control. Compared to the same location pair programming, this actually has multiple advantages: you don’t have to switch keyboard and mouse, and your view of the screen is not sideways which makes it much more comfortable.
In one of our projects after a year and a half it has been decided that testers will be brought in, in order to increase the quality of the product even more.
Three people, from which one is distributed, joined the team around the same time. We had arrived in an already ongoing project as not only new members, but as a whole new team and a completely new role.
This proved to be a triple challenge:
- we had to learn and integrate as any other team member would have to,
- we had to figure out how to organize our own small group of QAs and
- we had to figure out how to integrate our group in the already well-functioning team.
On top of it we had a distributed member…
Learning and integrating as a (distributed) tester
A very important part of a tester’s job is gathering information about how the software he tests should look like and behave. More precisely: gathering the right information. Mostly, that information should come from the client. For the collocated testers this is not a big problem as they can approach business analysts at any time, since they are working in the same location. For the distributed member on the other hand this means technical difficulties. The client is not connected to our network, thus reaching him is not possible through the regular channels we use within the team. This means that there are two options for off-site members: sending e-mails or asking a collocated colleague to transfer the question. Sending e-mails slows down the work quite a bit since the answer doesn’t usually arrive right away, but we learned to gather our questions through the day and then send them out altogether. Like this, we don’t alarm the client constantly and in return they really give their best to answer our e-mails as quickly as possible. When we ask a collocated team member to ask the client in our name we get the response real quick, but this approach has some downsides. First and most, our collocated colleague loses a lot of time passing information from one place to the other. The best solution for this problem is a very good and always up to date documentation so that the number of questions directed to the client is reduced to a minimum.
Organizing and embedding a new distributed test team
Synchronization of everyday’s work is very important. Being a part of a distributed test Team, which at the beginning was not organized, had no clear split of responsibilities and did not work as an independent Team. There were no dailies, no backlog… – which taught me that transparency and knowledge sharing is very important. You don’t want to realize at the end of the day that, since you were not sitting next to each other, you and your colleague have been unintentionally working on the same task all day long.
We have tried multiple ideas in the pursuit of the perfect setup.
We have tried to create a testing team with its own meetings and a backlog… This solved our work distribution problems and enhanced the communication inside the testing team, but corrupted our relation with the rest of the team as we were not in touch as much as before. Because of that we tried to be part of both teams and participate in multiple dailies, which was successful but also very tiresome.
So we came up with another idea – we created roles within our team: an automated tester who took care of the test project and a manual tester who was in charge of the test cases and the sprint testing. At the beginning we rotated those roles every sprint. The downside of this was that we constantly had to bring the other team member up to date with the information left out during the time he was in the other role. So we enhanced that idea and removed the rotation out of it.
Now we have each team member attached to a specific role that has clearly defined responsibilities. We synchronize when our roles overlap and when we hear or learn something we consider the rest of the team would like to hear.
We are probably still not through with the changes. As new team members will join, we will have to adjust. But every time we change we learn something new and we are improving day by day. So after multiple setups and some funny situations we have learned an old thing: “You can’t win the lottery if you don’t buy a ticket”. Don’t be afraid to suggest new ideas and to experiment.