The agile world was touched by the new version of the Scrum Guide released by Scrum.org at the end of last year. It presents transparency as one of the three pillars of empiricism in scrum, right next to inspection and adaptation. The previous version of the Scrum Guide included a sentence that I don’t think I ever paid much attention to, which reads: “Transparency doesn’t occur overnight, but is a path.”
In the previous version of the Scrum Guide, the scrum master was identified as being directly responsible for transparency in the project, and more specifically for defining the path to achieve it as fully as possible. Now, the focus has been shifted – Working on the pillars of empiricism, as well as the values of scrum, is the responsibility of the entire scrum team and its collaborators. Removing some of the tasks so far assigned to the scrum master such as “driving change”, can in my opinion cause confusion and misunderstanding, especially among novice scrum masters.
That’s why I’d like to now focus on the word “path” mentioned at the beginning and analyze it in the context of teamwork and employee self-development. Let me give you my interpretation.
Based on the Scrum Guide 2020.
A little bit of theory
First, let’s start with a bit of theory, without which it may prove difficult to start and understand the context.
Transparency, as defined by the creators of the scrum framework, means that “the process and the work being done must be visible to those doing the work, as well as to those for whom the work is being done. (…) In scrum, important decisions are made based on the observed state of its three artifacts. Insufficient transparency of the artifacts can lead to decisions that result in reduced value or increased risk.” (source: scrumguides.org).
As I mentioned before, transparency is one of the pillars of empiricism in scrum. But if we replace the word transparency in the sentence quoted at the beginning with any of the values represented in scrum – commitment, courage, focus, openness or respect – we get a very important piece of information, which I think can serve as a guideline, both in our projects and in our personal lives.
To become experts, we need time and hard work
Heidegger wrote that whoever wants to learn to think, must begin to think, which may seem to be truism. However, it is actually a profound observation. It also makes us realize that no one is born an expert. Professionalism in any field is paid for by hard work, lots of mistakes, hours or even days spent looking for the right solution. The journey always starts with the first step, which is often the most difficult, because it requires us to abandon what we know and what we are used to.
The aforementioned journey is particularly evident during the formation of new teams. Suddenly, we put together a group of people with often very different characters, traits and habits to work together. For some, leaving one environment and moving to another can be very stressful. In a new team, we start from scratch – we learn about each other, we explore who we are, what is important to whom. Knowledge, I would say, procedural knowledge does not appear suddenly, but is a process of learning and gaining knowledge. We have probably worked with different teams and different people before, yet we are still not be able to copy and use the experience we have gained before to its full extent. This seeming paradox makes us realize that life, also project life, is a constant road in which with every step, with every new team, we learn something new.
At the same time, I sometimes have the impression that professionalism in its common meaning does not allow us to admit that we do not know something. Because how would it be for me, the expert, to confirm that I don’t know something? Even the most experienced employees in a new environment need a moment to find themselves, to find the thread of understanding with others. What else, but not a path, is the time it takes to acclimate to a new project, or the extended time we need to understand the context and business objective of a client?
Are the professionals aware that they know so little?
On the other hand, we should mention the Dunning-Kruger effect, which in short states that one’s skills are evaluated differently depending on one’s actual degree of competence.
In a paper published in 1999 in the Journal of Personality and Social Psychology, Justin Kruger and David Dunning of Cornell University hypothesize that incompetent people do not perceive a low level of knowledge in themselves and cannot correctly assess their own and others’ level of knowledge. Therefore, assisting a scrum team member in self-development, as well as mentoring and coaching, is one of the most interesting and challenging roles a scrum master has to play. I’ll leave this discussion for a separate article though.
The archetype of such a path brings to my mind associations with striving for perfection, but at the same time with the awareness that I haven’t yet reached my destination and that I have a long way to go to reach my goal. Something like the Socratic “I know that I know nothing” or one possible response to the Dunning-Kruger effect mentioned earlier: experts in a field realize for themselves how much they don’t yet know.
I don’t mean false modesty, but rather an awareness of the journey – that is, of continuous learning, even by those we might call experts. I would like the above article to be a warning for me and for you – my readers – never to rest on the laurels of our own vanity, but rather to be aware of the vastness of knowledge and experience that is still waiting to be learned.
