This, a million times. (Which is how many I feel like I've said it so far.)
Conversely, this particular dysfunction of standups is a useful index of how much the corporate culture leads people to feel like they must justify their existence.
If I haven't made any progress since the last day, I just talk about what I plan to do for the upcoming day. I also might say "I'm still working on (the thing I was working on yesterday)". With a well functioning, trusting team that should be a perfectly reasonable thing to say every so often.
To me, that's a sign of low collaboration and low trust. If your team does regular retrospectives, I'd just say, "Look, I feel like in stand-ups, I keep having to justify my existence. Do other people feel that? What can we change to make that better?"
Off the top of my head, I'd look at the size of the unit of work and the length of the release cycle. I think Agile processes work best when the work is broken down into lots of small deliverables that meet the INVEST criteria:
If the team is jointly completing a few shippable things a day, then everybody should have a pretty good idea that everybody else is working. Doubly so if those are actually getting released daily.
In a meeting where you're supposed to say what you've been working on, at a job where you're paid to be working on it, in what way is it fine to have nothing to report?
You were blocked by some externality. If all you have to report is "I'm still waiting for Larry in XYZ group to send over the new protocol specs", then that's all you can really say. Vis-a-vis the daily scrum/standup, that's all you have to say. Issues like "what else could you be doing with your time, what are we paying you to do" blah, are a topic for a different audience and a different time.
That said, in a quality team staffed with quality people, you don't worry about people goofing off during the time they're blocked... you assume they are doing some kind of self-development, or tweaking some small detail somewhere, etc. It's when somebody is blocked for long enough that it puts their tasks in jeopardy that the scrummaster needs to start escalating things and working to get the roadblocks removed, and/or manage expectations vis-a-vis the tasks for the iteration.
My team just went through more agile training, and one piece of advice I found interesting was to consider keeping the managers out of the standup if it's not working. The meeting is to help others on the team, so that's the only people who need to be there.
Absolutely! And once things are running well enough that you can let the managers back in, it's still reasonable to forbid them to talk. Unless they are on the hook for deliverables, then they are at best there to observe.
Honestly, I can't understand all of the vitriol around "agile" methods that arises here occasionally. If you're doing something that works for your team, do it, if it doesn't work, do something else. Isn't that the whole idea behind "agile" stuff? Do people get stuck in situations where they have to do X because "we're doing agile, and agile says we must do X"? If so, can't the offenders be gently pointed to http://agilemanifesto.org ?
I believe ist's a combination of never having experienced the monstrosities agile was invented to replace, having experienced agile done wrong, and natural cowboy coder hybris.
In my experience, the "cowboy coder" is sometimes indeed disruptive (large unannounced refactors, e.g.), but almost always they are the most productive people on the team, the ones who contribute the best and most code.
I learned one of the Agile methods before the term Agile was even invented. Adopting it made a giant difference in the quality and sanity of my work.
But so many people today have have pseudo-Agile methods inflicted on them in large corporate contexts. There, the point isn't to make things saner and more effective. It's to please some executive who has a bee in their bonnet. And often, they only adopt some labels and some rituals. It's all pain, no gain.
But it's at the point where I avoid using the term "Agile". Or any other buzzword. I look at the circumstances, and say, "Hey, you guys feel pain X. Can we try change Y and see if that helps?" Often, the tool is one from the Agile or Lean toolbox. But I won't talk about the particular process I'm borrowing from because a) most people don't care, and b) a lot of people have been burned with faux-Agile adoptions.
I believe the bulk of what people call "Agile" these days is terrible. You could say that most of that isn't the true Agile. But at some point I think that isn't a battle worth fighting. Personally, I just say that Agile started out as X and has become Y.
I would rather they didn't throw the baby out with their bathwater, but in the stories I have heard, the vitriol is entirely valid. I don't think it should be all directed at "Agile", in that managers deserve a lot, as do the hierarchical power structures in which the managers work. But the Agile people also made choices that led to this outcome, so I think it's fair that there's some spleen-venting directly at the Agile movement.
Standups can however very easily become very uncomfortable in a dysfunctional environment. (As the original article unwittingly demonstrated.)
Consider the standup to be the canary in the coalmine. Most of the time people can ignore the dysfunction, work around it and pretend it isn't happening by just getting on with the job as much as possible.
But the standup will then become increasingly uncomfortable. Every single day.
In a healthy organisation, you can have perfectly pleasant standups, even without Scrum or Agile. I mean, what does a healthy team have to fear from standing around for a few minutes bringing each other up to speed?
It's a process that is very close to what often happens quite naturally around the time everyone on the team has arrived at the office (or online).
A standup can only become poisonous if the poison is injected from elsewhere. In Gareth's case abusing it for management status reports. In other cases it might be tension between team members, not having a clear goal, whatever.
The point is, you cannot have pleasant standup if there is that kind of stuff going on. Which is all the more reason to have a standup, unless it's your policy to ignore problems rather than dealing with them.
Standups aren't just not poisonous either: they are a very good poison detector.
It's a process that is very close to what often happens quite naturally around the time everyone on the team has arrived at the office (or online).
This is exactly the behavior I have seen of well functioning teams. Usually there is a period when the person comes in, maybe after coming up to speed on their email where they get informed and up to speed on what is happening with everyone, if anyone needs anything, what people are working on, and then get to work!
Standups are just a formalized approach to what can be a drawn out process for an individual, and in some cases may not be "normal" for your standard introvert dev types who sit at a computer all day and perceive meetings as multi-hour long chores that are inflicted on their participants instead of quick high quality bursts of information distributed in an efficient fashion (face to face).
Thank you. Most of "agile" "process" serves one purpose: to shine light on every aspect of your team's functioning. What you do with what you see is up to you.
Standups would make more sense if the team did not communicate during the day. The reason I think they are pointless is that when a blocking issue arises, you drop what you're doing and walk straight over to the person who can help you. I've never seen or heard of someone waiting until the following day's standup to bring up the issue (which is supposedly what the standup is for, right?).
Standups primarily are for making sure everyone knows what's going on.
If you're doing Scrum, the only issues you should really be bringing to standups are those you can't solve within the team that you need the Scrum Master to sort out. Anything the team can fix for itself isn't blocking, it's business as usual.
This is why I don't allow them on my teams. You have a block or issue and you're going to passively wait until the next morning or whenever the next meeting is? No. Deal with it when it comes up, don't lose half a day.
A standup is generally what it sounds like - the entire team stands up together and quickly/briefly cover what they have worked on in the last 24 hours. This can be as simple as "still working on x", or "i need x from y to continue".
Some places don't manage standups well at all, and that is one of the big problems with standups in general - they become status meetings and take too long. When done right, they are very useful as you quickly know what everyone is working on and if someone might need your insights on something (which should then be a separate meeting and not covered in the standup).
There are a few main features of standups that, if abused or ignored, can lead to awfulness.
- They're supposed to be short, very short. A few minutes at the most. They do not work for large teams (20 people giving a status update is a lot), and if you find yourself having 20-person standups it's time to think about if you should be breaking them into multiple independent standups.
- Managers aren't present, or aren't allowed to speak. This is an opportunity to ask questions, ask for help, describe what you're working on, to other members of your team, not to justify what you were up to yesterday to your boss. It's sharing, not reporting. This part is key.
- You don't troubleshoot in a standup. If you say "I can't figure out why I can't Foo module Baz", there shouldn't be a discussion about it, but someone else might go "I've worked with Baz a lot, let's take a look together after standup.", or later in the day someone might go "Oh hey, that problem you were having with Baz? I think I know what's happening." - this is the ideal intent of standups. Very quick snippets that highlight certain things in everyone's minds.
- It doesn't need to be documented. It's not a meeting, you don't need to take down minutes. Actual tracking of work done occurs separately (your scrum master should be doing this).
Holy crap, he has 3 hours standups? They're called "STAND UPS" because you stand while giving them so that you're motivated to be quick! I actually try and follow the one-breath rule for what have I done, what am I doing, what are my blockers.
I read that but it sailed right over my head until your comment because that is an utterly banal observation. Yeah, Microsoft spends 12 man months on bathroom breaks every single day too; I guess that's why they are going down the shitter.
I agree that it is not a very deep point but I think the point is a different one from the point your analogy make. People go to toilets, slack off and do all kinds of things during work that are not actually work. Those things are unavoidable. However, meetings that take too long are avoidable, have a low value by definition and thus require management action.
I'm genuinely curious, how are standups not status meetings?
From the article:
- Make sure everyone is working on the right thing
- Help out other team members by taking work off their plate or helping them by sharing domain-specific knowledge
- Keeping everyone informed
How is that different from a status meeting? I've heard "standups are not status meetings" over and over from the agile community, but I don't get it. They sure seem to be quick status meetings that allow everyone to get a handle on the current status of the iteration?
Disclaimer: I'm not an "agile guru". I've worked for years in an old-school corporate environment and just recently switched job and joined a small agile team. My views on agile don't come from reading or theory, they come from my one month experience so far.
The only difference between standups and status meeting is that you're not there to fill a report card. You're not there to show your manager you did something. You're just there because it's the only 10 minutes in the whole day where the whole team comes together to discuss. It's (at least in my place of work) highly informal, very chilled and very genuine. What we do is say what we're working on and ask for help and/or ideas.
We have a private IRC channel for this, but the fact that we meet face to face for 10 mins a day really does bring up interesting fast conversations.
The whole point of standups is not to take notes, not to keep track and just have a quick break to talk (not type) about work.
Standups are useful to the team. They are for making sure everybody knows what's being done and impediments that can't be fixed inside the team get kicked to someone who can focus on them. Anything in a standup that isn't useful to the whole team should fall by the wayside. They are standups to encourage them to be short.
Status meetings are for the benefit of a manager. They allow everybody to report to the manager so the manager can feel comfortably informed. These are typically useless to everybody else because they drag on for far longer and nobody pays attention whilst each individual briefs that manager. These sorts of meetings are detrimental to getting a team to self organise.
I think there's a stigma attached to the notion of the status meeting. Beyond that, at least to me, a status meeting is a kind of assymetric situation where one person with some kind of authority (manager, PM, ...) is trying to keep tabs on everyone else's work, where each attendee has to prove that they've been doing their job. In a standup, it's a kind of egalitarian environment where everyone is speaking to everyone else, and nobody is taking notes to report up the food chain.
I agree with this. Most of the time status meeting is usually something I associate with bringing my manager up to date on what my team is doing. Typically this is a 1-on-1 situation. Sometimes it involves other managers outside of my hierarchy but still under product ownership.
I agree this is the key difference, and I think the root of one of the problems: many workplaces that implement standup meetings have a manager or PM present at the meeting, even though this is discouraged by many agile evangelists. Sometimes the PM even acts as the scrum-master, despite the scrum process as officially conceived really discouraging that. And then it turns into daily short reports to the boss.
This is exactly it, and I can't help but wonder if the people who vehemently dislike standups actually work in such environments (I know I have).
I also feel like the original "Standups are Poisonous" author may work in such an environment also.
I once worked for a company (who shall remain nameless) where the development process could be generously described as a perversion of agile. They wanted the cool buzzwordy notion of agile, but didn't want to actually subscribe to an egalitarian, hands-off environment where the engineering process is largely self-managed.
So, manager as scrum-master (noooooooooo), manager present at standup (noooooooo), and worst of all, story points becoming a measure of productivity (noooooooooo!). Standups would routinely last half an hour, even though our team was literally 4 people large, because the scrum master/manager would stop someone and drill down constantly.
Oh, and the manager ran estimation too, and with pressure from above would blatantly try to influence estimates downwards. The rest of the team compensated by inflating small tasks. Yay.
Tasks would also get assigned to specific team members from the get-go, because the team was horrifyingly silo'ed and we were constantly "too busy" to cross-train by spreading tasks around. I find that silo'ing is by far the biggest thing that makes standups seems irrelevant - why listen to what that guy is doing if that task has no bearing whatsoever on anything you're working on, or will be working on?
Funny, that reminds me a lot of my last job. I am sure there are a lot of people stuck in a similar situation out there. Team members can't help but become biased against the process, and by association, the 'Agile' label.
Yeah, these are all common dysfunctions in teams getting started with Agile.
You see these a lot in cargo-cult style adoptions. They understand that they need to do these practices, but they don't understand why. The end result is that they try to pervert them to serve their own purposes (e.g. daily stand-up as a status meeting for managers) and lose the real value. Then they complain that "Agile doesn't work here".
When I think status meeting its usually beyond roadblocks that were brought up during standup or several standups. Some of our stakeholders aren't present.
To me a standup is a tool to keep the team fully gelled and jump on any issues which will cause a sprint to spiral out of control. They should only last a few minutes per person (we have about ten people) and we schedule coffee immediately following to tackle any issues that were tabled due to a timebox.
Note: We have a 'coffee club' where everyone brings in coffee and we french press it every morning. So its scheduled only so that nobody pulls us into meetings ;). We love our coffee.
I've never experienced standups that weren't status meetings, and weren't serious flow disrupters. You get to the office, but don't really want to get too deeply into your work because you know standup time is 9:00. The team gets together, each person summarizes what they did yesterday, what they plan to do today, what blockers they have. Everyone else mostly zones out. Next thing you know 30 minutes have passed, and by the time you get back to your desk and start to get ready to work you are already thinking "well lunch is coming up, no point in getting into anything substantial until the afternoon..."
I think standups could work, but they should only focus on things that impact the project (breaking change to an interface, or significant new things that are available) or things that are blocking work. And honestly I think email does a better job at that with a lot less impact on flow.
The common thread I see in your complaints about stand-ups are the "I can't break my work into pieces, I need several hours of intense focus to work on anything."
E.g., Your stand-up is from 9-930a. After which you can't start anything substantial because 'lunch is coming,' but that's 2.5 hours away (assuming you lunch at noon).
You're looking at the wrong side of the meeting. It's the time before the meeting, not the time after.
I like morning stand-ups, but a big problem is that if the stand-up is at 9, I start winding down whatever I'm doing around 8:30, and I don't start new tasks after 8-8:30. Multiply the loss by the entire team every day and that's potentially a big loss of time. And because everyone's schedule is different, there's really no place to put the meeting that avoids the problem.
The benefits of a well-run standup can outweight this productivity cost, but it's a real cost that needs to be considered.
Has anyone ever tried an end-of-the-day standup? Would not tend to disrupt flow, because you're going home afterwards. Also might help keep the gathering focused and on-topic.
I guess this does presume that everyone wraps up at about the same time every day, which I've generally found to be the case, but may not work well with widely distributed workers or places where people actually practice a wider range of work hours.
I have seem teams use end of day stand-ups. The problem with those is that they tend to devolve into status updates pretty quickly.
Team members report on what they did that day, but seldom think about the things they are going to get done next and the things that are preventing them from getting started on the next thing, which in my opinion, are the more important things to focus on.
A team I interned with did standups at the end of the day but honestly, at that point, you just want to go home; you don't want to stay to hear what's going on with everyone else.
30 minutes? That's definitely a long time. I've only been in an environment that does standups for a few months now, but for 5-8 people (team + PM/etc) it has rarely gone beyond 5-7 minutes (everyone rhymes things off in 40-60 seconds each, and any spin-off conversations are aggressively deferred).
It actually has worked really well in preventing of siloing/cliquing of work effort. Another thing that has helped greatly is using a physical task board and organizing conversation by task instead of by person. This puts less emphasis on "looking useful" as individuals and more on championing tasks to see their completion.
> This puts less emphasis on "looking useful" as individuals and more on championing tasks to see their completion.
This is a very good approach. Separating task and people is key to getting things done. When things are getting tough for an individual, the team can rally behind.
Yes, you've experienced terrible stand-up meetings. My rule of thumb is 10 minutes, max. Is everybody really standing comfortably for 30 minutes? Your coworkers must be tougher than I am.
Also, who are people talking to if not the rest of the team? Why are they saying things that other team members don't care about?
Speaking as an engineering manager - I've only had to use standups in environments where engineers were not good at checking in their code and closing out issues regularly. I HAVE to have that information, regardless of how I get it.
I would strongly prefer to have a stream of commits and JIRA issues in HipChat to review the following morning than have to do a standup. But not all engineers are as good as they like to believe they are at following development workflows and processes.
Since you are a manager, I might suggest that the Agile and Scrum the daily stand-up isn't for you. While I appreciate your need to know what's going on with the team, in Agile and Scrum, the daily stand-up isn't there to provide status to managers.
The purpose of the meeting is for the team to get together and co-ordinate the work that needs to be done in order to meet their Sprint goals. So while you may be able to get status information out of that, it's more important for team members to use that time to figure out how to meet their goals.
In addition, status should be obvious in Agile teams. This is why you usually see things like cards on walls and burn down charts. If status isn't obvious to everyone, you may want to see if there are other ways the team can make that information highly visible.
> Since you are a manager, I might suggest that the Agile and Scrum the daily stand-up isn't for you
I definitely agree with this. Standups/scrums have become much more productive since management stopped attending. It's hardly a "status" meeting any more -- sure, we talk about what we're working on, but there's a lot of jumping in by other team members with suggestions, help, or "I was going to do something similar, let's coordinate after the meeting".
The difference is the audience. I usually think of a status meeting as a one-way infodump from worker to manager. In a well-run standup, your audience is the whole team, because you're accountable to the team rather than any one person, and as a team member you're an active listener. If everyone's talking at the boss while the standup is going around then you're doing it wrong.
Exactly this. I've seen plenty of faux stand-up meetings, where it's all about keeping the boss informed, and everybody else zones out. That's entirely wrong.
Another wrong way is to take a long time. It's a quick meeting, where everybody syncs up for the day and major issues are raised. I think of it as like the way players will quickly huddle together on a sports field. It should be high energy, biased toward finishing, and tabling any significant discussions for later.
As far as I'm concerned, they only make sense in a team environment. Where people are jointly working on shared goals and extensively support one another. In the Extreme Programming approach, they go along with a team work queue and collective code ownership.
If people, say, have individual work queues parceled out by a boss and don't interact much, then as far as I'm concerned the stand-up meeting is the wrong tool.
Easy enough to say, not always easy in practice. If "the boss" has political sway then it's never going to happen. I worked in an environment that considers itself "very agile", because it "does standups". Any suggestion that it's being done wrong makes you look confrontational.
I was there because the money was good. Motivationally it was about as effective as being micro-managed on a waterfall project.
I've been doing agile scrum in a seven person team (scrum master, four developers, a product owner and our immediate line manager, with the occasional addition) for over a year now every single day. We try and get it over with as quickly as possible with people letting one another know when they are stepping over being particularly "stand up" - i.e. having a discussion or talking with one another. We don't always get it right, but like everything in agile it is iterative.
I find it supremely useful - it builds self-understanding in the team and a sense of actual teamwork, even camaraderie, improves visibility of what everyone is doing (and where you may be able to help - we often chip in when someone says they are stuck to say "yeah I know a bit about that, let's chat about it after stand up") without feeling like surveillance. You also get to know if there are going to be any demand on your time for discussion (say of upcoming work) from our line manager. It is not a status meeting. Both the theory and our lived practice make it a synchronisation meeting that defines the heartbeat of the sprint process. Its actually a comfort to know if you are stuck you can say so in the stand up and people are aware you are having difficulty.
If you are doing scrum right then status meetings should be unnecessary during a sprint. The interaction between the team and the product owner (co-ordinated by the scrum master to prevent the product owner becoming noise) should be sufficiently smooth that when you get to the demo at the end of the sprint nothing should be a surprise to the product owner (they are part of the team after all) but should be for consolidation and display to wider stakeholders. We use e-mail and GitHub issues to keep the product owner in the loop at all times (increasingly moving to just GitHub) and HipChat for status throughout the day. As for "higher level" status meetings, our line manager has no need for this from us because she is much closer to the work through the stand up and our scrum master will handle these duties as required so we can get our heads down in the sprint. Status meeting for more senior management are the job of the line manager, who also plays a role in just letting the team get on with development. Status meetings as people seem to be describing them here seem to be the kind of productivity killing time sinks that the scrum process defines as "noise" and attempts to use the scrum master to keep as far away from the team as possible.
(PS I work in IS Web Development University of Kent where we take agile process in our team very serously - we'll shortly be hiring ;-) )
I've been thinking of writing a script that pulls down commits from <yesterday>, formats it "properly" and pipe them to SAY.
"Wednesday, 24 April
Fixed bug #434, added protocols between user and tasks. "
And if they _really_ want to know what I am going to work on or what issues I have. Please check my tracker. There are bugs, features and chores. And each of them has comments that describe any issues I might have run into or will.
Actually in a well ran agile team, you should not need that as you should be focused working on only one user story.
If you are fixing bugs then the story should be "x bugs related to foo feature" and your daily standup report should be "I fixed x bugs on foo, I have y to go, should be done today, no blockers"
First, in agile teams, there is no assigning of tasks, each member takes the ones they feel like tackling.
Agile in not optimal for maintenance or emergency production issues. These are dealt immediately and only mention in the daily stand up as a blocker stopping you from finish the task you actually intended to complete. They are not even added to the product/sprint backlogs.
As a rule of thumb all user stories added to a sprint should take between half and 2 days to complete. If you have a whole bunch of small bug fixes, group them together so they fit in that time-frame (i.e. all UI bugs in page foo). Otherwise you end up polluting the backlog with hundredths of little things and turning your planning meetings into overwhelming nightmares.
Just think about it: if everybody in the team is working on only one or two tasks every day, the daily stand up will take each member about 30 seconds and the whole meeting less than 5.
Standups are definitely status meetings, and there's nothing wrong with that. As someone else mentioned, it's the audience that matters. 5 or 6 good engineers and a clueful manager in a room are going to sync up and get back to work, usually in less than 10 minutes.
Some people, including engineers, are prone to go on and on, perhaps even about something interesting like a bug or a new library they found. Make those people go last.
If the meeting takes longer than it's supposed to, walk out or hang up.
If someone is rambling on about something that isn't going to help the team move forward, say something.
Standups will not fix a bad team, or a bad manager.
The daily stand-up as a status meeting is a common anti-pattern and one I often have to coach teams out of.
While yes, you may be able to derive status from a daily stand-up meeting, that's not the point.
The point is for the team to co-ordinate their work and figure out how they're going to get things done. Done well, it has more in common with a planning meeting than a status meeting.
I actually have a whole course on how to have good stand-up meetings.
Wow that is entirely wrong. You don't figure out how you are going to get things done in a 10 minute meeting. You quickly call out where you are and if you are stuck, so people know who to needs help, or who can give help, or what needs to be done that no one is doing yet.
You don't figure out how you are going to get things done in a 10 minute meeting.
Sure you do, at a very high level. "Milo is doing the SYNAPSE adapters, Stinky is working on the compression drivers, Lisa is doing the UI stuff and Teddy is fixing the build system."
That can be covered in 10 minutes, and then the individuals involved can (and should) go off and hold whatever independent meetings - if any - are required for their specific tasks.
Aside from standups becoming status meetings (which it a mechanism of superficial management used by terrible managers), one of my gripes with them is that they're often redundant -- everyone should know what everyone else is working on, and what everyone else finished, and any blocking issues, via your agile tool (e.g. Rally). Redundancy in information is a terrible, terrible thing, and it leads to a situation where neither becomes canonical because that other thing.
To me, it seems like a waste of time to have everybody constantly monitoring the status of every card being worked on when you can just have everybody stand in one place for 10 or 15 minutes, then maybe another 15 minutes of subgroups talking about potential solutions to issues that were brought up.
On top of that if you really want the tool to show everything everyone is blocked on at any time, you wind up spending a lot more time than strictly necessary just typing status updates.
In my team's standups, people frequently wind up shifting plans to cover issues that are brought up or offering work arounds to mitigate blocking issues and kick them down the road a bit to give the scrum master(who is also our VP) time to clear them. We also wind up frequently offering to pair with different people based on what they're working on(i.e. one dev is working on something that touches part of our system that's particularly fragile, another dev more familiar with that area will offer to pair for the morning).
Since we started doing morning standups I've seen our team get more productive.
You are advocating a meeting once per day. Why not spend 2 minutes at that time to look over the agile board in the tool instead? I look at my team's board several times per day, as well as check-ins, and I spend very little time doing it. I am also aware of status throughout the day instead of once during the meeting.
The average card had maybe 4 words on it. We knew about issues because we talked about them.
I love the written word, but it is so much slower and less efficient than face-to-face communication in so many circumstances. The highest-bandwidth, lowest-latency human communication system is conversation.
Every daily standup I have been a part of or organized has turned into a status meeting. The biggest "tell" of a status meeting masquerading as a standup? When people address the boss, not each other.
What would it be like if the boss wasn't there? I've had good Scrum Masters hide under their desks if people kept reporting status out at them. The point: people in authority need to continually work to fight the urge to be "in charge" during self-organizational meetings.
I'm on my fourth team now since 2005 where I have helped successfully employ scrum, and stand ups are a great part of it. A couple of the biggest mistakes I see being made are:
1) not correctly identifying "chickens" and "pigs"[1]. Pigs get to talk in a standup, chickens do not. In fact any interaction with the pigs and chickens should go entirely through the scrum master (and not during the standup). If chickens want to come to the standup it is to observe only.
2) conversations. The standup is not the time for conversation. The best method I've employed is to have each person specifically answer three questions: what did you do since the last standup? What are you going to do between now and the next one? Are you impeded in any way? The last one is where conversations often start. Scrum master needs to stop those, identify the people who need to talk after the stand up, and move things along.
When you follow those as hard fast rules, standups shouldn't take more than N*3 minutes where N is the number of pigs.
IMO the usefulness of standup meetings depends entirely on the project and the team. It's impossible to categorically say they're good or bad.
For a while I worked on a team with a small codebase, which we all knew pretty well, and it was very likely that if somebody made a change today, I'd be working in the same area of code in the next day or two.
In that situation I thought standups were really helpful.
My current team/project is a bit larger and it's maintenance on a much, much larger code base. The project is large enough that nobody really knows the whole thing very well, and everybody works on a different section and there's not much overlap. If I were to switch places with somebody I'd have a lot more to learn than just what they've worked on recently.
On this project we're still required to do standups, but they're useless. The information wouldn't be very useful to me even if people kept to one or two sentences of what they were doing. Of course, few people do that, and they usually go into obscure details that maybe two people in the whole group really understand. And that's when I tune out...
I'm inclined to agree that Standups can be quite good.
Every morning we have our meeting which maxes out at 15 minutes. The designated note-taker rotates daily and takes the list of current action items to be added to RedMine.
The biggest difficulty was fairly simple actually - removing digression from the mix and also removing things we've completed from the meeting.
There are no side conversations while stuff is being covered, and every day we sum up what we did in a company-wide email. Other subjects happen offline between relevant parties. This has been remarkably effective for us :)
Both articles lack context, which we're all just filling in with our personal experiences with standup meetings, hence the pointless "debate" in the comments here.
I've noticed that developers can be divided into two groups based on whether they prefer to work with others or by themselves.
Those that prefer to work by themselves take chunks of work that can be done without input (formal or informal) from their fellow developers, (who they may refer to as "teammates" despite the fact that they don't work as a team in any real sense.) For this group, having a daily standup is a waste of time, because there is no work to coordinate.
Those that prefer to work with others take chunks of work that can't be considered complete until their fellow developers have also completed their portions. They seek continual input from their teammates in order to keep everyone on the same page. For this group the daily standup is just a more formal version of what they already do informally.
Offtopic - Hate these "github.com" posts that are actually from some blog hosted by some random dude on Github. Makes the domain bit meaningless. Wasn't there some fix for this to show more of the domain in certain cases?
When I first started doing standups, mine were longer than necessary. But as I got more comfortable and the team's workflow jelled, I've gotten better at being concise.
At my current job at turntable.fm, we only have standups twice a week (Tuesday and Thursday), and I honestly was surprised at how effective that is. I've always operated under the assumption that a standup needs to happen daily to be valuable, but trying them 2x weekly has changed my mind.
I think the real problem is when a standup is the only way that a team actually communicates status. At turntable we rely heavily on chat, which also contains messages indicating when new things are being pushed, and we also make it a point to have a lot of face-to-face communication. Our twice-weekly standups are a good way to fill in the gaps, if there are any, but they are by no means the only way that people find out what's going on.
And this is a very good example on what Agile is about. The daily stand ups are part of the basic "framework" but not mandatory if something else works better for a team. The key is to constantly inspect how the process is working and be open, as a team, to make adjustments.
Standups work really well when there are dependencies between different functional groups.
Consider a team working on a live browser/Facebook-based free to play game (social game as a service). There are many releases a week.
- Engineering typically requires art assets to begin/complete work. Ie. building models, unit models, 2D unit images, item images, etc.
- Releases don't end when they are pushed up to prod -- most releases have some kind of "go to market" plan that must be executed. For example, if a new Dragon Armor is released, we need to message all players to inform them of the new functionality and educate them on how it works, there would typically be a simultaneous tournament or contest that awards the new Armor as a prize, and possibly some other sale or promotion on a related item.
- It's a time for product to provide updates on where different specs are and on key game metrics.
- Customer Support/Community Management also provide updates on any emerging issues in the game, which improves everyone's situational awareness.
IMO Standups are very useful for a team that works remotely. Placing them in the middle of the day ensures that nobody's going to have to bend his or her schedule unreasonably.
Would you rather get at least one extra IM or phone call(?) from each member of the team randomly throughout the day as you're quietly and productively working in your own zone?
I'm all for anything that tends to eliminate mental context switching during the day. Needless to say, not a fan of any office environment for coders.
I'm a developer and not really a fan of standups, I find them monotonous and dull and often "zone out" after I've said my bit, but I can see how they are useful to management.
The problem with standups at the company I work for is our team work on multiple projects so standups end up being just "I'm working on project X and it's going well, no blockers, cheers!" updates from everyone in the circle.
Standups are probably better for teams working on a single product as everyone has a stake in what's going on
124 comments
[ 1.9 ms ] story [ 143 ms ] threadAdditionally, I think it is important to remember that standup is not a "justify my existence on the team" meeting. Having nothing to report is fine.
Conversely, this particular dysfunction of standups is a useful index of how much the corporate culture leads people to feel like they must justify their existence.
Off the top of my head, I'd look at the size of the unit of work and the length of the release cycle. I think Agile processes work best when the work is broken down into lots of small deliverables that meet the INVEST criteria:
http://en.wikipedia.org/wiki/INVEST_%28mnemonic%29
If the team is jointly completing a few shippable things a day, then everybody should have a pretty good idea that everybody else is working. Doubly so if those are actually getting released daily.
In a meeting where you're supposed to say what you've been working on, at a job where you're paid to be working on it, in what way is it fine to have nothing to report?
That said, in a quality team staffed with quality people, you don't worry about people goofing off during the time they're blocked... you assume they are doing some kind of self-development, or tweaking some small detail somewhere, etc. It's when somebody is blocked for long enough that it puts their tasks in jeopardy that the scrummaster needs to start escalating things and working to get the roadblocks removed, and/or manage expectations vis-a-vis the tasks for the iteration.
I learned one of the Agile methods before the term Agile was even invented. Adopting it made a giant difference in the quality and sanity of my work.
But so many people today have have pseudo-Agile methods inflicted on them in large corporate contexts. There, the point isn't to make things saner and more effective. It's to please some executive who has a bee in their bonnet. And often, they only adopt some labels and some rituals. It's all pain, no gain.
I wrote about how this happened here: http://agilefocus.com/2011/02/21/agiles-second-chasm-and-how...
But it's at the point where I avoid using the term "Agile". Or any other buzzword. I look at the circumstances, and say, "Hey, you guys feel pain X. Can we try change Y and see if that helps?" Often, the tool is one from the Agile or Lean toolbox. But I won't talk about the particular process I'm borrowing from because a) most people don't care, and b) a lot of people have been burned with faux-Agile adoptions.
I believe the bulk of what people call "Agile" these days is terrible. You could say that most of that isn't the true Agile. But at some point I think that isn't a battle worth fighting. Personally, I just say that Agile started out as X and has become Y.
I would rather they didn't throw the baby out with their bathwater, but in the stories I have heard, the vitriol is entirely valid. I don't think it should be all directed at "Agile", in that managers deserve a lot, as do the hierarchical power structures in which the managers work. But the Agile people also made choices that led to this outcome, so I think it's fair that there's some spleen-venting directly at the Agile movement.
Consider the standup to be the canary in the coalmine. Most of the time people can ignore the dysfunction, work around it and pretend it isn't happening by just getting on with the job as much as possible.
But the standup will then become increasingly uncomfortable. Every single day.
In a healthy organisation, you can have perfectly pleasant standups, even without Scrum or Agile. I mean, what does a healthy team have to fear from standing around for a few minutes bringing each other up to speed?
It's a process that is very close to what often happens quite naturally around the time everyone on the team has arrived at the office (or online).
A standup can only become poisonous if the poison is injected from elsewhere. In Gareth's case abusing it for management status reports. In other cases it might be tension between team members, not having a clear goal, whatever.
The point is, you cannot have pleasant standup if there is that kind of stuff going on. Which is all the more reason to have a standup, unless it's your policy to ignore problems rather than dealing with them.
Standups aren't just not poisonous either: they are a very good poison detector.
This is exactly the behavior I have seen of well functioning teams. Usually there is a period when the person comes in, maybe after coming up to speed on their email where they get informed and up to speed on what is happening with everyone, if anyone needs anything, what people are working on, and then get to work!
Standups are just a formalized approach to what can be a drawn out process for an individual, and in some cases may not be "normal" for your standard introvert dev types who sit at a computer all day and perceive meetings as multi-hour long chores that are inflicted on their participants instead of quick high quality bursts of information distributed in an efficient fashion (face to face).
If you're doing Scrum, the only issues you should really be bringing to standups are those you can't solve within the team that you need the Scrum Master to sort out. Anything the team can fix for itself isn't blocking, it's business as usual.
Some places don't manage standups well at all, and that is one of the big problems with standups in general - they become status meetings and take too long. When done right, they are very useful as you quickly know what everyone is working on and if someone might need your insights on something (which should then be a separate meeting and not covered in the standup).
There are a few main features of standups that, if abused or ignored, can lead to awfulness.
- They're supposed to be short, very short. A few minutes at the most. They do not work for large teams (20 people giving a status update is a lot), and if you find yourself having 20-person standups it's time to think about if you should be breaking them into multiple independent standups.
- Managers aren't present, or aren't allowed to speak. This is an opportunity to ask questions, ask for help, describe what you're working on, to other members of your team, not to justify what you were up to yesterday to your boss. It's sharing, not reporting. This part is key.
- You don't troubleshoot in a standup. If you say "I can't figure out why I can't Foo module Baz", there shouldn't be a discussion about it, but someone else might go "I've worked with Baz a lot, let's take a look together after standup.", or later in the day someone might go "Oh hey, that problem you were having with Baz? I think I know what's happening." - this is the ideal intent of standups. Very quick snippets that highlight certain things in everyone's minds.
- It doesn't need to be documented. It's not a meeting, you don't need to take down minutes. Actual tracking of work done occurs separately (your scrum master should be doing this).
From the article:
- Make sure everyone is working on the right thing
- Help out other team members by taking work off their plate or helping them by sharing domain-specific knowledge
- Keeping everyone informed
How is that different from a status meeting? I've heard "standups are not status meetings" over and over from the agile community, but I don't get it. They sure seem to be quick status meetings that allow everyone to get a handle on the current status of the iteration?
The only difference between standups and status meeting is that you're not there to fill a report card. You're not there to show your manager you did something. You're just there because it's the only 10 minutes in the whole day where the whole team comes together to discuss. It's (at least in my place of work) highly informal, very chilled and very genuine. What we do is say what we're working on and ask for help and/or ideas.
We have a private IRC channel for this, but the fact that we meet face to face for 10 mins a day really does bring up interesting fast conversations.
The whole point of standups is not to take notes, not to keep track and just have a quick break to talk (not type) about work.
Status meetings are for the benefit of a manager. They allow everybody to report to the manager so the manager can feel comfortably informed. These are typically useless to everybody else because they drag on for far longer and nobody pays attention whilst each individual briefs that manager. These sorts of meetings are detrimental to getting a team to self organise.
I also feel like the original "Standups are Poisonous" author may work in such an environment also.
I once worked for a company (who shall remain nameless) where the development process could be generously described as a perversion of agile. They wanted the cool buzzwordy notion of agile, but didn't want to actually subscribe to an egalitarian, hands-off environment where the engineering process is largely self-managed.
So, manager as scrum-master (noooooooooo), manager present at standup (noooooooo), and worst of all, story points becoming a measure of productivity (noooooooooo!). Standups would routinely last half an hour, even though our team was literally 4 people large, because the scrum master/manager would stop someone and drill down constantly.
Oh, and the manager ran estimation too, and with pressure from above would blatantly try to influence estimates downwards. The rest of the team compensated by inflating small tasks. Yay.
Tasks would also get assigned to specific team members from the get-go, because the team was horrifyingly silo'ed and we were constantly "too busy" to cross-train by spreading tasks around. I find that silo'ing is by far the biggest thing that makes standups seems irrelevant - why listen to what that guy is doing if that task has no bearing whatsoever on anything you're working on, or will be working on?
You see these a lot in cargo-cult style adoptions. They understand that they need to do these practices, but they don't understand why. The end result is that they try to pervert them to serve their own purposes (e.g. daily stand-up as a status meeting for managers) and lose the real value. Then they complain that "Agile doesn't work here".
To me a standup is a tool to keep the team fully gelled and jump on any issues which will cause a sprint to spiral out of control. They should only last a few minutes per person (we have about ten people) and we schedule coffee immediately following to tackle any issues that were tabled due to a timebox.
Note: We have a 'coffee club' where everyone brings in coffee and we french press it every morning. So its scheduled only so that nobody pulls us into meetings ;). We love our coffee.
I think standups could work, but they should only focus on things that impact the project (breaking change to an interface, or significant new things that are available) or things that are blocking work. And honestly I think email does a better job at that with a lot less impact on flow.
E.g., Your stand-up is from 9-930a. After which you can't start anything substantial because 'lunch is coming,' but that's 2.5 hours away (assuming you lunch at noon).
I like morning stand-ups, but a big problem is that if the stand-up is at 9, I start winding down whatever I'm doing around 8:30, and I don't start new tasks after 8-8:30. Multiply the loss by the entire team every day and that's potentially a big loss of time. And because everyone's schedule is different, there's really no place to put the meeting that avoids the problem.
The benefits of a well-run standup can outweight this productivity cost, but it's a real cost that needs to be considered.
I guess this does presume that everyone wraps up at about the same time every day, which I've generally found to be the case, but may not work well with widely distributed workers or places where people actually practice a wider range of work hours.
Team members report on what they did that day, but seldom think about the things they are going to get done next and the things that are preventing them from getting started on the next thing, which in my opinion, are the more important things to focus on.
We had a huge problem with non-delivery people scheduling meetings willy-nilly, just because people's calendar's were free.
I've put the kibosh on that, as much as possible, especially in the afternoon.
It actually has worked really well in preventing of siloing/cliquing of work effort. Another thing that has helped greatly is using a physical task board and organizing conversation by task instead of by person. This puts less emphasis on "looking useful" as individuals and more on championing tasks to see their completion.
This is a very good approach. Separating task and people is key to getting things done. When things are getting tough for an individual, the team can rally behind.
Also, who are people talking to if not the rest of the team? Why are they saying things that other team members don't care about?
I would strongly prefer to have a stream of commits and JIRA issues in HipChat to review the following morning than have to do a standup. But not all engineers are as good as they like to believe they are at following development workflows and processes.
The purpose of the meeting is for the team to get together and co-ordinate the work that needs to be done in order to meet their Sprint goals. So while you may be able to get status information out of that, it's more important for team members to use that time to figure out how to meet their goals.
In addition, status should be obvious in Agile teams. This is why you usually see things like cards on walls and burn down charts. If status isn't obvious to everyone, you may want to see if there are other ways the team can make that information highly visible.
Check out: https://www.udemy.com/improv-your-agile-scrum-stand-up/?coup... for more.
I definitely agree with this. Standups/scrums have become much more productive since management stopped attending. It's hardly a "status" meeting any more -- sure, we talk about what we're working on, but there's a lot of jumping in by other team members with suggestions, help, or "I was going to do something similar, let's coordinate after the meeting".
Edit: wrong, not right.
Another wrong way is to take a long time. It's a quick meeting, where everybody syncs up for the day and major issues are raised. I think of it as like the way players will quickly huddle together on a sports field. It should be high energy, biased toward finishing, and tabling any significant discussions for later.
As far as I'm concerned, they only make sense in a team environment. Where people are jointly working on shared goals and extensively support one another. In the Extreme Programming approach, they go along with a team work queue and collective code ownership.
If people, say, have individual work queues parceled out by a boss and don't interact much, then as far as I'm concerned the stand-up meeting is the wrong tool.
I was there because the money was good. Motivationally it was about as effective as being micro-managed on a waterfall project.
I find it supremely useful - it builds self-understanding in the team and a sense of actual teamwork, even camaraderie, improves visibility of what everyone is doing (and where you may be able to help - we often chip in when someone says they are stuck to say "yeah I know a bit about that, let's chat about it after stand up") without feeling like surveillance. You also get to know if there are going to be any demand on your time for discussion (say of upcoming work) from our line manager. It is not a status meeting. Both the theory and our lived practice make it a synchronisation meeting that defines the heartbeat of the sprint process. Its actually a comfort to know if you are stuck you can say so in the stand up and people are aware you are having difficulty.
If you are doing scrum right then status meetings should be unnecessary during a sprint. The interaction between the team and the product owner (co-ordinated by the scrum master to prevent the product owner becoming noise) should be sufficiently smooth that when you get to the demo at the end of the sprint nothing should be a surprise to the product owner (they are part of the team after all) but should be for consolidation and display to wider stakeholders. We use e-mail and GitHub issues to keep the product owner in the loop at all times (increasingly moving to just GitHub) and HipChat for status throughout the day. As for "higher level" status meetings, our line manager has no need for this from us because she is much closer to the work through the stand up and our scrum master will handle these duties as required so we can get our heads down in the sprint. Status meeting for more senior management are the job of the line manager, who also plays a role in just letting the team get on with development. Status meetings as people seem to be describing them here seem to be the kind of productivity killing time sinks that the scrum process defines as "noise" and attempts to use the scrum master to keep as far away from the team as possible.
(PS I work in IS Web Development University of Kent where we take agile process in our team very serously - we'll shortly be hiring ;-) )
"Wednesday, 24 April Fixed bug #434, added protocols between user and tasks. "
And if they _really_ want to know what I am going to work on or what issues I have. Please check my tracker. There are bugs, features and chores. And each of them has comments that describe any issues I might have run into or will.
Problem solved.
If you are fixing bugs then the story should be "x bugs related to foo feature" and your daily standup report should be "I fixed x bugs on foo, I have y to go, should be done today, no blockers"
Agile in not optimal for maintenance or emergency production issues. These are dealt immediately and only mention in the daily stand up as a blocker stopping you from finish the task you actually intended to complete. They are not even added to the product/sprint backlogs.
As a rule of thumb all user stories added to a sprint should take between half and 2 days to complete. If you have a whole bunch of small bug fixes, group them together so they fit in that time-frame (i.e. all UI bugs in page foo). Otherwise you end up polluting the backlog with hundredths of little things and turning your planning meetings into overwhelming nightmares.
Just think about it: if everybody in the team is working on only one or two tasks every day, the daily stand up will take each member about 30 seconds and the whole meeting less than 5.
standup = log --graph --decorate --oneline --author="YOURNAMEHERE" --since="yesterday"
If the meeting takes longer than it's supposed to, walk out or hang up.
If someone is rambling on about something that isn't going to help the team move forward, say something.
Standups will not fix a bad team, or a bad manager.
While yes, you may be able to derive status from a daily stand-up meeting, that's not the point.
The point is for the team to co-ordinate their work and figure out how they're going to get things done. Done well, it has more in common with a planning meeting than a status meeting.
I actually have a whole course on how to have good stand-up meetings.
Here's the link: https://www.udemy.com/improv-your-agile-scrum-stand-up/?coup... I added a discount code for anyone who's interested.
Good luck with your course.
Sure you do, at a very high level. "Milo is doing the SYNAPSE adapters, Stinky is working on the compression drivers, Lisa is doing the UI stuff and Teddy is fixing the build system."
That can be covered in 10 minutes, and then the individuals involved can (and should) go off and hold whatever independent meetings - if any - are required for their specific tasks.
On top of that if you really want the tool to show everything everyone is blocked on at any time, you wind up spending a lot more time than strictly necessary just typing status updates.
In my team's standups, people frequently wind up shifting plans to cover issues that are brought up or offering work arounds to mitigate blocking issues and kick them down the road a bit to give the scrum master(who is also our VP) time to clear them. We also wind up frequently offering to pair with different people based on what they're working on(i.e. one dev is working on something that touches part of our system that's particularly fragile, another dev more familiar with that area will offer to pair for the morning).
Since we started doing morning standups I've seen our team get more productive.
https://www.quora.com/Startups/Which-is-the-best-To-Do-List-...
The average card had maybe 4 words on it. We knew about issues because we talked about them.
I love the written word, but it is so much slower and less efficient than face-to-face communication in so many circumstances. The highest-bandwidth, lowest-latency human communication system is conversation.
Also: training/coaching wouldn't hurt..
1) not correctly identifying "chickens" and "pigs"[1]. Pigs get to talk in a standup, chickens do not. In fact any interaction with the pigs and chickens should go entirely through the scrum master (and not during the standup). If chickens want to come to the standup it is to observe only.
2) conversations. The standup is not the time for conversation. The best method I've employed is to have each person specifically answer three questions: what did you do since the last standup? What are you going to do between now and the next one? Are you impeded in any way? The last one is where conversations often start. Scrum master needs to stop those, identify the people who need to talk after the stand up, and move things along.
When you follow those as hard fast rules, standups shouldn't take more than N*3 minutes where N is the number of pigs.
[1] http://en.m.wikipedia.org/wiki/The_Chicken_and_the_Pig
For a while I worked on a team with a small codebase, which we all knew pretty well, and it was very likely that if somebody made a change today, I'd be working in the same area of code in the next day or two.
In that situation I thought standups were really helpful.
My current team/project is a bit larger and it's maintenance on a much, much larger code base. The project is large enough that nobody really knows the whole thing very well, and everybody works on a different section and there's not much overlap. If I were to switch places with somebody I'd have a lot more to learn than just what they've worked on recently.
On this project we're still required to do standups, but they're useless. The information wouldn't be very useful to me even if people kept to one or two sentences of what they were doing. Of course, few people do that, and they usually go into obscure details that maybe two people in the whole group really understand. And that's when I tune out...
Every morning we have our meeting which maxes out at 15 minutes. The designated note-taker rotates daily and takes the list of current action items to be added to RedMine.
The biggest difficulty was fairly simple actually - removing digression from the mix and also removing things we've completed from the meeting.
There are no side conversations while stuff is being covered, and every day we sum up what we did in a company-wide email. Other subjects happen offline between relevant parties. This has been remarkably effective for us :)
I've noticed that developers can be divided into two groups based on whether they prefer to work with others or by themselves.
Those that prefer to work by themselves take chunks of work that can be done without input (formal or informal) from their fellow developers, (who they may refer to as "teammates" despite the fact that they don't work as a team in any real sense.) For this group, having a daily standup is a waste of time, because there is no work to coordinate.
Those that prefer to work with others take chunks of work that can't be considered complete until their fellow developers have also completed their portions. They seek continual input from their teammates in order to keep everyone on the same page. For this group the daily standup is just a more formal version of what they already do informally.
Bookmarklet: https://github.com/johngibb/Hacker-News--Show-Subdomains
Edit: Haven't tried them myself; just did an hnsearch. It would be great if Hacker News would always show the subdomain if not www.
https://www.blossom.io/blog/2012/09/17/3-tips-for-quick-effe...
If done well they can be a great facilitator. Just make sure it fits your culture.
I think the real problem is when a standup is the only way that a team actually communicates status. At turntable we rely heavily on chat, which also contains messages indicating when new things are being pushed, and we also make it a point to have a lot of face-to-face communication. Our twice-weekly standups are a good way to fill in the gaps, if there are any, but they are by no means the only way that people find out what's going on.
Consider a team working on a live browser/Facebook-based free to play game (social game as a service). There are many releases a week.
- Engineering typically requires art assets to begin/complete work. Ie. building models, unit models, 2D unit images, item images, etc.
- Releases don't end when they are pushed up to prod -- most releases have some kind of "go to market" plan that must be executed. For example, if a new Dragon Armor is released, we need to message all players to inform them of the new functionality and educate them on how it works, there would typically be a simultaneous tournament or contest that awards the new Armor as a prize, and possibly some other sale or promotion on a related item.
- It's a time for product to provide updates on where different specs are and on key game metrics.
- Customer Support/Community Management also provide updates on any emerging issues in the game, which improves everyone's situational awareness.
Would you rather get at least one extra IM or phone call(?) from each member of the team randomly throughout the day as you're quietly and productively working in your own zone?
I'm all for anything that tends to eliminate mental context switching during the day. Needless to say, not a fan of any office environment for coders.
The problem with standups at the company I work for is our team work on multiple projects so standups end up being just "I'm working on project X and it's going well, no blockers, cheers!" updates from everyone in the circle.
Standups are probably better for teams working on a single product as everyone has a stake in what's going on