Tester, PO, Armadillo

This month I started work in a new organisation for the first time in 9 years. Whilst inevitably daunting stepping into a new company after that time, even starting on a fixed term contract basis as I am, I'm predominantly feeling excited about the prospect of working in a new environment. I'm taking the opportunity to step into in a full time Agile Product Owner position. Whilst this could be perceived as a significant change in terms of the job title that I'm coming from, the fact is that Product Owner is a role that I've been doing for some years under the mantle of my existing Testing/Support title.

A Rose by Any Other Name

When I wrote the last post of my "Survival of the Fit-Tester" series back in 2012 I highlighted how I believed testers in agile teams can provide a natural extension to the Product Owner (PO) role. I've seen for a long time a pattern of testers crossing the boundaries between testing, business analysis and Product Ownership.

As my role at RainStor developed to incorporate the customer interface disciplines of documentation and support, and in the absence of devoted POs in the teams, I found myself taking on more and more of the responsibilities traditionally associated with the PO. I was involved in organising the backlog, working with the development team to establish implementation approaches, breaking epics into stories and working with the team in elaboration meetings to establish acceptance criteria for the work they were delivering. As the development team grew into multiple scrum teams, so again a member of my testing team stepped in to coordinate the backlog and work closely with the developers on deciding the work for the sprints.

I'm not the only tester to have blurred the boundaries as their role has developed, or who has at some point taken on an explicit Product Owner role. In my immediate circle of acquaintances I know that Rob Lambert and Alex Schladebeck have also transitioned from being influential testers to having a product ownership role at some point in their careers. I don't personally view this as a progression, as I'm sure they don't either, but more like a natural expansion and utilisation of the skill sets and experience of capable individuals in making key business decisions. Being an expert in identifying relevant information to inform business decisions by its definition implies an excellent understanding of what those decisions are. This will involve gaining an understanding of what users are trying to achieve, what they value and what will undermine their perception of quality. The separation between that level of knowledge and actually being the decision maker is a thin one indeed.

A hidden choice

In self managing agile teams the testing and Product Owner roles are both critical to the extent that concepts such as the 3-Amigos have arisen to stress the need for these roles being present in important conversations. The investment in both full time testers and Product Owners for every scrum team is one that is daunting to many companies. What is happening in response to this is that some companies are choosing between one or the other, whilst possibly unaware of this being the choice they are making.

In some places, as was the case at my previous employer RainStor, the focus is on the testing, with a strong investment in testers in every team, but an absence of devoted POs. This can result in the need for experienced testers to step in on the day to day PO responsibilities. This situation was not unique to my team. As Priyanka Hasija observes in her InfoQ article on her experiences as an Agile tester

"QAs can also help the Product Owner (PO) write acceptance test cases by playing the role of proxy product owner. Having QA fill in as a proxy for the Product Owner when they are not available helps keep the team moving forward at all times.".

It is natural that, when the level of commitment to the PO role is lower than required by the team, a pattern that evolves is that the tester fills the gap as a proxy for them.

In my latest engagement at River Agency the individual product complexity is lower but the range of products and the level of bespoke customer work higher. This has resulted in a priority to focus on having a devoted team of Product Owners, with responsibility for testing shared between these and the developers. Just last week I was at a South West Test meetup where Anna Baik was recounting her experience of a company with a similar approach, that she wrily described as 'secret testers', where the job description of the Product Owners included most of the responsibilities that one might more typically expect to be associated with testers. A brief search on the subject of Product Owners and testing responsibilities yields discussions prompted by similar situations, such as this, and this one, that indicate that this pattern is not unique to these limited examples. There are many teams out there foregoing formal testing roles and instead placing high expectations on their Product Owners to test stories.

Whilst my preference will always be for focused testers, and a devoted PO, I can see the reasoning behind both of these approaches. In both cases the outcome is that the responsibilities of the one role are naturally picked up by the other to fill the needs of the team. What concerns me about both patterns is that each is a skilled role. Expecting someone in another role to 'pick up' the responsibilities of the other is optimistic. If, for example, the PO role carries an implicit expectation of testing then I'd expect the people in that role to treat this as a formal requirement and skill up accordingly, just as I'd expect developers to develop their testing skills in the absence of devoted testers in a team.

Where do product owners hang out?

There doesn't seem to be a widespread community for Product Owners. There are a few product manager groups, however the difference in results between a Google search on Product owner conferences as opposed to testing ones is dramatic. Testing is a vibrant community with a wealth of conference and groups to support it. Given the absence of a strong product owner community, the testing community does seem to act as a second home to a lot of the material and discussion that is geared towards product ownership. Gojko Adzic is perhaps one of the best examples of a highly influential author who's material on challenging requirements and 'Bridging the Communication gap' between customers and development teams is highly suited to the PO role, yet he targets a lot of his work into the testing community.

Paul Gerrard has also for some time been including elements of requirements management and user story design into his UKTMF group, and he has clearly stated that he sees a future shift to incorporate the definition and testing of requirements as the responsibility of a single group within the organisation.

"why for all these years has one team captured requirements and another team planned the test to demonstrate they are met. Make one (possibly hybrid) group responsible."

Armadillos

The luxury of specialisation at the exclusion of other responsibilities is becoming a rarity, and the need to take on multiple 'hats' is increasingly an expectation when working in flexible and self organising teams. It is clear that testers and POs have a lot in common in this regard. A common need to understand customer value, a common interest in information that furnishes decisions on quality, a common desire to assess the solution relative to the problem domain. The blurring of the boundaries between the two roles is somewhat inevitable.

So what is the difference between a tester who takes on PO responsibilities and a PO who tests? There will definitely be differences in the emphasis of responsibility, and skill. Devoted testers will always be more focused on extracting information from the software, POs on prioritisation and delivering to the customer at an understood level of risk, however I can see a future where this gap closes even further. In our 'square shaped team' individuals will be hired to fill out the matrix of skills required to deliver the team goals. Testers will need to develop skills in decision making and customer communication when the PO role is absent, and POs are likely to need to develop testing skills to allow them to obtain the information they need to inform those decisions.

One of Kipling's famous Just So Stories involves a hedgehog and a tortoise trying to protect themselves from the jaguar who has learned to overcome the defenses of each animal. Hedgehog learns to swim and flatten his spines to create a shell more like a tortoise, whilst the tortoise learns to curl up more like hedgehog, with the result that both end up as armadillos.

Based on my recent experiences, it's possible that testers and Product Owners might end up in a very similar position.