Tension and Negotiation Between Disciplines
My thinking in this area are evolving and so I expect I’ll be updating this in future posts, but I think there’s enough utility here that is worth sharing.
There’s a natural tension that exists (and should exist) between product folks and development folks. For a long time I’ve explained it to people like this: Product are trying to get something to market in a timely fashion that meets a need people will pay for. Development are trying to solve a non-trivial problem in an elegant fashion in a way that is maintainable and sustainable. Those two aims will inevitably come into conflict and so you have an ongoing negotiation between Product and Development, making tradeoffs between the two in order to strike as even a balance as the people involved know how. It’s important for each discipline to understand the perspective of the other and know what is important to them. Problems arise when one side gets too far out of balance. Where Product dominates, you tend to cut corners and add dirty hacks to rush something out. When Development dominates, you often find over engineering and gold plating. This is not to say that the two are always at odds, but regardless of the level of cooperation, this tension exists.
It has been a useful analogy, but as I’ve been exploring complexity and thinking about how I think about testing, I think there’s another dynamic I’ve been missing. There’s certainly the possibility for there to be a separate dynamic that I hadn’t considered distinct before. ‘Development’ is an interesting word. In many other industries, ‘Development’ is frequently preceded by ‘Research &’. I think that there is space to position what we think of now as software testing in this ‘Research &’ space. Much of what we do in testing is experimentation, research and analysis in the service of making better decisions around producing value. There is crossover between what we do and many of the other software development disciplines, not least of which is UX and User Research, both of which would also slot neatly into this area.
What you have then, is a three-way tension model where each of the arms is dynamic and can move toward or away from the others to lend support or argue against. It is conceivable that all three might move in the same direction, but it’s a much more complex dynamic than the two-way tension model.
This dynamic can be seen most frequently in meetings like story grooming, 3 amigos meetings and bug triage. Very frequently in these meetings, product and programmer voices tend to dominate conversation apart from maybe toward the end when testers are asked ‘how much time’, or ‘how much testing?’. More experienced testers will tend to facilitate these conversations and talk about what risks (and consequences) we know or can conceive of, problems with the proposed solutions and whether we even understand the problem space well enough to attempt a solution. That’s quite a different space for testing to occupy and I think there’s a real opportunity for testers to position themselves distinctly as this third discipline. That might mean repositioning our discipline as Software Research. I don’t want to get hung up on labels. The important distinction is the function we provide in these areas and to understand the value of what we do.
To paint a slightly more practical picture, think of a story grooming session with a product owner, programmers and testers. Each comes to the meeting with slightly different questions in mind. There is crossover between all three, but in essence you might break disciplinary questions down like this:
Product:
What’s the most valuable thing to produce next?
What’s the fastest way to get that to market?
Development:
What technical approach(es) will we take?
What are the dependencies and other technical aspects we need to consider?
How well do we understand the complexity of the proposed solution(s)?
(Research &) Testing:
Do we understand enough to know what value looks like?
Do we understand enough to estimate complexity?
What might go wrong?
Or to boil it down further
What do we build? / How do we build it? / Do we have enough information to answer those two questions?
I’m looking currently at the dynamics between the 3 arms and how they move toward and away from one another. I think there’s enough there for another post entirely, but considering the research/testing arm for a moment, the way we pose questions to the other disciplines describes how we apply tension, both in terms of technical:
Do the solution need to be robust (maintain its state) or resilient (adapt to change)?
and business:
Can the consumer of our story use what we deliver immediately? If not, are we building the wrong thing, or the right thing at the wrong time?
We might ask if we need to run experiments or conduct research before we continue, particularly if there is significant disagreement about the approach to take next or even what story to play. Alternatively we may throw our weight behind one of the other disciplines to support a certain action based on the different information, experience and perspective that we have.
I’ll leave it here for now, but I’m curious to see what others think. Please let me know.
Originally published at http://testjutsu.com on November 7, 2017.
