As part of our commitment to excellence and innovation, we’re constantly developing, testing and launching practice-proven features to help your organization stay and scale agile. Therefore, more exciting features will be launched soon. See our upcoming features in the list:
Tips & best practices:
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 do not need to think about it further.
This article is dedicated to this misunderstanding and the impressive power of communication.
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.
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.
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 reality; a reality that is mainly shaped by business expertise. On the other hand, developers also inhabit their 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.
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 the true function of the Product Owner.
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:
which describes from the perspective of the PO why he needs this story.
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.”).
that describe “When is it good?” and under what circumstances will the PO accept the implementation of the story?
which 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:
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 they start asking those annoying “Why?” questions. Imagine an entire car ride with endless “Why?” questions, seemingly aimless or meant 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.
The same is true for the relationship between stakeholders, product owners and the development teams. 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.
Why we should not mix agile and classical project management – or why traffic lights are not helpful at roundabouts.
With the WSJF technique, prioritization and PI Plannings become damn easy, highly effective and even fun! Step-by-step guide and free WSJF Excel template
What is it that renders the role of the scrum product owner so problematic and how should it be designed to allow an agile transformation to succeed?
Where value flows & business aligns –
The first AI-powered scaled agile project management tool.
