by ghr on 3/30/13, 10:49 AM with 62 comments
by onemorepassword on 3/30/13, 12:05 PM
"30 minutes", "action points", "notes", "weekly update"?
Seriously, I know that "you're not doing it right" is the standard lame excuse from Scrum-evangelists, but this paints a picture of doing pretty much the opposite of Scrum.
Especially the emphasis placed on the "weekly update" is a big red flag, suggesting this team is doing something that isn't even close to being Agile. Agile and Scrum are supposed to be about delivering working software, and in the case of Scrum it's strictly time boxed. Weekly updates suggest micro-management and/or not delivering anything shippable.
Only the 10:00 versus flex time is a genuine issue. We have a very simple solution for that: if you can't be there, mail it in (or use HipChat). Yes, this also applies to people who start early and are deep in the zone by 10am. It's not supposed to be a two-way conversation anyway, just quickly syncing up.
by ratherbefuddled on 3/30/13, 12:52 PM
The standup (in Scrum at least) should be three questions everybody answers: What you did yesterday, what you're doing today, any blockers? This should take a team less than 10 minutes easily.
These meetings are not supposed to generate actions points, or problem solve, or discuss anything. They are merely supposed to make sure everybody knows what's going on.
Follow up specifics later with only the people who need to be involved.
The time of the standup should be set by the team not imposed on them. Consensus is needed.
by slu on 3/30/13, 12:07 PM
A six person team should be able to be done in less than 10 minutes. If someone gets off topic or rants on about details, stop them, and perhaps suggest a meeting afterwords.
You solution totally ruins the dynamics of the standup.
by benjaminwootton on 3/30/13, 1:04 PM
>> Morning standups force people to be in work before 10:00.
What's wrong with that? Surely 10:00 can be considered core hours for anyone who isn't a remote worker?
>> They always overrun. Rarely are standups shorter than 10 minutes. 6 person team * 30 minutes = 3 hours lost.
They never last that long in my experience, but even if they did, 30 minutes per person per day to sync up the team sounds reasonable to me.
>> Action points are rarely produced, so the value of the outcome is questionable.
Standups aren't about acquiring 'action points'. They're about knowledge sharing, raising problems and impediments, making progress visible etc. You don't decide during the standup what people should be doing.
>> Others switch off if they’re not interested in the current monologue.
That's why it's a short standup. Its whole reason for being is to avoid long meetings, status updates and overhead. Anyone who can't stay focussed for 15-30 minutes in a morning also has a severe case of ADHD.
>> Notes are rarely taken, so by the time the weekly update gets compiled the team have to scratch their heads about what they did over the last week.
If you have minutes (and agendas and notes etc) then it ceases to be a standup and turns into just another meeting! Again, the whole idea behind the standup is to avoid this kind of stuff.
There is lots you could rant about in agile, but a morning standup is definetly one of the things you should retain.
by benaston on 3/30/13, 1:39 PM
by JackMorgan on 3/30/13, 11:50 AM
by DanielBMarkham on 3/30/13, 1:27 PM
I believe in a meeting-free workday for the team. To do that, the best way I've seen so far is everybody getting together briefly to describe what they've been doing, what they're going to do, and if they need help. Immediately after everybody has their turn doing this, people are all together in one room, they're all aware of who needs help and who is working on what, and they can begin the actual work. Maybe that means everybody grabbing a whiteboard and talking over a problem for an hour. Maybe folks chat for another ten minutes and then all work separately the rest of the day. Don't know, don't care. The team can figure it out. A standup is a dynamic way for a team to create its own daily agenda without using a bunch of calendaring apps and trying to mastermind everything ahead of time.
So when done well, it looks like the most totally natural thing in the world -- bunch of guys just listing what's up to each other and then doing a bit of work ad-hoc. Why would you need structure for that? (Even though there is quite a bit of structure and discipline involved) Aren't we just exchanging data? When done poorly, it's a god-awful thing that drags on, nobody is involved with, and serves no purpose. Blech.
The mistake we continue to make as technologists is to confuse working with data with working with people. When you're writing code, you're working with data. You use tools for data: spreadsheet, compiler, parser, etc. When you're talking about what folks are doing and how the project is going, you're working with people. You use tools for people: lightweight games, rituals, dinners, jokes, body language, etc. You don't use people tools for data tasks; you shouldn't use data tools for people tasks. If you think you could use email to accomplish stuff you do during the standup, you don't understand standups.
Sorry to run on like this, but I'm a big standup fan. In fact, if I had one thing I would want to do in any team, it'd be good standups. For many small teams, you could almost trash every other piece of process and do standups well and be fine.
by sklivvz1971 on 3/30/13, 1:25 PM
"I don't understand how to do it right, I've had a bad experience therefore it's bad."
WRONG. Complaining about something you don't really understand is what is _poisonous_...
Real life counter-example:
* Standup with a 15 people team lasted 7 minutes every day (worst day, 10 minutes). This included 2 remote members.
* It ran at 10am, so people in flexi time could come as late as possible (core hours start at 10am).
* Scrum master noted all impediments, and those only, so action points were always taken if necessary and skipped if pointless.
The key is: do it right, with self discipline. Agile is a practice, and as with any other practice it takes dedication to master.
Simply doing stuff superficially and then complaining is... unuseful.
by Swannie on 3/30/13, 1:37 PM
I've tried to do the whole "email instead of standup" thing. Guess what? No one reads the damn email. No one cares. Nothing happens. The stand up is meant to get people talking and not reading emails.
Yes, I documented out standups. This was because, yes, people can't make every call, can't make it to the office, are on holiday and need to know quickly if there were people waiting on them for feedback. So they could review the daily "minutes" and see if someone needed to talk to them. This worked well, though it usually took an additional 10 mins of my time finishing the email before sending it out.
And yes, management needed to report on progress. I tried my hardest to keep my devs OUT of the weekly progress call, and insist only team leads be present, but management weren't happy (and tended towards micromanagement of issues, but that's a different story).
And whatever you do, don't ditch the stand up. It's the best part of the day if you're truly a team player, as you can find out where you can make the biggest contributions to your team. If you notice patterns of issues, you can work to solve them. I've worked in too many teams where you could go for days, that turned into weeks, without talking to a quiet and reserved team member about the specific technical problems they were working on. Not good.
by _ak on 3/30/13, 1:22 PM
by mmahemoff on 3/30/13, 1:02 PM
(Yes yes you don't have to stand if you have a broken leg etc)
Action points aren't supposed to be produced. Standup's there to help people understand what everyone's working on and ensure there are no blockers. If there are blockers such as someone has no tasks or is waiting on someone else, you set up a follow-up meeting with just those people. Then you get your action points.
by Proleps on 3/30/13, 1:21 PM
I once did an internship at a company where we would do the standup over a conference call, we would also sit. We were such rebels :P.
by rehashed on 3/30/13, 11:55 AM
The most important thing to get out of the meeting, IMHO, is challenges, as status should be evident by the location of your story tickets. The problem with providing an environment where "Others can skim-read or ignore." is that they often will, and peer challenges can easily go unresolved without adequate feedback.
You are standing for a reason - its uncomfortable (for those of us who sit all day). Your facilitator should be roping in the conversation (and if not you need to replace them - rotating among team members often works). If that doesn't work, then your teams are likely too large.
by harryf on 3/30/13, 1:01 PM
IMO the hidden goal of standups is to make sure a development team communicates, ideally face to face. Why? Because it's extremely valuable to shipping quality code / product etc. My experience has always been when standups over-run, the reason is there's some topic that needs discussing and preventing that discussion from taking place is usually a mistake.
Without standups, in a typical office environment with introverted personality types, communication doesn't happen. So in the end they're a compromise; perhaps not the best solution to the problem but good enough.
by pasbesoin on 3/30/13, 7:39 PM
The solution reads vaguely like: We're already distributed (in time -- flexi-time -- if nothing else), so manage us like a distributed team.
The solution still strikes me as somewhat too bureaucratic, vis à vis the intent of a "standup" ("daily X", etc. -- choose your own name), as I see it. That being to informally, loosely, but effectively sync members' working states and awareness. Everyone should be free to take what notes are personally meaningful to them.
But formal documentation should be a separate track. That would include the "agenda / meeting notes" PDF CYA that appears to be going on and/or proposed, here.
by Karunamon on 3/30/13, 9:00 PM
I feel that the entire concept of the standup forces face-to-face interaction where none is necessary. Time that I'm wasting sitting in a room is time where my fingers aren't on the keyboard making things happen.
You do not need voice and physical presence to organize a project, or ensure everyone is on the same metaphorical page, or to find out what everyone is doing.
Imagine the communications medium of your choice, and then ask if the meeting couldn't just as easily be coordinated via that system instead of forcing everyone to get in a room and waste valuable time? And get you benefits such as easy access and archivability?
by jkaljundi on 3/30/13, 12:12 PM
We currently have only daily progress input via e-mail at Weekdone, but are looking at providing daily e-mail summaries as well.
Appreciate any input how to make a process like that better in a web/e-mail/mobile service.
by calpaterson on 3/30/13, 12:17 PM
Standups that routinely last longer than 15 minutes need to be corrected. Either split the team, don't have everyone talk every day or find some other way to cut time.
An email is not a terrible substitute if someone is working from home, but part of the value of a standup is that you can quickly ask questions and get answers right there and then.
by donnfelker on 3/30/13, 1:17 PM
by vpeters25 on 3/30/13, 5:55 PM
I respectfully disagree with all the "you are doing it wrong" replies. In this case, it's not your or your team's fault, but your scrummaster is definitely doing it wrong.
I've been scrummaster on teams over 12 people and our daily standup meetings lasted around 3 minutes and rarely got to 10 minutes or over.
In agile, the team self-manages itself. If 10 am is not working, change it. If meetings are taking too long, bring it up as a blocker on the standup itself or on the next retrospective (you guys do these, right?). Have the team agree on making adjustments but focus on one adjustment every iteration.
In short: Inspect and Adapt
by karterk on 3/30/13, 1:17 PM
If you have daily stand-ups, why would you have 30 minutes worth of update per person?
This whole article is pretty extreme. Standups, just like any other process (light-weight or otherwise) is only good until its original intention is being served. If a standup is taking a long time, make it a point to cut it short. If someone is narrating a long story, ask that person to stop and take the rest offline.
Finally, everyone should understand that stand-ups are used to convey status and information about important things. It's not a recital of what each person did the previous day. Sometimes, you might have nothing to say and in that case, just say so. Nobody should be talking about details in standup.
by Sunlis on 3/30/13, 1:22 PM
Of course, we haven't solved the "you must be in my X:XX" problem, but doesn't every meeting get I the way of flex time?
by tjtrapp on 3/30/13, 3:55 PM
If someone starts to get off on a topic that isn't related to "what i completed yesterday", "what im going to complete today", "any impediments" then raise your hand and call "parking lot". This informs the person to wait until after standup to have the conversation.
The first time I did it people thought I was crazy. I got looks like, "who the heck is this guy to cut me off?" but the next few times I start to raise my hand, the person realizes and ends their talking.
Give it a shot. Google "stand up parking lot" for more info.
by fadzlan on 3/30/13, 12:06 PM
My take here is that we should have much smaller teams and if possible have Scrum of Scrums to handle bigger project. However, I know that this might not be possible for some since some project tends not to have a good demarcation on what should be in which teams.
by ascotan on 3/30/13, 7:13 PM
1. It should be a place were the lead helps people coordinate. Not just work, but their schedules. If dev A will be finishing up widget A on Wed. then dev B knows he needs to hustle, etc.
2. It's a place where QA can get a grip on what's happening in development. Most of the time QA has no idea what's going on in dev, and having the QA guys in scrum helps them.
3. It forces lazy devs (who spend all day on youtube) to actually report status the next day in front of all the other devs.
A few more thoughts.
1. It should be around 15 minutes. Too short and it just becomes a round robin. That's great, but a lead should be able to adjust the work and coordinate at scrum. You can't really do that in 3-5 minutes. If it's too long, the devs get cranky because you're killing their dev time.
2. No PMs. Project managers imho should not attend scrums because they speak a different language (it's called powerpoint) and they usually a) don't understand what's being said b) freak out when qa says there's a bug c) like to get on a soapbox about schedules and releases when it's not appropriate.
It's far better to have the lead/leads manage the PM separately be delivering separate status reports to him directly (either through email or a formal report-like deliverable).
3. No more than 10 people. I would say around 6 is best, but you can't have a 15 minute scrum, when the number of people is too large. If you have more people, you need to split them into groups of 6-10 and then have a 'superscrum' for the leads. This type of 'superscrum' is great for have the PM join in, because it can focus mainly on resource management and schedules (which is what PMs love to talk about).
@OP I've actually have asked for people to report status via email (particularly when I have a bunch of remote guys), and it's really terrible. You end up getting a bunch of emails which you have to respond to. That's great if your a developer and you can put you AD LIB email on a cron job for the lead, but for the lead, the coordination of the team via email will eat up most of your morning. It simply better to call in or show up and everyone be in the same room for 15 minutes.
by Morendil on 3/30/13, 1:57 PM
Useful blog post: "We tried X expecting Z, but instead Y happened. I wonder what's going on, please chime in."
The mistake here isn't "negativity", it's Z-blindness. It's missing out on an opportunity to revise your model of how the world works, by noting that there is a discrepancy between your expectations and how things actually turned out.
(Of course, the "useful" approach results in less sensational titles, which may be why we see fewer of those.)
by motoprog on 3/30/13, 12:43 PM
by securingsincity on 3/30/13, 2:02 PM
by rubyrescue on 3/30/13, 1:40 PM
by jimgumbley on 3/30/13, 12:13 PM
If the person in question can't be coached to collaborate with others then a role where they can be a sole contributor may be better.
by podperson on 3/30/13, 12:38 PM
In my experience keeping standups under 15min is the easiest part of the process.
Turning the standup into paperwork seems insane to me.
by scottmagdalein on 3/30/13, 12:23 PM
by walshemj on 3/30/13, 9:53 PM
Though he's right teams should know how how to run meetings and Action Points.
by westonplatter0 on 3/30/13, 1:34 PM
Sounds like all of you have developer communication issues, not standup issues.
by cshimy on 3/30/13, 4:08 PM
by norswap on 3/30/13, 2:06 PM
by Uchikoma on 3/30/13, 1:25 PM
by michaelochurch on 3/30/13, 11:56 AM
Here's why Standups can be powerful and, actually, a bit subversive. They create Common Knowledge (see: http://en.wikipedia.org/wiki/Common_knowledge_(logic) ) of what you are doing. That's different from shared knowledge. Shared knowledge means everyone knows it. Common knowledge means everyone knows everyone knows it (and, recursively, everyone knows everyone knows everyone knows, and so on...). Bob knows you are getting useful work done. So does Tom, your boss. But, thanks to Standup, Tom also knows that Bob knows you are getting your work done. At least in theory, this limits Tom in his ability to isolate, disempower, disparage and ultimately create cause to fire you. Standups move authority away from managerial hands. They're not intended toward that effect, but if they work well, that is something they accomplish.
(Of course, in a closed-allocation company, your boss can just give you impossible or extremely boring work if he wants to flush you out.)
It also needs to be made clear and constitutional that the daily standup is the only status-reporting overhead, except in a production crisis. If there's Daily Standup and your boss gets to interrupt you regularly with status pings (which is a show of power; he probably won't even remember that he asked you, just like people look at their watches but forget to read the time) then you're just getting screwed.
Also, I agree that standup before 10:00 or after 4:00 is just shitty. I'm usually up at 6:00 am, but the idea that you have to have the same schedule as the boss to be a worthwhile human being is just garbage.