1 Hour to 2.5 Long Scrums Every Day - Is this Crazy?

Question

The team has

• ten developers
• one development manager
• one tech lead
• one project manager
• over eight projects going on at once
• everything is top priority

Every day there is a hour long call called scrum that goes over every single item in the sprint and provide updates. Even though there is a team, the projects discussed are not related to each other, but their own unique application, they do interact with each other but at a very very small scale. Management requires for the whole team to stay and listen.

In addition, there is another hour long call three times a week, where other projects are discussed, providing updates on each item.

How would you advise appropriate alternatives to make sure sprint items do not fall to the wayside?

Even with these long meetings, there is a real lack of transparency to the overall long-term vision of the product.

In addition, how would you advise making sure the team understands the different projects going on that they are mandated to support?

What calls would you make? What decisions would you take?

Answer 1

None of what you described is Scrum

1. Scrum doesn't have the roles you described.

2. You don't seem to have the two essential roles for Scrum - the Product Owner and the Scrum Master.

3. In Scrum everything cannot be top priority. The Product Owner creates an ordered list. The Development Team works on them in that order.

4. In Scrum there are no status meetings. The Daily Scrum is a 15-minute time-boxed event for the Development Team to coordinate their work.

It is not clear why you tagged it Scrum. Please refer to the Scrum Guide.

What calls would you make? What decisions would you take?

However, if you wish to practice Scrum, you can start by sending a few people for Scrum training. Your team is too large to be a single Scrum team. You can split it into two Scrum teams. You can designate the Scrum Master and the Product Owner for the teams. The same Scrum Master and/or Product Owner can be shared by the teams, if needed.

Keep the teams relatively stable. You can split the projects between the teams. However, you will get better productivity and team morale if each team focuses on one project per sprint. You can make an exception if there are critical production bugs on other projects that cannot wait.

It's not Scrum... how would you best improve this?

I would take two immediate steps to improve this:

1. Split the team into two and assign half the projects to each team: Regardless of other factors, communication is a problem in teams that are too big. At a minimum you will save the need for everyone to stay and listen to all project meetings.

2. Find a way to prioritize projects: If management says "everything is top priority" they are in effect saying nothing is priority. When you designate one of the projects "top priority" what you are saying is "assign resources to this project first and if any resources are left assign them to other projects". If "everything is top priority" then all projects will be starved of resources. In reality, more resources will be wasted in context switching.

Answer 2

I think the Scrum vs. non Scrum dilemma it's a second-stage problem, you should tackle the most important things first, which IMHO are:

1. Everything is top priority, which also means that nothing is, which also means that you don't have any priority (or more likely your priorities are the result of antagonist factors/interests, which makes things difficult to manage). That's the first thing you should address, if you don't have an idea on where you should invest it will be very hard to find out also how.
2. You got 8 projects for 10 people + 3 managers. I don't know how you ended up in such a configuration, but maybe you (as a company I mean) can explore other ways of managing your development system. I could be wrong here but maybe 1h * 5d * 13people = 65 hours/week invested in coordination for such a small team are a bit too much...

In order to fix these things you need to have a shared understanding of what are the problems you're facing (i.e. the manager feels like he/she needs to have a complete daily status because otherwise he/she will not have a clear idea of what's going on... if that's the case you have to work on finding a solution to this problem) and how this affect each-other's work, and people to be engaged in fixing this situation.

Answer 3

As others have pointed out, this is not Scrum in any way shape or form.

How to rectify it?

The easiest way I've found to cut down on unnecessary meetings such as these is to quantify their cost.

