When does whole-team collaboration become an impediment and not a desirable quality of the team? For me, it has been when the team don’t stop the discussion process and get on with writing software.
A change to one of the new features emerged towards the end of the Sprint, and after some digging, the Product Owner wanted some options to take back to the stakeholders so they could then decide on a course of action. The first discussion started off with a few around a whiteboard walking through the issue, but the number quickly grew as other team members joined the discussion. No problems so far.
The problem came when people, particularly those not there for the start, started to move the discussion away from the original scope to include other areas affected – essentially bringing a high-level overview down to the technical details of integrating each proposal into the current system. Suddenly a nearly finished meeting dragged out for a further 30 minutes, well past the timebox, as the discussion was constantly diverted and corrected by a few people getting tied up in too much detail.
During the retrospective, a team member raised this issue. It was felt that once the team understood the issue, they should have then split off a smaller working group to assess the solutions and feedback to the team where any decisions could be evaluated, and a consensus reached about how the team should go ahead. This was felt as a fair compromise between the team knowing what was going on and development not stopping. Below is the current version of this process.
Conversation Agreement
Initial team conversation
A first conversation with the team about the issue at hand: the originator of the discussion is responsible for setting a timebox for this conversation and specifying the scope of the discussion. Write the scope of the discussion down so that all team members can see it.
Do we know enough to propose a solution?
At the end of the conversation timebox, the team decide if they are confident enough to go ahead and discuss potential solutions. If so, a smaller group of developers is given asked to look into the problem and propose solutions to the team.
Is the knowledge held within the team?
If the team feels they can’t propose a solution, then the next question is whether they know enough about the problem to continue.
Liaise with Product Owner
If more questions emerge, the developer leading the discussion, or another, if it is felt more practical, should then work with the Product Owner to answer those questions before feeding back into a new discussion.
Small group discussion to propose solutions
The small group of developers is given a timebox and timeframe within which they can explore possible solutions and develop one or more proposals.
Feedback to team
At the end of the timebox, the small group presents their proposed solutions to the team.
Does the team accept the solutions?
Based on the proposed solutions, the team has to decide if they have enough to take back to the Product Owner. If further questions emerge, or the proposal does not solve the issue, then the process starts again, restating the scope of discussion.
Propose solutions to the Product Owner
The team take the proposal to the Product Owner in as non-technical a format as possible.
The new process has already paid off; small working groups have formed and brought back proposals for a number of issues, and the team feels they are being more productive because of it. Naturally, we will review this regularly, but it looks like it is here to stay for a while.
For more on retrospectives, check out our article What are your top tips for facilitating a great sprint retrospective and why?
If you want to develop your Scrum skills, take a look at our upcoming courses
Need help with Scrum? Get in touch with us using the link below.