Why You Should Start with Design Thinking When Launching a Successful Scrum Project.
As an Agile coach, I have had the opportunity to accompany various Scrum launches and coach different teams over the last years. In doing so, I was able to achieve great success with the teams in efficiency and reliability. However, in one key area, my teams fell short of my expectations: user-centricity.
To better understand this problem, let me tell you about the best team I had the privilege to work with. It was a fairly newly formed Scrum team of mostly young colleagues and an inexperienced product owner. Different expectations, especially about the quality of the acceptance of the user stories, led to tensions between the Development Team & the Product Owner. Since the Development Team did not feel understood enough by the Scrum Master, I took over his task to take the tension out of the team.
We managed relatively quickly to reprioritize the backlog with the relevant managers and stakeholders and reduce the pressure on the team. By making more realistic estimates of the scope of the user stories, we were then able to deliver desired quality at the promised time. Even though I tried to build a strong team through various measures in retrospectives, workshops, and events, no measure is as effective as success. Therefore, it was especially the first two measures that made it possible to form this team – whose first experiences were characterized by mistrust and failures – into a team that stands for trust and reliability.
It was foreseeable that this team would soon no longer need my support and could be taken over again by a less experienced Scrum Master.
If I ended the story here, it would be a pure success story, but I wanted my last weeks with this team to count as well.
So I pushed the team to take on a feature that a specific customer had been waiting for for a long time. I thought it was a good example of becoming more customer-centric. It wasn’t that this wasn’t considered at all. There were two meetings a year where all customers were presented with the results of the last six months and given an outlook for the future.
However, I felt that this was not enough to understand exactly what the customers wanted. So we started to talk about the feature regularly with the customer in short Skype meetings. When we thought we had found a good solution, we made an appointment to present our solution and a few other topics in the morning, and a factory tour in the afternoon.
We planned the trip to our customer as a real event and set off with a relatively large delegation and a really good feeling. When we arrived at our customer, we received a very warm welcome, as we were the ones who finally had the longed-for feature with us. At least that was the plan.
Within the first hour of our meeting, it turned out that our solution met the requirements in theory, but was practically worthless to our customer. We interrupted the meeting to work flat out in the team and with our colleagues at home to find another solution.
But it quickly became clear that we would not be able to meet the customer’s requirements with what we had prepared. So, back to the meeting: admitting mistakes, “back to square one” again, mood down.