The last deployment on Friday went well: no service interruptions or incidents. All technical monitoring is green. However, on Monday morning, customer complaints were raised.
Our Definition of Done does not include Functional monitoring. The team culture did not yet have this reflex in its interactions, where a checklist would have been helpful.
A systematic structure can help us improve the quality of our software building processes. A technique resulting from the consulting practice is available: MECE.
This article shares the definition, value, and how to use MECE in the context of Quality Engineering. Have a good read and use your notepads as practice reinforces understanding.
What is MECE?
MECE is the acronym for “Mutually Exclusive and Collectively Exhaustive“. Its use is associated with McKinsey in the 1960s (disclaimer: I have no action in the company as already mentioned in other articles, I just like structure). Both elements ME and CE must be present.
The MECE concept consists of creating “lists of lists” of elements at the same time exhaustive and without collisions within their list. It is recommended to have comparable elements to a maximum of 3 for an argument. Once created, we must take a step back from possible inconsistencies and errors.
MECE brings several advantages. The clarity of the structure facilitates more intuitive exchanges between the stakeholders. The systematic list-building approach also limits the risk of forgetting. Finally, we can work more efficiently by avoiding overlapping themes.
Interesting in a consulting context, what use is MECE can we make in Quality Engineering?
Why use MECE for Quality Engineering?
Our approach to Quality Engineering consists of injecting quality into our software ecosystem, from culture to operations. Our business may seem far removed from the board, yet the structure has value in other ways.
The software world is full of lists: functional and non-functional needs, white-box and black-box tests. We can split the non-functional requirements into another list: reliability, maintainability, etc. The software world also requires a capacity for change management and influence, hence the importance of logic.
Argumentation is a ubiquitous art in the history of humanity, which the Greeks widely disseminated. Over time, several models have appeared (yes, lists again). Deductive or inductive reasoning is the most commonly found, although chronological, structured, or comparative models can also be combined. Their strength reveals in a structured argument.
We can apply MECE to the software value chain, starting with the need.
Using MECE to improve requirements
The requirements collection is a challenging exercise where several practices must be balanced. Using MECE list helps us to structure our preparation, questioning, and expression of need.
The need begins by answering the two questions of “Why?” and “For what”. It is a process where we have to act as Question Asker in the role of Quality Assistance as mentioned in this round-table. Our goal is to explore the need to reduce the number of forgotten subjects, which are very costly at the end of the chain.
Let us take the case of setting up a new digital service for customers. Beyond the functional need, we can identify the channels affected by the project: the site, the mobile application, the stores? The types of customers must also be validated: are we just talking about the B2C model or others? It may seem trivial, but projects that have forgotten a significant area of need are common.
We are starting to see that MECE brings value when combined with other skills. We can improve our active listening, requirements engineering, and domain knowledge with the MECE structure. Practice and preparation remain fundamental; we must have the lists ready before the meeting. In this example, the technical design requiring balancing needs and constraints will be greatly facilitated by a good structuring of the requirements upstream.
We can also improve on a more than recurring topic, problem-solving.
Using MECE to improve our problem-solving
MECE was created to support solving complex problems that McKinsey faced. The famous boxes well-structured ensure a better reflection and possible parallelization of the hypotheses to be explored.
MECE is powerful when combined with other problem management techniques. An Issue Tree allows us to articulate our hypotheses of underlying causes to step back before sorting and prioritizing them. We can then apply a 5 Why to the verified causes, identifying the root causes. MECE is also known for its usefulness in Six Sigma.
Let’s imagine a concrete case of Quality Engineering. You must present an approach for improving the stability of deliveries; they do not manage to follow the cycles of sprints. The first step will be to take a step back from the system and identify the hypotheses explaining this instability. The next step is to quickly remove the options that we can already invalidate, to dig into the most likely ones. Making lists will help us take a step back and structure our approach. We can also take inspiration from the McKinsey’s methodology.
Problem solving also involves knowing how to convince. MECE is also helpful in this regard.
Using MECE to structure our argumentation
The best ideas, skills, and analyses available are worthless if stakeholders do not understand them. Good argumentation makes the difference in change management to convince and influence teams.
At the origin of the MECE model, Barbara Minto proposes its implementation in the Pyramid of Minto. This consists of structuring the primary message around arguments supported by data resulting from our model MECE. Again, the value of MECE is found in its combination with the techniques of logic.
In the book describing the principles of this pyramid, three founding elements in the management of change are identified. First, the analysis of the situation is oriented by facts, without emotions. Then, we have to identify the potential obstacles before finally proposing remedies. These three ingredients should be included in the proposed change argument.
Having several strings to our bow is very useful in addressing Quality Engineering priorities.
MECE, a technique to be transformed into a skill
The MECE model is applicable throughout the value chain of software creation. Like other techniques, understanding and practice are necessary to make it a real skill for our teams.
Cartesian profiles love lists at the risk of abusing them, using MECE in every way. We must keep in mind the acronym’s meaning in two steps, “ME” and “CE”, to quickly validate if our list is truly MECE. In some cases, we just need a structure or a clear description of a process.
MECE also has some interesting limitations to identify. For example, the trade-off of the structure can make us forget external or superfluous elements, sometimes important to consider. The principle of not overlapping the pieces can also be counterproductive in some instances; our systems are full of cause and effect, as explained in this article about Chaos Theory.
Let us recap the contributions of MECE within the framework of Quality Engineering :
- MECE is a model for structuring elements that is both comprehensive and non-overlapping
- We can improve our value chain by using MECE for solution framing, problem-solving and case structuring
- MECE is useful when it supports the right objective and combined with other techniques such as an Issue Tree or 5 Why
- MECE’s contributions can be increased by collaborative, agile, and emotional intelligence approaches
You can concretely use MECE for the following subjects:
- Identify and practice MECE on the most relevant processes and activities to capture its value, preferably in collaboration
- Share the MECE concept in the form of talks internal, disseminate and share the lists created on a documentary portal
- Use MECE to structure your pitch with a Minto pyramid and the logic techniques
An approach of Quality Engineering requires initial argumentation, change management, and the implementation of concrete solutions. We must prioritize the improvement of our organizational thinking structures by using MECE wisely when relevant.
What topic can you practice MECE right now?
References
Wikipedia, MECE principle https://en.wikipedia.org/wiki/MECE_principle
Anjana Gosain, Sangeeta Sabharwal, Rolly Gupta, Non-Functional Requirement Classification for Service-Oriented Data Warehousing http://www.ijsrp.org/research-paper-0713/ijsrp-p19111.pdf
Barbara Minto, MECE – I invented it so I get to say how to pronounce it https://www.mckinsey.com/alumni/news-and-insights/global-news/alumni-news/barbara-minto-mece-i -invented-it-so-i-get-to-say-how-to-pronounce-it