How do I overcome a bottleneck in a team's process, when what people are telling me doesn't match what I see
I started a new job a few months ago as a scrum master.
The team was and still is having problems completing their tasks during the sprint.
Initially the problems seemed to be tasks that were too big and there were some blockers early on in the development process. As these problems were solved the percentage of tasks in the Testing column at the end of the sprint kept going up and up. While the done column didn't move much at all.
There are two developers for each tester. Which is more testers than my previous team, but I am not sure how it compares to the industry average.
I asked how the team could help the testers. I was told the developers weren't testing the changes before passing it to the tester. So we tightened up the pretesting quantity gates. Now not only do changes need to pass code review by another developer the developers also have to demo the code to the testers before the testers test it.
The percentage of tasks in the testing column went up again. Now it is more than 80% of tasks by the end of the sprint.
I suggested that the developers and testers pair test the tasks combining the pretest demo and testing. But the testers don't trust any testing done in the development environment and they won't let the changes into the testing environment without a pretest demo. And the suggestion that the developers and testers test in both environments in quick succession is popular with no-one.
I have been talking the lead tester and the challenges they are experiencing seem significant, however I keep getting the feeling I'm missing something. I feel as if I am asking the wrong questions.
I think I need to talk to someone lower on the totem pole, someone less invested in the status quo. Smaller, more concrete, subtler questions maybe during one of those pretesting demos. I'll do that next week.
Also the complaints about lack of developer testing are louder.
My feeling is that only a few tasks are getting bounced back, but those few are causing disproportional pain to both developers and testers. Also much of the time the problem is not the task bounced back, but some other task in the testing queue. My feeling is the problems will get worse the longer the testing queue gets.
But that is my feeling. It would be nice to have some concrete numbers. With my previous team I would open up JIRA reports and I'd get some idea about what might be causing the problem. With this team JIRA reports is giving me garbage. They are saying we are getting no work done at all which is not quite true. I'd like to get the percentage of tasks reopened after testing and the percentage of time in testing, it looks like I will have to dig into JQL as the standard reports are giving me nothing.
What am I doing wrong? What am I missing?
My previous team was more cross functional. With this team I am not sure how to even begin to move them in that direction. Any suggestions in that direction are shot down immediately.
Your problem is not that you have developers and non-developers (as you call the business analysis/product owner, the designer and the testers). Your problem is that these people have individual ownership on their slice of the cake and not on the entire cake.
Here are a few things from the Scrum Guide (emphasis mine):
- Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment;
- Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis; and,
- Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.
Ideally, every member of the development team in Scrum could be a full stack developer but if in reality you have developers and testers then that's no problem at all. I've worked with such teams where developers wrote code and testers were testing it, and in some teams it worked and in others it didn't. What was the difference?
In the teams that worked well together, people collaborated. They worked together to move each story through the sprint to "Done". Developers finished their work and did a handover to testers. They explained what was going on, how the thing worked, where to look for things in the database, how to create test data, etc. Developers and testers had a good understanding of what needed built after interactions with the Product Owner. Testers worked closely with developers to prepare their test scenarios before they received a handover of the development. If someone needed help from someone else they got it. They owned all of the work, even though they were taking care of different stages of the work (design, development, testing, etc).
Care to find out how things unfolded in the teams that didn't collaborate? Everyone was doing their own thing. Developers developed. Testers tested. Business analyst wrote requirements. They only cared about "their part" and once that was over they threw it over the fence to others to deal with it next. "I've done my part, now it's your turn". Instead of all pulling together to move the ball from one side of the court to the other, they just bounced the ball back and forth between each other until someone eventually said "good enough".
Your problem is not that people have different skills and are not cross functional. Your problem is that their skills don't complement each other. Their skills don't mix, they stay layered.
If you put developers to test more and testers to develop more, people will start to hate it. Find ways to make them work together. How exactly, I can't say. It depends on the team's dynamics. You might need to experiment with a few things. Test out some other things. Look at the entire picture and figure out what's going on. You might need to track each story in the sprint individually and determine from that where the friction points are between people. Then think how to work on that.
And keep in mind that it might take some while to improve the way people work together. You said you started as a Scrum Master a few months ago. How much time have these people worked the way they do now? That's how they do things. They might be so immersed in their way of doing things that they don't notice that there might be better approaches. You, on the other hand, are new and you see the problems. Work with them to improve communication and collaboration first, and later you can all look for ways to improve the process.