This article kicks off a series, which I hope will last a very long time. The goal is to take 2 terms that look like synonyms, but which, in the detail of their differences, can tip a capital decision. The saying "Talk little, but talk well" seemed perfectly fitting to me for multiple reasons that I'm going to detail.
In any field, communication between people has an extremely important place and often conditions the failure or success of projects. Over the course of my experiences, I've realized that a great many problems and misunderstandings were essentially due to a lack of understanding between the speakers. Misunderstandings that can breed feelings of frustration, anger, even resentment or animosity toward others. A primal reflex would be to quickly lock ourselves into a procedural, administrative, distant, even conflictual approach that goes against agile values. The effects being devastating for the project (slowdown, delay, sub-quality, abandonment, etc.)
The origin of these misunderstandings is often that the meaning of the words used is not necessarily the same on both sides. This can be understood through the use of specific business jargon or abbreviations, but sometimes through the simple mastery of the language itself. Not everyone has a dictionary as a bedside book (yet super effective as a sleeping pill). It is therefore useful that from the very start we agree on a certain number of sensitive terms (e.g.: delivery, acceptance report, defect, etc.). What's more, if you write this down in your documentation (which is kept up to date, of course), you'll make newcomers happy and often avoid long useless debates. Of course, the definitions are not immutable and can perfectly well evolve along with the project's context.
The most perceptive among you will have sensed that one must not limit oneself to the mere definition of certain terms. Indeed, where vocabulary is the micro view of relationships, you must broaden your horizon and also define the processes, without overdoing it either. The definitions of ready and done ("Definition of ready/done") are a very good example of this. But we're stepping out of the scope of the article series I want to run.
So I suggest a first post on the "Complex VS Complicated" pair which, as you'll see, opens the way to other notions that are very useful in project coaching and monitoring.
