Two clients, one team, should we still have the standups together?

Question

We are team of a 7 developers, 2 interns, one user experience specialist and a Quality Assurance member. The team is usually dealing with new clients. Not all members are involved in the same project; usually there are two parallel clients with 3 or 4 Full-time equivalents assigned. Few members are involved in both projects at the same time and one or two are taking care of the interns.

For each project we have separated backlogs and ceremonies scheduled at different times. We try not to overlap these meetings so that the common members can attend both. This is going well.

However, the entire team is doing the daily meeting (DM) together.

So we start with Project A, the members involved with the Project A present their progress, impediments and what they intend to do for the rest of the day and once this is finished we get to Project B. Then the interns will present their progress to us.

There are several problems with this. The members involved solely in one project have no context about the other project, because they don't participate in the other meetings, nor in the development. They recognize some terms, ideas and verbs, but still couldn't really comprehend what the other members are talking about. Visible signs of boredom start to appear, like checking the phone, impatiently stepping from one heel to another, sudden eye-rolls or not very polite smiles. This puts pressure on the other team to hurry up their DM and thus they are not really focusing on the actual impediments or on the synchronization between the devs that are working on a certain story/task.

The DMs don't take more than 10-14 minutes for both projects together.

On top of that, Project A has a different meeting with the Product Owner (PO) half an hour after this meeting on certain days of the week (M, W, F). This meeting is nothing more than a status update to the PO, but it doesn't really help the project. We agreed today that at least in these days not to have both and to have only the one with the PO and discuss here the usual DM. The PO gets more context thus.

The arguments for keeping the DM with the entire team are twofold. First, the fact that, well, we are a team and this is the only moment when we are all together so we use it to bind the team. The other is so that everyone knows what's happening, on what each person is working, what the other project is about or what support items appear from older projects (not too often though).

I have only 1.5 years experience with Scrum and am not sure how we should proceed with this. I just feel like having a DM per project is better, but I get a strong 'NO' against it from key members, some believing that I want to try to split the team.

How should we deal with this?

Answer 1

This is breaking one of the fundamental rules of Scrum, which would be "one team, one goal, one responsibility". It's incredibly difficult for a team to work on two things at the same time, I've seen it attempted on multiple occasions, but I've never seen it work out.

(In fact, the last time I saw I tried was earlier this year, with my team, and the end result was the team fractured and we had to make new teams.)

My honest suggestion would be: split up into two teams. You've got enough people to run two smaller teams, and any time spent on a meeting for a project that you don't actually work on is basically a colossal waste of time. You've already noticed this for all the other ceremonies, but it applies to the daily as well. Your team is on the "too large" side of a scrum team anyway, so it shouldn't hurt much to split up anyway.

Besides, as long as you're one team that also means that, according to Scrum, your whole team is responsible for both projects, which means that if either of them is lagging, the whole team should work on the most important one. I'm guessing you're not doing that either, which means that effectively you've already got two teams.

But if you want to keep it as one big team, split out the daily scrum anyway. If people get bored during the daily, something is going wrong, and in this case it's simply that an update for a project that is not yours is not useful. Let people work. In general, in any meeting, if you feel your presence isn't contributing anything, leave that meeting. That goes for the daily as well.

In my previous team, the last ditch effort to keep the team together despite working on two different projects was to hold a short happiness meeting before lunch, where both project groups got together to share how they were feeling and celebrate any successes together. That at least kept some team spirit, but ultimately, breaking up the team and forming new teams for each project was by far the best choice.

Answer 2

Two things need to happen:

• You have to let go of the daily meeting with both teams. In my experience it doesn’t generates much value for all the points you and Erik mentioned. You should instead adapt your ceremonies depending on the following point

• One of this suggestions depending on your situation:

  • Separate in two teams and have independent ceremonies for each one. Although I think it’s important for team building to keep some perhaps monthly catch-ups to know what is everyone up to
  • If you really need to have some members in both projects, then I think you need to do laser-focused meetings each week minutes to keep everyone up to date on both projects. Perhaps do backlog review each week with the two teams together. The reasons are:
    • Some members might need to do trade-offs between tasks and it’s important for everyone to understand why
    • Deciding on deadlines and tasks to take might require both teams to agree on them
    • It helps the team to continue being “a team” and that’s very important if you have to move members between projects

Answer 3

TLDR: ask the Team.

From the Scrum Guide:

Scrum Teams are self-organizing [...] Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.

Scrum Teams are self-organizing. If your Scrum Team's process is being held hostage by external stakeholders, then you're not really doing Scrum, nor realizing all of the benefits Scrum has to offer.

Your first step is to ask the Team. You could do this by combining their Sprint Retrospective meeting into one (more on that below) and asking there, or just in an impromptu meeting.

Your Question gives the impression that the Team doesn't want to combine the Daily Scrum, but have you actually asked them? Your Question doesn't specify whom gave the 'reasons to not split', but implies it was not the Team. So get their opinion first.

After that, your task is to convince the stakeholders that you should start having the Team be self-organizing. If you can convince them, great. If not, make sure they're aware that what they are doing is not Scrum, and carries costs (such as lowered developer morale, lowered productivity, lack of innovation, etc.) After that, just make sure these costs are as visible as possible to the stakeholders. It's their responsibility to make decisions. It's your responsibility to make sure they feel the pain from bad decisions, so that they can realize bad decisions were made and act accordingly.

---

If you want my subjective opinion (which is not as relevant as the opinions of your Team, but may be good as a starting/talking point to get them discussing the issue), then you should split the Daily Scrums but combine the Sprint Retrospective and (with optional attendance to the other Team's half) the Sprint Review.

The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.

Many improvements are process-related, rather than project-related, and as such would benefit both Teams. Personally, I consider this worth the overhead of listening to unrelated project-related improvements.

The Sprint Review is a little trickier. I suggest it be combined because of:

During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint.

However, that is complicated by:

Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value.

The reason I think the former could be useful is because I think performing the Demo as a full Team can help bind the Team together well. The Project B Team would be treated as external stakeholders of Project A (and vice versa). They would be able to view the state of the product (from a business point of view, not a technical one). They also get to join in the celebration of the Sprint completion (assuming your Sprint Review generally has a celebratory vibe, which in my subjective opinion it should).

The reason I'm leery about this is because the second part of the Sprint Review, the planning portion, is not really relevant to both Teams. You could, perhaps, suggest Team members wander off during the other Team's planning portion of the Review.

As always, ask the Team.