Multiple Projects in a Sprint
Hi, I'll be interested to hear what others think is the best solution to my particular conundrum....
So, I've just joined a company as a Scrum Master where they have quite a few Agile anti-patterns. One of these is multi-projects in a Sprint. A Sprint typically has at least 3 projects on the go, which results in the dev side of Team members all concentrating on their own particular line of interest. This of course then creates a scenario of every Scrum ceremony being of complete disinterest during large portions of time to other Team members, simply because 'their' work isn't the item under discussion, and to my mind, rather than having a Team of people, we have a group of uncoupled individuals.
I have asked whether pair-programming is an option, but this was met with not much enthusiasm from the Team, with the reply that the Projects were simply too small to keep all the Team engaged. The Business will continue to submit multiple projects for the foreseeable future.
I guess my question is:
Given that I'm told by the devs that any one project cannot be easily worked on by more than one dev, (and not being interested in pair-programming), how do I ensure that there is a flow of knowledge in the Team, but also keep all Team members engaged? In an ideal world, the Team would swarm onto the Project, get it done and then move onto the next, but there will always be multiple 'small' projects per Sprint.
Thanks for any insight you can give !
In your question, “project” is mentioned seven times and “product” not once. How many products are the Development Team and the Product Owner focusing on each Sprint?
.find_in_page{background-color:#ffff00 !important;padding:0px;margin:0px;overflow:visible !important;}.findysel{background-color:#ff9632 !important;padding:0px;margin:0px;overflow:visible !important;}
Who decides what the team works on? Is there one Product Owner, and is that person really empowered to make decisions about what needs to be done (and when)?
If so, then one opportunity may be to help that Product Owner understand the benefits of focusing on one thing at a time, and finishing it sooner, rather than having multiple unfinished things that are not yet delivering value.
Another thing i might add..the Scrum guide describes Scrum as a framework to deal with complex adaptive problems. If your projects are not complex and adaptive, then perhaps Scrum is not the most fitting framework to use. Also, since one of the responsibilities of the Scrum Master is coaching the team in cross-functionality and self-organizing, it might be an opportunity to coach them on proper pair-programming. I personally have found that some teams just dont know how to do it effectively and that's why they don't see it working for them.
@Ian - You're quite right, I did use 'Project' rather than 'Product'. Unfortunately, in this case you really can use the two interchangeably.
@Simon - Ha! Another problem is the Product Owner is not sure of his responsibilities/ accountability, and the Business have only just started to address that. I do hope to try and convince them that working on one thing at a time is indeed more beneficial than trying to do many things at once.
@Fatuma - A couple of them are quite complex, but some are not. You are quite right, I do need to try and teach the Team the benefits of pair-programming, but it's still tricky trying to convince them. And yes, I am wondering if Scrum is even right for this Team, it could be that something like Kanban would be more effective.
Another problem is the Product Owner is not sure of his responsibilities/ accountability, and the Business have only just started to address that.
From the Scrum Guide:
"The Product Owner is responsible for maximizing the value of the product... For the Product Owner to succeed, the entire organization must respect his or her decisions... No one can force the Development Team to work from a different set of requirements."