16

TL;DR What is the best part of the day to have the Daily Scrum meetings, in the morning or afternoon? There cannot be a single, canonical answer to this question that will be true for all teams and all projects. However, there are certainly some common practices—but keep in mind that "common" doesn't necessarily mean "best." To clarify the trade-...


16

None of what you described is Scrum Scrum doesn't have the roles you described. You don't seem to have the two essential roles for Scrum - the Product Owner and the Scrum Master. In Scrum everything cannot be top priority. The Product Owner creates an ordered list. The Development Team works on them in that order. In Scrum there are no status meetings. The ...


14

Why would you need to? The daily stand-up meeting should only take five to fifteen minutes, depending on the size of the Scrum Team. If it is taking longer than that, then that's a separate issue you should probably be looking into. If it does only take five minutes, then are your developers really so hard-up for time in the day that the presence of a ...


11

The stand-up in Scrum has a distinct purpose. As do the other meetings defined by Scrum. There is no overlap between their purposes, so having another meeting is not a good reason to cancel the stand-up. What could be a good idea though is to have both meeting directly following each other. In other words: shift the time of the stand-up to immediately ...


9

I think the most useful advice can actually be found in the comment on your linked Question. My manager was absolutely shocked to find out that we still had our stand up when he canceled it (a regular occurrence). My response to him was "The stand up isn't for you. It's for us. Whether you're here or not, we still need to sync up as a team. The Daily ...


8

Quick answer: It depends. It depends on: Frequency: If you're having a daily meeting, sending the minutes one day later make it useless. Action Points: If you're dealing with several people that will follow the actions discussed during the meeting, better sending the minutes before having the other people doing anything. Otherwise, if the attendees carry ...


8

The simplest answer is to ask the team. Go with what they feel most comfortable with. If it doesn't work out, adapt and shift the meetings around. I have worked with some teams that prefer to have all the meetings in one day. They see that as a 'hands-off' day and like to get it out of the way rather than having meetings spread out. Other teams don't like ...


8

The physical Kanban board offers the face-to-face meeting approach. It necessitates all team members to come together. Moreover the feeling for "What I'm now responsible for" increases. We introduced a physical Kanban board at our customer once before we shifted to a digital one. The method is initially better taught in a physically way Get a Whiteboard and ...


7

I am drawing assumptions on your PO's agenda, based on my experience of other PO meetings, and discussing a stakeholder's objections on spend would not be consistent with that agenda. The PO, or you, or another leader of the team, should acknowledge the issue, validate the issue, and then table it with a promise of an immediate meeting to discuss further. ...


7

TL;DR I was thinking at the back of my mind to either: defend the PO and budget defend the team, since they were kept busy delivering items from the backlog Bring focus to the meeting by telling POs to keep focus on delivering high value items in the following sprints The correct answer is "none of the above." Your goal as Scrum Master isn'...


7

The "true Agile" you probably have in mind doesn't exist. Some teams are more Agile than others, some are less. For a bunch of other teams Agile is just a buzzword which doesn't reflect in their practices. Some even refuse to use the word Agile and prefer to say "move with agility", to detach themselves from the buzzword. Agile is a set ...


6

You are really looking at issues associated with multi-tasking. There are a number of questions on PMSE addressing this issue that you could look at. If you want something a bit more dry you could try this paper, but I would suggest that your friend: Document the lost time. This would be the amount of time it takes to prepare for and then physically get to ...


6

You do need to make him aware of the impact of his pontification, and it sounds like he has some awareness now. However, it will not cure the issue. It is a well constructed behavior pattern he has developed over his life time and is likely consistent with his personality make-up and a ton of social engineering, i.e., he has been rewarded in his past for ...


6

In general, all interruptions to the mental "flow" of highly concentrated knowledge workers are counter productive and so the timing, duration and structure of the daily need careful consideration. Having tried a few variants I prefer to hold the daily 30 mins after everyone is in the office. The reasons are: There's enough time for the majority of the ...


6

TL;DR The Scrum Master for my team cancels the daily stand up if we have another meeting that day...Is canceling the stand-up like this a good idea? Like many things, the answer is "maybe." Generically, the answer should be no; the daily standups should be held regardless of whatever else you may have on the calendar that day. However, there are ...