Take the average daily cost of the team (be conservative, it'll still work out expensive). Work out their hourly rate, multiply that by the hours per week these meetings take, multiply that by the amount of people in the meetings.

Use the resulting BIG NUMBER to take back and say that these meetings are costing $X per week, $XX per month, $XXX per year in direct cost, not to mention the cost in lost productivity of doing other things. Use that as justification for cutting down the length, frequency and attendance size of the meetings.

Quantifying the actual cost (not even including lost productivity) of regular meetings usually scares people into finding a better way.

Answer 4

1 Hour to 2.5 Long Scrums Every Day - Is this Crazy?

It's not just crazy, it's wrong. This is exactly the sort of situation that Scrum is meant to prevent. If you're having a 1-hour (not to mention a 2.5) daily meeting, you're doing it wrong.

Management requires for the whole team to stay and listen.

The first step in solving a problem is to acknowledge the problem. Talk it over with a manager -- one on one is probably best here so that you can talk freely and they don't have to respond in front of the whole team. If you point out the cost of these long meetings (between 65 and 160 man-hours per week) and the potential for improving productivity and morale, you'll probably get plenty of agreement.

What decisions would you take?

Splitting up the group into two teams and learning to do actual Scrum instead of the current Scrum-in-name-only, as others have suggested, are two good suggestions, but they're big steps that management may not be eager to make. Good Scrum training can be expensive, and it may also be hard to justify if managers have told clients or other stakeholders that you already practice Scrum.

Since the primary goal here is to spend more time working and less time in meetings, you might start by reducing the time allowed for the daily meeting. The meeting should be laser-focussed on conveying just the information that has changed since the last meeting and what everyone should expect by the next meeting. Stop going through every ticket in the sprint and instead give each developer 1 minute to give their status:

• What did they finish?
• What do they expect to finish by the next daily meeting?
• What, if anything, is preventing them from getting something done?

If there's detailed information about specific tickets that needs to be conveyed, that should be done in written comments attached to the ticket itself -- it doesn't need to be read out loud or rehashed during the daily meeting.

Another goal should be to do each sprint a little better than the last. To foster that, Scrum includes a "sprint retrospective" meeting. This is an opportunity for anyone on the team to suggest improvements to the process, but it's not a free-for-all for venting frustrations. The meeting should have an agenda that anyone on the team can contribute to -- a wiki page works well for this -- and the person running the meeting (not a manager) should stick to the agenda and keep things moving. After an explanation of each proposed change, let the team vote on whether to try it or not, and make a note for the next retrospective meeting to discuss whether the change helped and should be continued.

In all cases, extended discussion or argument should be tabled and addressed outside the meeting, with results reported back to the team via e-mail, chat, or however the team routinely communicates.

Answer 5

What you are describing is a long way away from being Scrum. However, the Scrum framework does offer you some guidance that could help.

In Scrum we limit team sizes to a maximum of 9. This is done because there is a lot of research that shows communication in a team larger than 9 becomes too much of an overhead.

Scrum also limits the daily Scrum stand-ups to a maximum of 15 minutes. The reason the team stands up for the meeting is that it encourages focused and effective conversation. It is worth noting that the daily Scrum is about synchronization within the team and is not about reporting progress. When you think about it having the whole team together in a meeting costs a lot of lost working time. So it is important that the daily Scrum is efficient and covers topics that effect the whole team. When a topic is raised that does not concern everyone it should be taken outside of the daily Scrum and discussed by only those that it effects.

Scrum also emphasises the importance of prioritisation. Research has shown that the more tasks being done by an individual in parallel, the less efficient they are. Good prioritisation will allow team members to work in a focused and efficient way.

How would you advise appropriate alternatives to make sure sprint items do not fall to the wayside?

This is where the Product Owner role comes in. The development team works on the top priority tasks and only needs to focus on these items. While they are doing this the Product Owner looks at the big picture and works with the team to continually refine the backlog of work.

Answer 6

You made one mistake in organizing with the team.

In my opinion, you need this stuff:

• have to break down the requirements, create task, estimate and distribute them. In other words, this means that you have to create the Sprint Backlog.( with the product owner and investor)

• have to perform the short Daily Sprint Meeting.

• have to ensure that at the end of the Sprint potentially shippable functionality is delivered.

• have to update the status and the remaining efforts for their tasks to allow the creation of a Sprint Burndown Diagram (A Sprint Burndown Diagram is very important)

Answer 7

It sounds like you are describing meetings and not scrum.

Scrum should be at the start of the day, full team present and standing.

Under 10 minutes with a recap of things completed/updates, and a commit for the current days tasks; done by each person on the team.

I think maybe planning meetings and story review meetings are your 1 hour meetings.

Answer 8

I've used the following document "Fourteen Observations of Good Scrum Practice" with success hope you will do also: http://lookforwardconsulting.com/wp-content/uploads/2011/01/ScrumObservations.pdf

In summary A scrum team typically consists of around seven people who work together in short time boxed activity called sprints, with plenty of time for review and reflection built in. The mantras of scrum is “inspect and adapt,” and scrum teams are characterized by an intense focus on continuous improvement—of their process, but also of the product. The main roles in scrum are Product Owner: Own and drive the product and maximize the return on investment, The Scrum master: act as a coach and guide the team to a higher of efficiency, self-organization. The development Team :a highly collaborative and self-organized team doing the actual work.

Observation-1: Sprint is owned by the development team and SM should make sure to protect the team during the sprint from management interference that can negatively impact the sprint.

Observation-2: a common definition of done which is a result of negotiation between all the actors in Scrum team members, but the development has the final say.

Observation-3:The product backlog is owned and ranked by the Product Owner. Other team member can suggest features to add but is the PO who has the final say.

Oberservation-4:The Team is responsible for their own commitments and should only make commitments they truly feel they are going to fulfill.

Observation-5:The PO can set the priorities for the Team.

Observation-6: The Scrum Master has no authority over the activity of the team.The SM is the one who has the expert knowledge on the scrum framework.

Observation-7:Sprint planning is about what PBI the team will build and how they team is going to build it.

Observation-8:Sprint backlog, owned and maintained by the development team.

Observation-9: The daily scrum meeting is a timeboxed meeting to a max 15 minutes where the development team take the opportunity to sync their activities and answer the three question: What did you do ysetrday, what will you do today and any road blocks that other team members can resolve. The SM will facilitate the meeting.

Observation-10: the sprint review, it is the time for team to shine and present the sprint increment to the PO. Only demoble increment maybe demonstrated.

Observation-11: The retrospective is the time for the team to reflect on how they can improve.

Observation-12: stakeholders have no direct authority on the team and the SM should shield the team if the interaction with stakeholders is deemed a distraction

Observation-13: if the PO decide to terminate a sprint, they should organize a termination meeting with team to tell the team what is behind the cancellation and the team should come up with key leanings items to be communicated to the stakeholders

Please check the pdf file for more insights.