​ What you say can and will be used against you

​‘Agile’, the mind-set expressed in the Manifesto for Agile Software Development (2001) and its underlying principles, introduced very different ways of thinking about software and product development:

​Agile adoption grew, with Scrum heading the pack. The changes in principles and ideas spread, and new language was introduced, often replacing old language. At the same time, Agile turned into an industry, the new thingie that seems required to be successful and make money. Inevitably, along came the tendency to mimic, copy, paste what is perceived as successful and profitable. The new language and words were copied, often disconnected from their intent, meaning or feeling, often forgetting to consider whether the words we use still apply.

I invite you to keep thinking about the continual evolution of insights, and how this is (not) expressed in language. Unknowingly we sometimes grind, certainly in a world of creativity where learning is continuous and collaboratively. Alongside the adoption of Agile thinking, terminology evolved. But like agility has no end-state, language shouldn’t have an end-state either.

Much of the commonly used terminology in a context of Agile still has the old undertone of top-down expectations, suppression and productivity:

• Do you recognise how teams need to be high-performant, and coaches should build high-performing teams? A team however cannot be constructed by an external force. Nor is a group of people necessarily a ‘team’. A team is a cohesive collective of people working towards common goals and objectives, thereby jelling and overcoming resistance, internally and externally. A team is what emerges through intense collaboration. Performance arises from such collaboration. Rather than aiming at high-performance, facilitate collaboration. Clear the way for teams to interact, to share, to disagree. Highly collaborative teams will perform.
• Maximization, even unintendedly, has the connotation of endless growth. As does continuous improvement. It leaves an impression of unlimited accumulation; more, more, more. Consider to optimise what you do. Make the best of what you have, of what you are able to do. And while doing so, in order to do so, continuously adapt. What works today might not work tomorrow. Continuously adapt to optimise your way of working and the value delivered.
• Much of the environments in which we operate are coming to terms with the idea that predictions (exact, detailed, known upfront) don’t exist in the complex and creative world of software and product development. The alternative is to strive for predictability. I am not denying the idea that predictability is possible; forecasting based on reality offers us just that. I prefer reliability more, the fact that people, teams and their hard work can be counted on. It might help create awareness that it is all about discovery, rather than even predictability.
• Technically, Scrum says an Increment should be releasable no later than by the end of a Sprint. Although achieving just that is an incredible leap forward for many organisations, we can raise the bar, set a new dot on the horizon as Scrum adoption grows. Let’s share the expectation with teams and organisations that Increments are expected to be valuable. An Increment, by default, is potentially valuable, as value is an assumption that can only be validated by releasing.

​Mind that language, when not blindly mimicked, expresses your mind-set. I invite you to step away from what has the danger of becoming traditional Agile terminology. Step away from the false dichotomy of eternal growth, succes vs. failure. Mind your words. What you say can and will be used against you.