5

TL;DR Your part-time people need to be present for Sprint Planning. Specifically: Do NOT: act as a team member's proxy during essential framework meetings. attempt to circumvent framework-mandated meetings such as Sprint Planning or the Daily Stand-Up to accommodate resource constraints. Instead, you should: accept that part-timers create additional ...


5

I tried to find different ways to keep the daily scrum interesting. Here is what I found and at the same time think that it would be worth trying. Always consider, to not bring somebody in a uncomfortable situation: Rather neutral: I have been using smart phone app-timers in the daily scrum. Passing them from one to the other. I think playing sounds when ...


5

Question is -> should this all happen in one day (of course given the fact that it may be shorter - planning 1 hour, review 1 hour, retro 1,5 hour)? The typical cadence of a the Scrum ceremony is to host Sprint Planning and then at the mid-point of the timebox run a Backlog Refinement ceremony. The Sprint Review occurs at the end of the timebox as that ...


5

The most important goal of the daily scrum is not to identify problems, but to create a plan for the next 24 hours (until the next daily scrum). It doesn't matter when exactly you do the daily scrum though. I prefer it in the early morning if all team members tend to arrive around the same time. If team members come in at different times I generally ...


5

First of all, with 8-9 developers, each having 1-3 impediments, it seems like the team is not really working together towards the same goal, but working very efficiently towards several goals. (and thereby losing real productivity). Second, the Daily scrum is the last responsible moment to raise an impediment, but nothing prevents the team from quickly ...


5

No team I ever met was self-motivated to fill out bureaucracy tickets. The question you should ask is: who wants them to count hours and why. Then find out how to solve that need. Ideally, you have a capacity for each team member and that capacity goes down when you have meetings. A person there for 8 hours per day might only have 6 hours of capacity. ...


4

Developers are most productive when they focus on one thing at a time... ...without interruptions and task switching. Meetings are only one form of interruption. If you have a ScrumMaster, consult with him/her and let them handle this. If not, there is a thread on Programmers SE that has good discussion on this topic. You should be able to extract what ...


4

I think there's another point to this question that isn't covered yet and that is: What should actually be covered in a sprint planning? (or why does it have to take a lot of time at all?) Short answer: In a sprint planning you should only be planning the sprint. What that means: Looking at your tasks and stories Quick estimation (if you do estimates; e.g. ...


4

Include all team members in sprint planning The basic tenet of Agile/Scrum is that there should be direct communication between the Product Owner and the team doing the work. Also, the members who will be doing the work should make a team commitment to completing what they signed up for. So, you should try to include your part time person in your sprint ...


4

Just Say "No" to Scrum Anti-Patterns The daily stand-up is for team coordination. Gamification and intra-team competition are antithetical to the goals of the stand-up, and introducing "fluff" into a meeting that should be time-boxed to 15 minutes or less is counter-productive. Keep the meetings short and focused, and end them early when the meeting's ...


4

I would avoid gamification. It's the kind of thing that some folks enjoy but others find extremely annoying and alienating. Even if your current team members all enjoy it (and I would never be 100% confident that nobody is faking enjoyment to fit in to what was expected), team membership changes. Humor and fun, on the other hand, can be a positive thing. ...


4

Generally speaking, a morning meeting is better, because it doesn't cut the working day into two halves (people mostly complain about meetings because it cuts their work into pieces and they find it hard to start again) during the meeting we usually talk about what is going to happen after the meeting and when it is in the afternoon it looses it points. ...


4

I've not seen this in action. What I do know is this sounds like a team evolution. When a team is still in the forming, storming or even norming phase, comfort is still being established. At this point you are working on team cohesion and team trust. Having spent a lot of time in theatre I can tell you it takes a lot of trust for a good acting troupe to ...


4

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: 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 ...


4

What you are describing may well be healthy Scrum behaviour. Scrum relies on communication between the development team members as this promotes synchronisation and improves team effectiveness. It is important to remember that healthy conversation is often a productive use of time for team members. As a Scrum Master if I saw several conversations ...


Only top voted, non community-wiki answers of a minimum length are eligible