How to apply daily stand-up meetings with a large team on multiple projects

Question

Background

There are:

• 4 .Net Developers
• 4 PHP Developers
• 2 QA Specialists
• 2 Integration Specialists
• 2 Analysts
• 3 PMs
• 11 Projects in active development. None are trivial. Some are programs with sub-projects.

I am the 4th PM tasked with adding method to the madness. I am trying to take the org Agile. My short term goal is to implement daily stand ups and Sprint planning (probably end up being more Kanban than Scrum). The environment is multiple eCommerce and SaaS sites, so at any given time something can break and send all plans to the wind.

The Challenge:

We can't have 11 stand ups a day, nor can we perform work on 11 projects a day.

• Option 1: Each PM has one stand up for the projects they want to focus on; however, some team members will be on all three and therefore need to attend 45 min worth of stand-ups every day.

• Option 2: We have one massive stand up with 17 people. This would have the most transparency as to what project/task each person is/has been working on. However; how long would such a meeting need to be? How long would people end up listening to issues that do not apply to them?

• Option 3: I don't know, you tell me.

Answer 1

option 1: it might work if you make these standups extremely quick and efficient (15 min is the maximum, standup could be much shorter)

option 2: sounds like a disaster to me; having so many people and projects, it would be impossible to process it all in a meaningful way and still keep it under 15 minutes; you might end up with long boring "standups" (I've seen those)

I would vote for option 3: try to split your people into several teams and minimize the number of projects per team (context switching takes lots of brainpower). Ideal SCRUM team has 5-8 people (afaik).

if you can put some of your projects on hold - do it.

The environment is multiple eCommerce and SaaS sites, so at any given time something can break and send all plans to the wind.

in this case you can ask one of the teams to take care of the problem (or just assign one of the teams to be a "product support" team - for one sprint or forever).

Answer 2

The Problems

Reading between the lines a bit, it would seem that you have a few related issues.

1. Your "team" is too large to be truly agile. You may want to consider splitting up into cross-functional tiger teams with a focus rather than a multi-project, matrixed organization.

2. The purpose of your stand-up hasn't really been defined. Truly agile stand-ups are task-coordination meetings, not PM status pulls.

3. You have four project managers, all of whom presumably want to hijack the stand-ups for status on whatever they are on the hook for that day.

Some Potential Solutions

There aren't any easy answers here, but it's clear that you need to re-engineer the process. Some suggestions include:

1. Split into project teams of no more than 6-9 team members. If people need to be matrixed, just adjust your expectations (and estimates) downwards to account for the reality of task-switching overhead.

2. Divvy up the projects between the PMs. Four project managers focused on the same projects is just too many cooks in the kitchen.

3. Never, ever use the stand-ups as a status pull. Hound people for status elsewhen. Use a single stand-up each day to allow the team members to coordinate their tasks for that one day with one another.

4. Limit commitments made during the stand-up to tasks that can be delivered the current day. Bob needs something from Joe by the end of the day; can Joe deliver, or does he have a dependency the team needs to know about?

5. Have a separate stand-up each day just for the project managers. Whether it's a Scrum-of-Scrums or just a "my Excel spreadsheet is bigger than yours" contest doesn't matter; this is the meeting where inter-project dependencies and tracking issues should be worked out, not during the development team stand-up.

Organizational Costs

The bottom line is that your current process is unwieldy. That doesn't make it wrong, but it certainly makes it expensive in terms of process overhead. To whatever extent you can, you should work hard to:

1. Reduce the organizational costs of process overhead.
2. Make overhead an explicit cost to the organization and each project.

For example, if your team really needs to spend 5+ hours a week on status updates and meetings, that's a minimum of 75 man-hours a week that needs to be accounted for in your project plan and its budget. Once those costs are made clearly visible to the organization, senior management can make informed decisions about whether the benefits of the current process outweigh the costs.

Answer 3

The easy solution is to have only one standup which is for the team. My recommendation is to talk about only the upcoming work and focus on those issues which my cause some troubles later on such as cross-project tasks, integration tasks, tasks which are on the board for a long time.

With this approach the three personal oriented questions need to be transformed to a task oriented question, but for large projects this kind of setup is way more effective. As I mentioned before you have to talk about issues, and the recommended order is right to left on the board, because there are those tasks which are close to finish. If the 15 minutes passed you stop the meeting and see what can be done differently the next time so that it fits into the timeframe. One additional trick is to talk about those issues which have a stop sign, because those are the one which need to be discussed with the whole team (how to unstop them).

Answer 4

You say that you want to take the organization Agile. Be careful, as this can be a significant change and can lead to resistance and inefficiencies at least in the short term. You will really need to plan this out and have buy-in from your senior management team to support you on this undertaking before you try to implement it so that you can proactively address issues like the one that you raise. Otherwise you are setting yourself and your organization up for failure.

Maybe a best first step is to use agile as a framework rather than follow it to the letter. There is no sense in implementing a system to improve efficiencies with a level of bureaucracy that negates any gains you can make. Do you really need stand-ups for all projects every day? Or can you get away with stand-ups every second day? Can you limit agile work to fewer projects so that the team can get a feel for it?

Answer 5

With 18 people working on 11 projects, you must have a lot of multi-tasking going on. This will drag down all the projects.

As others have noted you may want to create some cross-functional teams. Given that you have four PMs you may want to look at creating four teams. That will leave you short some resources and you will have to share the scarcer resources. These will be pretty small teams. The PMs should meet frequently to deal with issues like project prioritization, work distribution, and resourcing.

With four teams you should be able to have each team do a quick stand-up with shared resources attending a couple stand-ups. You may want to add an additional stand-up for the project managers.

Try taking one team and dedicating it to a shorter project. If they aren't pulled between projects they should be more effective. With four teams you will be able to experiment with process. If this works out you may be in position to argue for more dedicated teams.

It has been my experience that matrix organizations tend to have problems keeping staff in touch with their functional groups. Allow some time for the functional groups to meet and handle their issues and develop their skills.

Answer 6

You say " My short term goal is to implement daily stand ups"-this is not a difficult goal. Whether this is useful is not important, so have daily stand ups. Your goal should be to get the projects done as soon as possible, and your job is to find the process that satisfies that. Maybe that is daily stand ups and maybe not.

Answer 7

I am in a situation similar to yours:

• Big team 12+ members (backend + ios + android developers, testers)
• 6 projects. Some projects need collaboration with team from other companies.
• I am the only PM of the team

In real-life software development, managing a team with fixed number of people working in only 1 project is desirable, but we are not usually in this situation. For example, when one project is put on hold due to dependency with other teams (which sometimes we could not control), we need to temporarily move members to other projects. Some other times we need to have backup (in case the only ios/android developer leaves), so one person working on one project may also learn and work on other projects as well.

In this case it is really difficult to apply every words of Agile. Instead, we have standup meeting for each project every two days i.e. Today we have meeting for project 1, 2, 3; tomorrow we have meeting for project 4,5,6; and then the day after tomorrow, project 1, 2, 3 again.

In today’s meeting, I won’t request everybody from project 1, 2, 3 to attend meeting from the start to the end. At first, I ask A, B and C who work on project 1 – we have standup meeting for project 1. After that, I invite D who works on project 2 to meeting and release A since he is not working on project 2. Now B, C and D will have meeting for project 2, and so on..

This is not Agile, but so far we are happy with current approach. Developers don’t need to spend too much time listening to unrelated information, and we got quite sufficient information to work for 2 days between meetings. If any questions arise, we are willing to discuss on-person, or call for meeting, during the workday.

After all, standup meeting is just a tool; it may not answer all questions – you need to answer as much as possible in most efficient way, and use other tools – communication during workday - to support it.