Borders and Constraints — more on team inter-disciplinary tension

In a recent post, I presented a model depicting the natural tension that exists between various disciplines in a software development team. I’ve had some interesting discussions with a number of people since then that I think have helped to clarify and refine my thinking. I’ve also borrowed heavily from Dave Snowden and the complexity space.

One thing I didn’t make clear in the last post was the reason for the circle that encompasses the tension lines. I alluded to borrowing heavily from complexity and Cynefin, but in hindsight I should have also pointed to the relevant material. This represents the accepted constraints within which the team works. One of my colleagues at House of Test pointed out one could add any number of tension strands to the circle and pull in any number of directions with varying degrees of force. I realised some clarifications to the model were needed.

The boundary represents what Dave Snowden describes as ‘containing constraints’. His post Freedom through constraints describes both containing and coupling constraints. The tension lines between the different disciplines are an example of coupling constraints. They are the constraints that exist through the relationships within the system bounded by the containing constraints.

The area within the circle as an uncertain space in which the team is trying to discover and realise value. A line of tension can exist for any discipline in the team provided it is sufficiently distinct in function from the others that its fundamental aims and activities will be at odds to some degree with the others and need to be negotiated. This is different from a clash of personalities. I’m speaking here specifically of the objectives of the discipline.

The circle around the outside represents any constraint that the team has accepted. More specifically, whilst the team may recognise some of them as problems, for the purpose of this development effort the team is not working to resolve them. These constraints may be time, money, environment, contractual obligation or any other non-human boundary.

Take for example a constraint of a time-sensitive market opportunity. Priority one is to get something functional to market in order to take advantage. Within this constraint, the team may modify its ideal behaviour (TDD, building for maintainability, rigorous testing, UX polish etc). In this scenario, the PO is likely to argue for any action that moves toward delivery and against anything else. Research/Testing and Development may well argue the case against, but will rapidly run into the time constraint.

The actions that take place within these constraints and the constraints themselves can be co-evolutionary — they modify one another. To continue the analogy, let us say that the team has agreed to curtail some of their regular activities for the sake of expedience. They also argue that this technical debt that they have decided to take on will go to the top of the team’s backlog to be immediately repaid in the next sprint. This necessarily has a time-based impact on other features waiting to be implemented and so the actions of the team affect time constraints, just as time constraints affect them.

It is important for the team to be aware of the constraints they have accepted and to revisit them regularly. Not all constraints are impediments, but a constraint that was once enabling may not always serve the team.

I’m at the point now where this model is helping me to better describe the utility and value proposition of software testing. I feel like it has utility in terms of helping to describe interactions between disciplines on a team. I haven’t quite settled on how to visualise different levels of tension between the disciplines, but if you were to ask teams to self-evaluate what that looks like for themselves over time, you might get a picture over time of how the team perceives balance or imbalance in those relationships. This is something I plan to experiment with in coming weeks and months. Comments and feedback appreciated.

Originally published at http://testjutsu.com on December 15, 2017.