42

I had experience participating in a "SCRUM" team with several employers. It appears to me that the managers take out the "daily scrum meeting" as the main point of SCRUM, and set it as the goal, instead of having it for what it is: a mean to achieve more effective development cycle. Very quickly the 15 minutes meetings became 45 minutes meetings, the ...


37

As an alternative to daily scrum, we're thinking about asking developers to provide daily reports with the following conditions: What a terrible idea. Do you think that this can decrease their productivity? Yes. Why? A verbal presentation at a meeting combines writing and n people "reading" the report into one concurrent activity. Talking plus ...


35

I would find daily stand up boring and useless if I felt there was little to no value in it. There are a few things that can reduce the utility of a daily standup. The information being shared never pertains or affects me in any way. Absence of team ownership and everyone always working on their own projects. Absence of team communication outside the ...


33

Why are the backlog items not inserted and prioritized before sprint kickoff? Wasting developers time is not fun. Let your team leads work with the product owner and project manager a few days beforehand to prioritize stuff. This goes for planning who is on each sprint team too. Why is it taking a day to break things out into tasks? If you have a reasonably ...


30

Make estimating easier Break your sprint planning down. Do you need to estimate the individual tasks? I've done sprint planning two ways: Stories are estimated in story points and then tasks are estimated in hours Stories are estimated in story points and tasks simply fall under that with no estimate Of the two, I prefer the second option. I find that ...


27

This is a fairly common practice, although I wouldn't say supportability is the main benefit. The real benefit for this approach is keeping an audit trail. It's also common place to have an extra column containing the username of the user who made the last update. If you're dealing with any kind of financial or sensetive data, I'm sure you've heard of ...


21

Ideally, the scrum master is responsible for facilitating the project activities and to address any sort of impediments faced during that. He/she does not participate in the "yesterday, today, impediments" spiel during the daily stand-up per se, however, is answerable to the team members for any kind of status on the impediments they have reported during ...


19

Some of the problems encountered with daily SCRUM meetings : those which last too long. You don't want any manager guy in those daily because they're the root cause of this kind of problems. See how they'll usually be the ones using a chair (yes, having to stand up for those is to entice people to be fast) having to hear about someone (or 2 or 3 devs) ...


18

a) I will find out what the answer to this is from the person responsible for that area of the project and get back to you within the next two days b) This is a good point, thank you for raising it. I have not thought about this aspect but will do and get back to you within the next two days c) What do you actually mean about this as it does not seem to ...


17

The Scrum team is self organised so there is room for somebody who is a little more dominant. Others should ask him for his ideas about tasks they are working on, but his dominance must be kept under control. What you can do: Motivate others to be independent but collaborative - this can be best achieved if you co-operate with their manager and HR who ...


16

The former argument is invalid, because adding a few database maintained timestamp fields to a series of tables is not difficult work. This is in fact the kind of mind numbing task that one would give to a junior or an intern, and they could easily do it in a single two week sprint with time to spare. It may or may not even be necessary to map these fields ...


14

Timing is the killer for many. Programmers like to code late, sleep late and come in after the morning rush. Having to be in office at a fixed time - way too early for them. And too late for others who may come in earlier and start working already. Flow is another issue. A programmer in flow with some feature will work until late at night, go home and come ...


14

Presumably, the reason for this question is because you feel that the team is somehow under-performing because of this dominant person. Perhaps because the rest of the team aren't contributing 100% because, well, what's the point? As a manager, if you are, it's your responsibility to make sure that all of your employees understand what their roles are. ...


14

"As long as they need to be, and no longer." The thing to realize here is that meeting time to saved development time is in no way linear. For your team, for your company, for this topic, then 1 hour of meetings might save 2 hours of dev work. If you have 10 hours of meetings, another hour of meetings might save 0 dev work. Hell, it may save you -2 hours of ...


12

For Scrum, Ken Schwaber and Jeff Sutherland explain: Daily Scrum The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours. This is done by inspecting the work since the last Daily Scrum and forecasting the work that could be done before the next one. The Daily ...


11

