Stagnating Team Performance and the Disagreement over the Basic Operating Assumptions
I. Stagnating Team Performance
A. One Way Up, Many Ways Down
Success generally requires the simultaneous satisfaction of multiple criteria and constraints. Often, one of them is enough to turn success into failure. This rule can be applied to almost any endeavour, including, for example, a software development team looking to complete its deliveries on time and budget.
In this article, we will discuss one of these conditions for success: the team’s agreement on a set of basic assumptions regarding their identity, mission, and objectives. More specifically:
More specifically:
To illustrate how critical this agreement is for collaboration, let’s consider the following example: a team of engineers and builders is provided with architectural plans for building a house. If they cannot agree on the interpretation of symbols in the plan or on the best way to execute those plans (foundations first or last, electrical installation before decor, etc.), the project will surely fail.
What else can you find in this series?
B. The Need for a Baseline
If you are not yet convinced that establishing a baseline and a shared understanding of some fundamental notions regarding a team’s identity, mission, and objectives is necessary, let’s flesh out the details of what this means using software delivery as our example.
In software delivery, software development teams use Agile or Waterfall practices to run their software development lifecycle or SDLC. What could happen if a significant portion of the team does not necessarily see the benefits of code review, considering it to be, at best, a distraction and at least a waste of time?
Well, the developers will push back, diverting attention and energy into futile discussions and compliance enforcement. On the other hand, how can a manager convince these developers of the need for code review, a somewhat self-evident truth which, by definition, should not require justification? Could it be that in their previous roles, they successfully delivered quality software without the need for code review? It all comes down to our personal and unique professional evolution, expertise, and past experiences.
II. Traditional Consensus-Building Methods
A. Consensus-Building in Teams
The self-evident truths are self-evident for the manager making the assessment, but they might not be for all members. Here, we consider reality (limited to the context of the team and its operations and not the entire universe) to be partially, if not entirely, subjective. This subjectivity creates conflict. The traditional ways of dealing with this conflict have been as follows:
Suppose a manager decides to adopt the consensus approach. What would be the best way to persuade the team (or its majority) to adopt a particular view and establish the prerequisite shared assumptions? The following methods come to mind:
Let’s discuss the pros and cons of each.
B. The Rhetoric-Oriented Approach
The rhetoric-oriented approach is the safest but least effective method for building consensus. It uses the prevailing cultural concepts of the time as its main argument to drive the points through. It assumes that if people are happy to accept established universal concepts, such as the need for collaboration and cohesion in groups, then the specifics of how this can be implemented will follow effortlessly. Of course, the devil is always in the details.
In practice, this method is almost always ineffective. The team is simply not convinced, especially when they cannot logically link the manager’s views to his rhetoric.
Moreover, the implementation details proposed by the manager are not uniquely derivable from the principle elements of his rhetoric. In fact, other implementations (ones they can readily think of on their own) can be equally supported by the same arguments. In such situations, groups appear demotivated and disengaged and might agree to what has been said without much conviction.
C. The Fact and Logic-Driven Approach
Another method managers use to persuade a group to adopt particular views is the fact- and logic-driven approach. This approach is more rigorous and time-consuming, but it is also relatively easier to challenge. Loopholes can always be found in the data, insights, or logic used.
The fact- and logic-driven approach also has another drawback: it is almost certainly conducted from the manager’s vantage point. This drawback can be verified when we examine the metrics used to analyze the data and derive insights. Are these metrics designed to downplay certain aspects and overstate others? In most cases, they will be. If they did not support the manager’s views, they would not have been used in the first place.
D. An Approach Based on Natural Philosophy
Dave Snowden, the inventor of the Cynefin framework, developed “naturalized sense-making” as an approach to understanding the world using natural philosophy and science rather than opinions or subjective interpretations of events and experiences.
Applying this strategy, we propose an alternative method to establishing shared assumptions in a team based on formal systems and logic. Let’s see what it offers.
III. A New Way of Building Shared Assumptions in a Team
A. Formal Systems
The concept of a formal system of axioms, theorems, and logic is elegant, powerful, and appealing. It is structured as follows:
How Are Formal Systems Structured?
A formal system allows us to derive sophisticated and complicated statements of truth from basic assumptions. Should the assumptions produce incoherent or inconsistent results, they will be challenged and possibly replaced.
B. A Structured Approach to Group Processes
What can a formal system of axioms, theorems, and inference rules tell us about group processes in general and software development in particular? Here are some insights:
C. Challenging Fundamental Principles and Innovation
Challenging basic assumptions daily is detrimental, but once in a while, it can spark innovation. Take DevOps, for example.
For a very long time, it was taken for granted that development and operations were two different universes. Development and operations teams differed on every account, from skill sets to mission, objectives, and even style.
For all that time, software companies that ran their own applications also understood the value of connecting the two worlds. During the past few years, the assumption that development and operations became weaker. New tools and novel development strategies, including continuous integration and continuous deployment (CI/CD), automated testing, and Agile practices such as cross-functional teams, made the fusion of the two worlds possible and viable, and we got DevOps.
IV. Appendix
A. Formal Systems
A formal system is a structured framework consisting of a set of rules and symbols designed to produce and manipulate strings of symbols according to specific syntactic and semantic guidelines. Formal systems are foundational in various disciplines, including mathematics, computer science, and logic. Here, the components and functions of a formal system are outlined in detail:
1. Components of a Formal System
2. Functions of a Formal System
3. Applications of Formal Systems
In summary, a formal system is a meticulously defined framework that facilitates the rigorous manipulation of symbols according to predefined rules, enabling the derivation and proof of theorems. Its precise structure and components ensure the systematic exploration and verification of abstract concepts across various disciplines.
B. Euclid’s Geometry
Euclid, the ancient Greek mathematician, stands as a giant in the history of geometry. Around 300 BC, he compiled his groundbreaking work, “Elements,” a systematic treatise that laid the foundation for Euclidean geometry, which dominated the field for over two millennia. The cornerstone of “Elements” was a set of five axioms, or self-evident truths, upon which Euclid built his entire geometric edifice.
The five axioms of Euclidean geometry attributed to Euclid are as follows:
The last axiom, also known as The Parallel Postulate, was particularly troublesome; it did not seem as evident or elegant as the others. It became a thorn in the side of mathematicians for centuries. Many attempted to prove it as a theorem based on the other four axioms, but none succeeded. The problem? The fifth axiom wasn’t inherently obvious – it was more like a hidden assumption about the nature of parallel lines.
V. References
- Book Review: Gödel, Escher, Bach: an Eternal Golden Braid, by Douglas Hofstadter, 1979