If you have worked in a scrum team, you’ll know that often you need to slow down first to get the results you need. In this article, we share a story about a team we worked with and the 7 warning signs which helped us to identify why they were consistently building the wrong thing, resulting in unhappy customers and stakeholders. We then share what we did to get the team building the right thing for their customers.
Our consultant was asked to coach a team to help work out why there were so many defects, resulting in a low-quality product.
Through a process of coaching, observations, and one2ones we recorded the following 6 symptoms or warning signs:
- A very large number of defects
- Long daily scrums
- Missed requirements
- Stress in meetings
- Lack of trust between business & engineering
- Unhappy customers
Now we had identified some recurring symptoms, we needed to find what was causing this to happen and whether the defects were a result of a lack of technical quality or something else.
What we did:
Slowed right down. For example, we went from 10 stories to 2 in one session. This was a major reduction in potential productivity, but it was needed so we could begin to see any patterns. The clock was ticking… if things didn’t get better, we would need to speed things back up due to external pressures from the rest of the business. This needed a careful balance between allowing the team space and time to slow down and the project sponsors’ trust in order to demonstrate the value in this.
After one particularly bad sprint, the Product Owner asked, ‘why are we still getting so many defects?’ The room went silent. We picked a random defect and used the five whys analysis. To our surprise, we discovered the team didn’t understand the fundamental requirement! Eureka!
We then realised that many of the defects were a result of a simple lack of understanding of the business domain. Once this crucial realisation was made, all the pieces started to come together.
How we did this:
As part of the slowing down process, we changed our refinement meeting to teach aspects of the domain. The team also co-created a list of questions for the PO for this session. This enabled the space for the team to ask meaningful questions as they didn’t feel pressurised to get through the usual list of 10 agenda items or more. We did this for several months.
Even though this was at the expense of build time, we knew we could significantly increase the team’s understanding as well as building trust between the PO and the Team. Trust is the absolute foundation of any team. When there is an absence of trust a number of negative behaviours emerge, not least because team members will be unwilling to appear vulnerable within the group. Moreover, trust contributes to the psychological safety of the team which impacts team effectiveness.
It was time to teach:
Our PO had 30 years’ experience in this domain and had assumed everyone else shared the same amount of knowledge he had (– warning sign number 7!). Which, of course, they didn’t.
We set up a weekly classroom training session for him and the team. With 20 years of knowledge stored away, the PO had a lot of information to share and was eager to get through it all in the first week. To avoid information overload, we instead designed a steady cadence of material over a 3-week period to ensure the team fully understood the domain. One of the important activities that came out of this training was a role play exercise between the PO and the Devs, where the team performed the role of users of the function.
In time, and once everyone had gotten over feeling awkward, we started noticing the change in mindset and, therefore, behaviours. Benefits which could take years to realise begun happening within just a few months. The benefits of this shift in mindset and behaviours became apparent when the team began to push back when they identified potential issues which would make the customer’s workflow far more difficult. An awesome result of the team understanding both the domain and perspective of the customer. The feeling of Team Morale went through the roof.
Resulting in:
Shorter daily scrums – due to fewer questions from the team to the PO because they had the right understanding.
Less stress in meetings – the primary cause of the stress was the PO’s frustration in having to explain the smaller, seemingly less significant details because the team lacked a fundamental understanding.
The right product being built – because the PO now knew the team had the right knowledge, were demonstrating the right behaviours and understanding, he now trusted the team could build the right thing and even began listening and agreeing to the team’s suggestions on what the customers might want!
If you are experiencing similar problems or this story resonates with you, please talk to the AWA Team about how we can help you.