Retrospective for a team with multiple projects

Our main issue is that a single team might end up working on few different projects during a single sprint.

Well then, I suggest that's precisely the issue the team ought to challenge in their Sprint Retrospective. It isn't a matter of finding some sort of template to use, which would only cover up the real problem:

• Why are they working on multiple projects despite the resulting difficulties?
• Are they pulling all this work by choice, or is it being pushed onto them?

Thank you Ian, for the reply!

Multiple projects was the easy example. An alternative would be a huge project, where different team members have little overlap in their tasks. Let's imagine a company-wide system change and the team needs to migrate different tools to the new system. Get 2-3 team members focusing on different tools and you have the same result.

Not sure how the way work is pulled/pushed matters. If it really does, I'm open for suggestions, the goal is to have working retrospectives, not arguing the current approach is the best :) Currently tasks are prioritized by business representatives and the team is pulling the highest priority tasks based on capacity each sprint. 

If work.is pulled, the team can apply focus, with Done finished increments of work being delivered early and often. Through this system empirical process control is thereby established.

The whole point of Scrum is to provide such empiricism under conditions of high uncertainty. The most important project is therefore the Sprint itself.

Is there a need to establish empirical process control in the "huge project" you describe? Is it complex, meaning is more unknown about it than is known?

From what you say, it sounds like there are well-defined pieces of work proritized by a business authority. If that's the case  why even use Scrum? What significant risk or uncertainty is there to be mitigated by a team each Sprint? Do they have meaningful Sprint Goals to collaborate around and aim for? That could be the more important issue to address in a Sprint Retrospective.

Are you sure you are following the Scrum Guide or are you just using some of the terminology that is used?  For example, are your Sprints planned with a Sprint Goal in mind and focus on delivering incremental product value to the stakeholders?  Is your Product Backlog actually a list of all the things needed to be done to the Product in order to improve it? Is your Product Owner the individual respected by the organization to make decisions on what is right for the Product? 

Most of the suggestions you would get here are going to be Scrum leaning.  In this case, I don't think you are following the Scrum Guide and the sprint you mention is more of a fixed duration at the end of which you give a status report.  I may be wrong and if so, please accept my apology.  But regardless, what I'm about to suggest still applies.  Look at the processes you have, find ways to help the team understand the problems and opportunities associated to those processes.  A retrospective is for looking back.  What worked, what didn't? What did we learn from what we just did?  How can we apply those learnings?  Often using a "technique" can make it harder to have a successful retrospection event.  Facilitate discussions by asking leading questions.  Ask the team what they feel not just what you observe. The people doing the work should be the ones that drive the discussions so let them.  If they do not feel that there are problems, then who are you to say that there are.  But remind them that if no one speaks up, nothing can ever improve. 

These are some great replies.

We are definitely NOT using the Scrum Guide, but similarities are a lot - making me seek help here. Ian is probably right that one of our problems is that the sprint goal is either too high-level for the a team to associate with, or too specific. Making it hard for everyone to collaborate to the same goal.

At the same time, we are mitigating the risk of poor/incomplete system migration by delivering each tool in increments. This allows the business to evaluate both the system migration quality and tools capabilities in the new environment. Yes the backlog is a list of things to be delivered, but after every increment this list gets updated based on feedback.

Tackling the problems and opportunities associated to those processes might be a good starting point. I can imagine this can open the discussion on how to pull and reflect on our lessons learned, having a productive retrospective (instead of me trying to force a technique).

Daniel, you touched another pain-point that I have, but this requires a separate discussion. How to coach the team towards Scrum, or anything in that matter, if they believe that what they currently use is the best possible option. Using approach A and claiming its the best, just because you are not aware that there are options B, C, D...is something I've been struggling for some time.

How to coach the team towards Scrum, or anything in that matter, if they believe that what they currently use is the best possible option.

I often coach my teams that everything we do is an experiment. Do we know for sure that the code we are going to write will be what the stakeholder really wants?  Not really, but we are willing to experiment with it and get their feedback. 

Same holds true with the way people work.  Sometimes you don't know that something can be done better until you take a critical look and agree to experiment with options.  Sometimes the experiment produces bad results but as long as you learn from the results, the experiment is a success.  Challenge them to experiment. 

How to coach the team towards Scrum, or anything in that matter, if they believe that what they currently use is the best possible option. 

What data or evidence is the team using to support their belief that they are working in the best possible way?   Are they measuring things like lead time, cycle time, customer satisfaction, meeting sprint commitment and Sprint Goal, defects/issues identified within and post-sprint?



If not, then perhaps that is where the team needs to begin; otherwise, they may just be working from opinion only, and a possibly misinformed one at that.

Thank you again to everyone who replied. There are several good ideas I need to experiment with, before requesting additional assistance, or claiming success :)