When you are wrong, even if you are right
Last week I conducted workshops with two teams I am working with, and few more people from Scrum Guild which I am leading at SIENN.
The goal of the workshops, was to remind and understand (for the few new ones) the value of several types of requirements, which can be used as parts of the PBI’s definition. These requirements’ types constitute the greater complexity of the PBIs. The first part of workshops was theoretical presentation and it took about an hour. I was sure that it would be a great introduction to practical part of workshops, especially because during lecture I gave five highly important tips; how to work in Scrum Teams with PBIs, how to build trust between PO and devs, how to ask questions, and – the most important, that there are no stupid questions. It is always better to ask, than to assume.
The second part of our workshops was practical simulation Scrum game. The main rule of the game was to implement the whole knowledge from theoretical part, to make your work more efficient and much easier, so: ‘How to you use, what you heard and make it work.’ It did not work at all. I guess it was only ‘heard’, but for sure it was not learned.
The first mistake I made, was that I assumed that attendees (especially team members I am working with, for more than a year) would understand the value of the first part of workshops and use it as a rule for their practical work. I did not tell them this, because I assumed, they understand. They did not.
The goal I wanted them to achieve, was easy: they should focus on various types of requirements (like: user story, use case, business value, etc.), which they got from me, and summarise these requirements’ types into complete understanding of a complexity of the specific PBI. The main reason why we decided to do these workshops once again is that the application developers are working on is much more complex than it was a year before, so the complexity of the PBIs is greater. I thought it would be very valuable to remind my team members, that focusing on complexity means focusing on difficulties of development. It is recommended to understand that the complexity means that while looking at the PBI, we should see the bigger picture. To achieve full understanding of the workshops, all the attendees had to ask questions, and to be honest, they should ask a lot of questions – directly to me. Sadly all the attendees made a lot of assumptions. They assumed, that I am a game facilitator, but not a participant. They assumed, that they could not ask me any question dedicated to the task they got and they assumed, that they cannot support each other.
During development part of workshops – the practical one, they asked only two questions, and none of them concerned the domain knowledge of the task. Assumptions, which I asked them not to do on the theoretical part of the workshops, were the main driver for all teams and made the delivery harder to achieve. There was so many grey areas, and questions which should be asked to me, that development was much harder without them. There were so many competitors, even if I said, it is not a competition, and we are not going to get any prizes. Everybody wanted to win.
The last part of the workshops was a summary part, when we made conclusions together, about what had happened. When we took into account every detail of whole game, we all realised how much we misunderstood. How much assumptions were made and how wrong it was. So, I started with assuming that people would follow what they heard during the presentation. At the same time participants assumed that there are forbidden questions and actions, such as sharing their requirements and materials. As a result, they have delivered product based on those assumptions.
We did not have a common understanding of what happened – at the beginning, but then suddenly we realised, that the core of the problem was not that the requirements are too complicated or PBIs have less types of requirements than they should to be understood. The main reason why these teams slowed down and lost focus on PBI’s complexity, was that they lost understanding of business value of the features they are implementing. The reason, why they did not ask me questions was that they made assumption that I would not know the answers. They believed they would waste their time and energy on something they would not get any value out of. In the end I was right when I proposed workshops – the problem had existed, but it looked like, nobody knew, where the problem began.
Today, basing on the knowledge from workshops, we know how we can improve, what to do and how to do it. My private conclusion is that sometimes you can only see the tip of an iceberg (like I did) and you do not know what is under the water. But even if you do not know everything, you need to alarm teams about risks you sense. I was wrong about the cause of our problems, but I was right that the problem existed. I made a lot of assumptions about what they need, and how to work with them, and in the end it did not work.
I asked the team, what value of the workshops they see, and they all said: ‘We need to ask more questions’. They know, they need to change their behavior in order to improve. And to be honest, it was worth it to be wrong. The lesson I learnt is not to assume. Just ask.