A Very Happy Marriage between Agile and Context-Driven
16.04.15 - 13:28 - Filed in: Software Testing
image credit: https://www.flickr.com/photos/wenzday01/6027317553
I believe the agile and the context-driven communities are highly compatible and should make every effort to get married at once. The two communities have not been too close in the past and I believe they have not yet appreciated each other's value. My experience has shown that it becomes a winning ticket as soon as the two communities are exposed to each other in a professional setting. When it comes to education I believe demonstration is far more powerful than presentation. And that is exactly what we did at eBay.
At the European Product Development organization at eBay we had five scrum teams located in London, Berlin and Zurich. They consist of highly skilled developers most of whom believed that if they applied all good development practices there would not be a need for any testers. Hence, they did not have testers aboard their teams. In parallel I lead a team of testers who occupied themselves in more waterfall projects offering testing services to other parts of the organization. No professional contact between the two teams. We decided to do something about it.
About mid-year in 2013 we started to change the set up and place testers into the teams. It started with a first experiment, where Jan Eumann commuted between Berlin and London to offer his services to a specific project. Jan has vast experiences as a software engineer and consultant from his days before eBay and that certainly helped him to establish a service culture towards the team and boosted his acceptance. He later joined the team in Berlin and actively helped to bridge the connection to the business units in Berlin, with whom he already had good relations.
Earlier that year I hired Ben Kelly, who was one of the first testers getting himself fully involved into one of the teams in London. Since Ben is a master in finding words for what he is doing, he was able to convince the team that there was far more to testing than they initially believed. Ben has a rare talent of being humble and assertive at the same time.
We then expanded to the team in Zurich with Daniel Moennich early 2014. Daniel has a sound background in software engineering, which helped him a lot with gaining acceptance with his team. He introduced a lot of critical thinking at the beginning of the project and his approach of solving problems for the team in a calm way demonstrated his value.
At Let's Test in 2014 one of my missions was to identify yet another tester to hire for one of the teams in London. I spoke to many attendees and tried to evaluate who could be a match, which was difficult because the profile I was looking for required a sound level of software engineering knowledge and a ruthless mind of inquisitiveness and deep understanding of testing.
I then stumbled across Ioana Serban. I recommend you meet Ioana if you get the chance to do so. She's one of the most energetic testers I have ever met. Ioana is smart, technically proficient, inquisitive and will certainly not take shit from anybody.
Of course I made mistakes, too. At one point I hired somebody with whom I did not clarify what it means to be embedded as a tester in one of the teams. We both soon became unhappy and our paths went into different directions again.
Hiring the right people
Hiring people is a tricky matter because it is tremendously difficult to evaluate people in the artificial setting of an interview. Our process evolved over time and we found the following approach to be suitable for our needs.
I talked on the phone for about 30 minutes to applicants who passed my first screening of their CVs. I wanted to establish their general views on testing and get a feel on whether or not they could fit into our teams. Then they had to write a little application incl. unit tests. We evaluated their work in terms of elegance of their solution and the quality of their tests. If they passed that, we invited them for a full day at the eBay office and we did something we called "Sprint in a Day". The applicants were exposed to the teams we were hiring for and they had to solve some hands-on problems. In between senior people talked to the applicants and established an impression by doing behavioural interviews. All this helped us to gain a rich impression on applicants and if they did well, we hired them.
When we decided to place testers aboard the teams I had no idea of how that was going to work out. It was a path of little experiments and learning as we went ahead. Our set up was that all testers were reporting to me but their day to day accountability was towards the team they were in. This meant that I kept my hands off the operational level and let the testers do what they were doing. As a manager this can be uncomfortable, since it is a loss of control and I as a manager — like many managers — like to be in charge.
I discovered that the "be in charge" had to take another form. Rather than involving myself in the day to day matters, I took responsibility to hold the community of practice together and make sure the testers in the teams exchanged their ideas on a regular base.
Currently none of the teams would ever want to do without their embedded testers. Their opinion shifted not because I tried to convince them of the value of a tester, but because the brilliant people I talked about above demonstrated their value. Not only are the teams operating very smoothly with the current setup, but parts of the rest of the organization have suddenly become interested in learning how the European Product Development Teams handled their testing. What we have established is an incubation cell that will have significant influence on the whole organization. This is much more than I expected to achieve.
Leadership is not control. It is also not about me. It is much more giving people the liberty to shine and not to take a center position, but to support the flow of what is happening by offering assistance where it is asked for. At one of our workshops the team came up with an Agile Testing Manifesto, which gave us an outline of how we work.
The experience with the European Product Development team of eBay has demonstrated to me that the context-driven way of testing is indeed highly compatible with the agile mindset. It is an encounter between two tribes, which both strive for craftsmanship and high quality of work. I hope the two communities move closer together in the future. People using software will gain from it.