By the time we do our team meetings, we already know what we've been doing all week and what we'll be doing next week. And we have a reasonable overview of the long-term plan. What we do in our team meetings is talk about what is bugging us. Anything that happened in the last week which slowed us down significantly, things that we'd like to change in the ...


11

My observation is far too often these meetings are for the managers to look and feel like they're actually doing something rather than them being useful for the team and the project. For example, a team is assigned to do series of short bug fixes on different projects. They're really not working as a team but as individuals. However, because company/...


11

I've done these in the past, but in the morning as opposed to the end of day. It generally took less than five minutes to fill out, so no, I can't see how there would be any decrease in a developer's productivity. The nice thing about doing it in the morning was that it made you think about what you're going to do for the rest of the day. Having said that......


10

Make sure that no-one monopolises the meeting. If 4 of the developers get their spiel out of the way in 5 minutes, and the next 10 minutes are spent listening to the team leader detailing all of the amazing, awesome new developments he's made, most of which are neither as amazing nor as awesome as he thinks they are, people will get very bored very quickly. ...


10

Planning is one area of scrum where teams have a lot of flexibility. Try something new every sprint until you hit on something that works for your team. Some successful ideas I've either tried personally, or heard about from other teams: Do user story creation and prioritization without the entire team. The product owner and/or scrum master can handle a ...


10

The original idea of the daily standup is certainly to do it in person, because this enables a communication channel with way more bandwidth then anything based on writing. Having that said, doing it in writing via mail, chat or similar can be a great choice if it actually solves problems you have with the face 2 face communication. Especially with vastly ...


9

15 minutes. Does that 15 minutes (plus the time to prepare for it) convey enough new and useful information between team members to improve the teams productivity for the coming day by more than 15 minutes worth? If there's not that amount of useful scrum content each day, the team members are probably thinking that they'd make far more progress toward the ...


8

Cancel the damned meetings. They have no point unless they have a point. I have been at too many of these over the last 15 years. I'm pretty sure that if the brain cells injured by these no-agenda "team meetings" were still functioning, my team and I would have built something that sold for billions of dollars and I could retire to relative obscurity and ...


8

I'd suggest if you hold the Retrospective meeting to see "What went well" and "What did not go well" and see if the developers list the daily Stand-up meeting itself as a waste of time. Then you would need to re-organise it a bit. My personal experience: The aim is to know what we are doing today and where we were yesterday. Instead of sticking to the ...


8

... the more definitive statements a man makes the more likely he is to be definitively wrong ... - tyler durden this applies to blanket "standards", while on some tables this could be a huge win, on every table it would most likely be useless noise and more code to maintain or forget to maintain. there is a balance to be had here, that is what you ...


8

I agree wholeheartedly. Almost every table in every database should have at least 2 fields: the creation date and update date. There are many reasons that you should put a create date and update date. For obvious reasons that prior people stated…which is audit. I have been designing systems and databases for 25 years and have worked for hundreds of ...


8

You mentioned three types of questions: a) you do not know the answer to: Tell them I don't know the answer, but that you will find out the answer. Then write down their question/concern and get back to them quickly. b) you have not thought about for one reason or another: Tell them that is an interesting idea. Then write it down and followup quickly. c) ...


8

You said that the meetings feel like you are lecturing them. If it feels that way to you, and the team doesn't seem interested in what you have to say, then why still have the meeting? If you're just throwing information at them, and it isn't holding their attention, why not just summarize everything in a weekly email instead? If you want to make use of ...


8

TL;DR When properly executed within an appropriately-sized Scrum team, the daily stand-up should never take more than 15 minutes or so. If it takes longer, either the team is too big or you have a process problem. The Purpose of the Stand-Up The daily stand-up is a commitment and coordination meeting for the entire team. It is designed to ensure that the ...


7

The resistance comes when: 1) They are used to force people to rush in for 9am. It's extra stress when the train is late. 2) Poor scrum leadership. The leader should be telling people to take stuff off line rather than have people stand around listening to something that doesn't affect them. 3) Valueless content. This is again a scrum leadership issue. It is ...


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