The transparency of language in an environment of Scrum
Our real-time, globalized world thrives increasingly on information and technology. The balance of businesses and society has rapidly shifted from industrial (often physical) labor to digital (often virtual) activities. The world seems to be changing faster and less predictable than ever before. We used to believe a majority of our problems to reside in the ordered stability space, but we find ourselves living and working in the complex novelty space nowadays, the space where more is unknown than is known.
The industrial recipes of Excel-based management, unlimited expansion, shared resources, efficiency and utilization don’t apply anymore. Agility became a critical state for organizations. The Agile paradigm is replacing the old, industrial paradigm. Scrum is a clear and the most adopted definition of Agile, and the third Scrum wave is rising.
The principles and ideas underlying Scrum are a better fit for navigating the complex novelty space. Scrum introduces new language and terminology to express the novelty of those principles and ideas. It makes the impact of the change more transparent. The new language and words however are often copy-pasted to be embedded in a broader old, industrial setting; against the illusion that work happens within the ordered stability space. The words get disconnected from their novel intent, meaning or feeling. Shifting to a new paradigm includes the conservative tendency to mimic, isolate, copy, paste what is perceived as trendy, popular and profitable.
Rigor is required in morphing towards an Agile way of working. The real challenge is not even to just sense whether our words are remainders of the industrial paradigm and don’t apply anymore. We need to remain conscious about the continual evolution of insights within the new paradigm, and how this is or is not expressed in our language. Unknowingly we grind, grow complacent. The Agile space, in which we operate, keeps evolving. We discover better ways to express our intents than blindly repeating what others are saying:
- Do you recognise how teams need to be ‚high-performant‘, and such high-performing teams must be built? 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 intense collaboration. Rather than aiming at high performance in itself, often hinting at productivity, facilitate collaboration. Foster an environment, clear the way for people to interact, to share, to disagree. Highly collaborative teams will perform.
- ‚Maximization‘, even unintendedly, has a smell of infinite expansion, endless growth. As does ‚continuous improvement‘. It leaves an impression of unlimited accumulation; more, more, more. Where is the room for reflection, adjusting, changing direction, adapting, maybe even turning back? 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, regularly adapt. What works today might not work tomorrow. More changes than remains stable. Continuously adapt and optimise the value of your work.
- Many inhabitants of the environments in which we operate are discovering that in the complex novelty space more changes than remains stable. Exact, detailed, upfront, long-term predictions no longer work. At most we strive for 'predictability'; forecasts based on the past reality. I prefer reliability even more, the fact that people and teams are reliable and transparent in the hard work they do. It creates awareness that it is all about discovery, discovering what is needed to make the best possible progress towards hopes, goals, ambitions and vision.
- Technically, Scrum says an Increment should be releasable no later than by the end of a Sprint. For many organisations that already represents an incredible leap forward, let alone the ability to have releasable versions of product even sooner. We can raise the bar even beyond that, set a new dot on the horizon. We can share the expectation with teams and organisations that Increments are expected to be not just be 'releasable', but be valuable. Consider what you are defining as Done. An Increment, by default, is potentially valuable, as value is an assumption that can only be validated by releasing and gathering feedback.
Mind that language, when not blindly mimicked, expresses your mind-set and beliefs. Reflect on what became traditional Agile terminology in the meantime. Move away from false dichotomies that don’t reflect the reality of iterative-incremental discovery; eternal growth, succes vs. failure. Mind your words. What you say can and will be used against you.