The success of agile projects is directly related to the way the scrum teams communicate.
Many teams and projects identify these as their biggest problems without being able to articulate them precisely. The biggest problem, however, is that everyone believes they know what communication is and therefore does not need to think about it further.
This article is dedicated to this misunderstanding and the impressive power of communication.
Content of this article:
Let the adventure begin
Of course, we have all heard it before: Scrum as a methodology relies more on direct communication than on extensive documentation and specifications. But what exactly is communication and how is it used in the Scrum context?
Admittedly, this approach sounds pretty dry. But this article won’t be a pseudo-academic discussion. Instead it will be an adventure, because…
We want nothing less than the movie Inception.
Leonardo DiCaprio in his famous role in the Hollywood blockbuster today will be our Scrum coach. That certainly makes for some good entertainment.
What do we expect from Scrum teams?
We expect nothing less from them than that they develop breathtaking software instantly and without major specifications.
This is no easy task. They have to deal with more and more complexity in less and less time (time-to-market). Welcome to the 21st century!
Let’s imagine that Inception does indeed work. I am a customer, product owner or stakeholder, and I have a product in mind. Now I meet a development team.
It would be fantastic if I could simply implant my vision of the product into the brains of the developers and they could completely assume my perspective.
Combined with their technical skills, it would be a lot easier to implement the product.
That’s what we want!
And we can have that.
The key is communication.
But not in the sense that we communicate a lot and directly, or deal with each other in a particularly nice, respectful and appreciative way. Of course we should. But that’s not enough.
We must grasp communication as a much broader concept, so that we really achieve something akin to Inception. And we will do that right now.
Inception in action
In my trainings I regularly ask people about communication and what it is all about. Usually I get the answer “Communication is the exchange of information between a sender and a receiver”.
The answer is undoubtedly correct. But, at the same time, it is far too short for our purpose. With the sender/receiver principle, we simply cannot make it to Inception.
In other words, the definition is correct, but we couldn’t have said it in a more unromantic way. Yes, you have read that correctly. We really need a romantic definition of the term, one that leads us much closer to our goal. Here is one:
Communication is the mutual invitation to enter another person’s reality.
Customers or stakeholders live in their own reality; a reality that is mainly shaped by business expertise.
On the other hand, developers also inhabit their own reality, which is more technical than the business reality of customers and stakeholders.
As a result, they clash and do not have much time (remember: time-to-market) to describe the object of development in such a way that the description doesn’t become a costly bet on the future, but is sufficient to develop any kind of software.
A bet on the future turns into a specification if I have to trust that the specification was good, but I can only check it relatively late on the object, virtually after the unveiling of the monument.
“Enter my reality”
Communication in Scrum has the goal of overcoming this barrier of different realities between roles as quickly as possible. It is rather a cultural concept than a technical one.
It’s not about how much and how direct, it’s simply about how. We need a culture that gets the change of perspective between customers or stakeholders and the development team going as quickly as possible, so that both parties can understand each other’s reality.
This is what the true function of the product owner is.
He not only turns professionalism into functionality (which is not the same, by the way), not only defines a product from a business process, but above all promotes this shift in perspective on both sides.
But how can he do that if he only writes stories?
Well, that might just be enough.
The only question is how these stories are written and why they are enough to initiate Inception.
Read the article “How to write a good story” for more details. (coming soon)
In that article I explained that a good story should consist of four parts:
Motivation, which describes from the perspective of the PO why he needs this story.
Description, which describes the scope from the user’s point of view (“As a user, I want this and that. For this purpose I have this available to me. If I do this, that will happen.”).
Acceptance criteria that describe “When is it good?” and under what circumstances will the PO accept the implementation of the story?
The test cases once again shift the perspective. They do not represent the perspective of the user as many may believe, but the perspective of the application itself.
This means that we have at least three perspectives of the feature to be implemented, i.e. almost a 360 degree view. That helps a lot.
However, the key to Inception is the first and undoubtedly the most important part:
Motivation
Because the process of getting to know each other always works by means of motivation. If I know why someone acts the way they do, then I also know what will likely happen next.
Children between the age of 3 and 4 radically change their communication strategy. Until then, they always ask for the names of objects.
But at that age that’s no longer enough and start asking those annoying “Why?” questions. Imagine an entire journey by car with endless “Why?” questions, seemingly aimless or just to annoy the unfortunate parents.
But at this age children look for their place in the world and try to make the connections between the things they can now describe. This can only be done through motivation, which in their case is “Why?” questions. These questions are their key to the world.
And the same is true for the relationship between stakeholder, product owner and development team. Communication that uncovers motivation creates this change of perspective. A corporate culture that creates transparency at all levels can do that. The mere exchange of information cannot.
