Hit Plateau in 2nd Year of Scrum! Need ideas!
Hello! I am the CSM for a non-profit with a small team of developers and testers. As with a lot of non-profits, we are understaffed and have team members pulled in multiple directions to cover everything needed. In our 1st year of implementing scrum, we had a fair amount of success and saw definite improvements in comparison to the team's old waterfall methods!
Now, that we are in the 2nd year, we seem to have hit a massive plateau and have not reached our sprint goals in the last 4 sprints. The bottleneck seems to be UAT. The users that are doing UAT are very understaffed and do not have dedicated testers on our scrum project. So, things aren't getting done which prevents the team from getting things "done" and limits the amount of work the developers can get done per sprint.
So, does anybody have any suggestions on helping the team move forward? Is it a matter of changing our DoD and not including UAT? If that happens, all of our testing will back up. When would we get that done and approved?
We're just stuck and I don't know what to do until we can hire more people! Any ideas are welcome.
Thanks in advance!
Can you explain why UAT is being conducted by an end user group rather than the team itself? Why isn't it a team responsibility to meet this part, as well as all other parts, of the Definition of Done?
Fair enough . . . we took it literally and wanted to have at least one actual user that could be a part of the team for UAT in case anything got lost in translation between them and the developers. As it turns out, we have 2 users involved doing that. We still wouldn't mind having 1 dedicated user doing some testing but we don't have that luxury.
That being said, we are still learning . . . is it normal to not have any users involved in the team/UAT? What do you recommend?
> ...is it normal to not have any users involved in the team/UAT?
The expectation is that "user involvement" should be rather more pre-emptive than that. There's no proscription against including users as team members, or against having UAT activities. What matters is that team members aren't constrained by skills-silos. A silo (such as doing UAT) leads to bottlenecks, the delayed detection of errors, and rework. Your team is currently experiencing those issues.
In Scrum the Development Team should work with a clear Product Owner in order to deliver each increment. The PO may liaise with users so that requirements can be understood and conveyed to the team in a timely manner, and so that waste including defects can be avoided. This includes Product Backlog refinement, Sprint Planning, and ongoing collaboration with the team and stakeholders during the Sprint. I suggest you review the PO's responsibilties in this regard.
Thank you, Ian! This is great info and confirms what I've been thinking. It is great to get these thoughts from a scrum veteran outside of our organization. I'm actually getting with the PO and the director over the department tomorrow to discuss a re-boot and re-evaluate how necessary it is to have the users involved at the current levels. It clearly isn't working and I hope they will see that so we can move forward! We've gotten away from "true scrum" and we need to get back! Thanks, again!
I don't know if this adds any more value so I keep it short: In our case, we lay the options Ian mentioned on the table with each new team. And they indeed chose different approaches. Some have a PO who is very close to end users and validates for them. In some cases, the PO IS an end user. Other teams include end users from other departments into their daily work. Others work with "business enablement" teams who join the Scrum teams and validate. Some teams tried one way, it did not work out, then they changed it and it worked better. Enabling the teams to make that call and choose different approaches turned out to be the right thing.