The daily stand-up is an anti-pattern
kristopherwilson.com
kristopherwilson.com
Specifically, if you have a team that doesn't communicate effectively on a daily basis, then the standup gives you -- the manager -- a place where you can get and keep your developers on the same page.
When everybody already knows what's going on, then the standup loses a lot of its meaning, and should get cut down to "Anybody blocked, or need anything they don't have? Everybody good to go today? Okay, let's make this happen."
But at a lot of companies, it goes the other way, turning into a Kafkaesque version of Show and Tell.
Most people that end up in technical management don't get any serious coaching on leadership or management. This leads to a lot of management-by-bestseller, cargo-cult agile, and the sort of dystopian teams that grind the minds of otherwise talented developers into useless pulp.
It's not that these managers are incompetent or bad-intentioned, just that they never got any solid guidance on how to lead, manage, and grow a team.
What's truly insidious is that the problems don't really start becoming catastrophic for months or years, by which time it's very, very difficult to turn the ship around.
One of the more powerful tools for fighting this sort of problem is the retrospective -- a weekly block of time where the team goes over what works and what doesn't -- but, more often than not, the retro is the first thing that gets cut from the process because "nobody has time."
The standup should not include the manager as a participant; that's broken. The standup is supposed to be for coordination among the team, not status reporting to the manager.
Most of the time, the manager is partly responsible for solving the "blocked" and "things needed to do this task" issues that come up so it's better to have them there then not. If the whole point of a stand-up is to have all the team members forced into a quick acknowledgement, leaving someone out doesn't seem to help.
Overall, I do as much coding/development as anyone else on the team. However, I also identify problems that others on team may not see until they become serious. I also look for ways to make the team more efficient through automation of the more tedious/repetitive aspects of the development process and implement a solution when I have downtime.
For example, we have a lot of network/hardware integrations we support and each one requires reconfiguring a database and reloading a couple services. This reconfiguring was being done manually much of the time through the web interface so I tracked down the rows being changed in the db by doing db diffs on each configuration and scripting out the changes that might be different on each developer's machine. Instead of manual config, developers just put a few custom constants in a json file, run the script and select the configuration they want to load from a script. That then updates the test db and they can be running/debugging their code in less than a minute instead of up to 10-15 at times (plus time lost from losing focus/train of thought). I know my example is nothing amazing really, but with some developers having to test a couple configurations a day, that time adds up without realizing it. The db schema rarely changes nowadays (maybe once a major version), but if it does, I just have to add a column perhaps at the most to the script and have them run it again after they update their build.
I sell the daily standup to the developers as a tradeoff: we do a quick daily meeting in exchange for keeping stakeholders off your backs the rest of the day/iteration.
EDIT: phrasing
You're right; a better phrasing would be that the manager is not an active participant in the meeting. It's a developer coordination meeting, not a status reporting meeting. So the manager is welcome to listen in, but they're not supposed to be managing during that meeting, and in particular they should not be asking questions, because that'll very quickly turn the standup into a daily status report instead.
Absolutely no experience, so this may be stupid.
Has anybody tried to replace this with a "daily shared morning tea/coffee"? Create a collegial atmosphere that's intrinsically unsuited to active management; there's no real need to keep people ontopic anyways because they'll naturally talk about work. Plus drinks may keep people occupied enough that only one person would naturally talk.
[edit] Oh, is that what the watercooler does!
But by all means try it out; if it works for your team, great!
It's a lot easier to be collegiate in a college.
One of the main goals of Agile processes is to remove overhead from the developer so they can focus on adding value to the stakeholder. Anybody who starts goofing around the standup is disrespecting and wasting the team's time.
Now, your idea might be worth a try. As I said in another post: the team runs itself and might decide to try something like you propose... and keep doing it if it works for them.
I prefer to have wash up meetings at the end of the day so you do not waste time in the morning hanging about for people to turn up
Many of my best stand ups go like
Mary: "Nothing to report."
Jon: "Nothing to report."
Dyneshwari: "Nothing to report."
Shruthi: "Nothing to report."
Su: "Nothing to report."
Grant: "Oh, we moved all the test databases. You need to get the latest base data in your environment or you won't be able to work."
Joe: "Nothing to report."
It's over in 1 minute.
Mary: I fixed the missing-messages bug, and I'm about to refactor the protocol to support faster logins.
Jon: We should talk afterwards, I'm also touching the protocol to edit the login screen.
Dyneshwari: I did an unrelated UI change that doesn't interfere with anyone.
Shruthi: I just started laying the groundwork for ads in the stream.
Manager: We should talk afterwards, legal has a bunch of new requirements on the format of ads.
Su: Nothing to report.
Grant: Oh, we moved all the test databases. You need to get the latest base data in your environment or you won't be able to work.
Joe: Jon, loop me in when you talk to Mary, I just had to change the protocol for UI widget X and I've got some tips for working with it.
Not quite 1 minute, but it could save several hours of work when Mary, Jon, and Joe coordinate and make sure they aren't stomping on each others' toes, and their little mini-meeting probably won't take more than 20 minutes.
I feel that the article is attacking a strawman, or perhaps it is a no true Scotsman where the objections are all or mostly about standups that aren't working rather than about the idea of a short "Let's just make sure we are all on the same page" session.
And here you have your real problem.
You're applying an office-tool (the board) to a team that is not sharing an office.
What works much better for distributed teams is to treat them like OSS projects.
Do you know any OSS project that uses a "board", or stand up meetings?
They use the issue-tracker, pull-requests and chat instead.
Blog I haven't seen tried, but I imagine it would hit the same problems; either you notify everyone and have the same problems as slack, or you don't and have a big risk of someone missing an update.
This has an amusing side effect: For some reason, even if I attend the stand-up after all, nobody debates my completed tasks with the big green check marks. So I now do this before every stand-up.
I guess we are drilling down to the similarly fundamental yet pointless truth about communication: it's easy when it is working well.
+1. A "manager" can't replace a "team". And having a "team" is one of the key aspects of being agile(this is what "peope and interactions" is about).
I concur. My people don't communicate very well and have no real team spirit. The stand up meeting helps to alleaviate that.
Of course, people who "don't communicate" and "have no real team spirit" are not fit for Agile and stuff, but that's another story :-) In my case, Agile, having frequent deadlines and frequent stand up meeting, helps me a lot to maintain a soft pressure on people. I don't like that (I'd prefer a team of super motivated people), but that's the best I can do. Having a more formal method like RUP wouldn't help because the analysis/coding cycles are too long. Having a kanban could help a bit, as Agile with such a team feels a bit artificial.
"My people" are all terrible and need "soft pressure" to succeed....
I've done agile agile (the process being agile) before which worked great. 3 week planning with one to three tasks per week and weekly sync, no detailed estimates. This was pleasant, I felt trusted, empowered and as a result more committed.
Right now I'm doing the full cargo cult Agile, with daily standup, sprint planning, backlog grooming, sprint retrospectives, end of sprint demos. I get regularly dinged for not following the process, never mind if the work is actually done. Also there is 5 manager/pm at our standup, for 6 engineers. I don't know for you but this kind of stuff makes me completely indolent, before I start searching for something new.
> Also there is 5 manager/pm at our standup
These statements cannot both be true. Those 5 managers are violating the "process".
Only if they speak
Also one of the "managers" (that's his title), manages no one.
He's a scrum master of sorts, who goes around interrupting people programming to remind them to move their tasks to "in progress" or to "closed". I assume so our burndown chart moves down. I've been tempted to replace this guy with a script.
We all know what the other member of the team works on, so the standup is clearly not for us but for a minute update to all the managers who are sitting in on several "standups" in a row.
If you read my comments, it's not really the standup itself that I complain about. It's disguised micro management with an Agile shell.
Since teams are supposed to be self organized and the process itself should be agile, you could ask the member of the team to comment on the process and if they think the standup help them.
We don't make huge use of it, since we've only got about four developers, so communication is pretty easy, but it can be helpful.
It also can be helpful months later when needing a reminder why something was changed based on an assumed unimportant detail at the time.
No amount of sprint planning, backlog grooming[1], or sock-monkeys flying across the room during a standup can make up for a lack of leadership.
In your current situation, I would wager that -- early on -- the development team committed to a lot of deliverables and then failed to deliver, either due to overconfidence, or pressure from an overeager management team. Afterwards, an Agile Process was installed to ensure that This Sort Of Thing Never Happens Again.
The end result is what I like to call Agile Bondage, where everybody focuses on the process, rather than the product or the customer.
[1] Backlog grooming, with the entire team, is generally an antipattern. You do not need the entire team to grind to a halt to make sure the stories in the backlog are actionable. Have the product owner grab a pair after the standup to review upcoming stories to make sure that things look kosher for the rest of the team.
Teams need to be tight and involved with eachother, otherwise the standup makes no sense.
What makes this a little difficult is that Scrum™ insists on cross-functional teams, i.e. all teams have a UI guy, a backend developer, a tester, etc. So you can end up with some very disjointed teams, like the one mainframe dude who works on stuff no one understands or cares about. Yet you have to hear about it every. morning.
(It didn't work, and then I left. In my experience you can't change places with that kind of process. I'd love to hear from anyone who's succeeded)
People also assume Agile means you'll do more faster - I don't think this is always the case. Quality generally is better but again not because of the process but because of the team. A team in full flow and working really well together needs no process.
The biggest benefit for me is that if the team is given accountability then there is total transparency about what the team is doing. Organisations tend to add additional layers of management to supposedly shield the team from politics - but it's the additional layer of management that actually creates the politics.
Even the phrase "agile methodology" is wrong.
So we decided to went with textual async standups on dedicated slack channel.
Example: "Yesterday I finished the “fix the price calculator” feature, which was mostly about removing the Coffee code and rely on the value retrieved from the backend, via ajax. The nice thing was that the backend code was already covered with tests, while the Coffee one wasn’t. After that I helped Jack with the “allow logging in with email” feature (we need it now because we have a batch import of users from system X soon). After that I did a small ticket, where I block buying licences for special periods of time. This was nicely TDD'ed, thanks to the concept of aggregate, introduced by Robert recently - all the tests pass < 1s. Here is a commit worth looking at. Today I’m going to start with foreman'ing the recent commits and after that I want to work the XYZ system to allow a better editing of entries. I’m not sure how to start it, so all help is welcome"
Blogpost where we describe this technique: http://blog.arkency.com/2014/06/async-standups/ and list of them where we explain the async&remote approach: https://blog.arkency.com/story/async-and-remote/
Daily standups have never been beneficial. I see people here talking about managers not talking during standup. I've never seen that once in the past 10 years that "SCRUM" has been the buzzword. NOT ONCE. I've never seen standups that were only 15 miutes. After being forced to stand for 20-40 minutes each day listening to an air headed project manager drone on during the Standups at Amazon, I vowed I'd had enough. I got tired of having my time wasted and made a rule that if I can't sit down during a meeting, I'm not attending. If you think I'm rambling in the meeting, then you can make me stand up, but I'm never the problem (always the "product manager" or "biz guy" is the problem. Talking seems to be what they think is the purpose of their job.)
It's gotten to the point where I associate the word "scrum" in job postings as a red flag.
Teams should work asynchronously, all the time. Git lets us code async. Slack and Hipchat let us chat async. Whenever we need to coordinate, we just talk. (which is why you need offices so your talking doesn't bother other people.) Otherwise, everything should be async.
A standup is a big old pointless nose-counting exercise. It feels like it comes from the 1950s.
And if you're having a daily standup at 10am, then that means I can't start work at noon, can I? So, where is this "flex hours" that everyone thought was such a good perk 10 years ago?
I've been a PM, TA and developer - I would be fairly ruthless with timing.
Agile might make it easier for incompetent people to screw things up, I suppose. And therefore it might be best to avoid in teams where the problem is deeper than the team organization.
In my industry, the big problem is people trying to use agile to deliver fixed cost, fixed feature, fixed time projects. They'll often be doing this as part of a large organisation also working to those targets. If you want to deliver a project like that, you need to control change to requirements, and push the costs from change either into a cost bucket you can track, or back onto the customer. Because Agile encourages flexibility, other teams teams working on waterfall push changes towards the Agile team. If the interface between them needs unforeseen changes, or some extra business logic turns out to need to go somewhere guess who's implementing it. The axe falls on the project manager at the end.
I don't think scrum is right if - you don't have direct contact with users (i.e. a feedback loop), you don't have the capacity to change your product and drop features as you go.
It's worth agreeing, in that kind of organisation, the scrum will be happening at 10am, like you say.
Agile isn't a set of processes, it's a set of principals.
I completely agree that it's become a terrible cargo cult in many shops, easily as heavy as RUP.
Ymmv.
I've heard it explained that the scrum thing was a way to start the journey. If you are in developer chaos, or utterly bogged down in useless process (some processes are good), then this will get you on the road. But we have better tools these days. Use them. Remember what your goals are. Scrum is not the goal. Delivering/testing the product or feature is (for example). If scrum is a strategy that gets you there in a better way, great. If you have a better way, use that instead.
Two week sprints are probably better than 3 year development cycles for most things (airplanes and nuclear reactors require a lot of planning, sorry). But it is artificial. Any complex project will have many different components, and all of them are going to have a different, natural cadence. This core infrastructure requires careful planning and build out. That UI element needs to be slapped together for an A/B test. This "like" fits great into the next 2 weeks. This device driver has to be syncronized with the prototype hardware delivery being made by your partner. And so on. Almost none of that fits into a 'finished product every two weeks, never stop or change once you start".
If scrum works for you, great, but please don't cargo cult it, or think it is the end instead of the beginning.
Useless but fun anecdote: I was reading some glassdoor reviews yesterday if a nearby compay. It was being excoriated by every employee review. The CEO responds with 'we are Agile now, so come work for us. All the whiners quit" (quote marks imply paraphrase, not direct quote) .Ya. No thanks.
It's like saying 'burgers taste bad'. If your burger tastes bad, then maybe you're making it wrong.
It's almost a tautology: "My time machine doesn't work." "Well, maybe you didn't build your time machine right!"
What do the effective teams you've worked with do differently and better than the author's? How do they avoid the pitfalls, or why are the problems not problems that the author outlines in "three general arguments" against it? What kind of variation in teams should the author account for?
We let them choose the time of the day for the daily stand-up. One team agreed on 11am. Another on 5pm. Some people see this 15 minute stand-up serves as a major interruption. I see it as a way to consolidate some of the tiny interruptions throughout the day into one.
Also teams have individuals of varying experience so we consider the stories to be a team goal. This makes the more experienced individual more willing to help those still learning since they are no longer making a trade-off for their own stories vs somebody else.
Lastly, I've worked on projects from 1-20 people and beyond a certain size, daily meetings are just mandatory or things fall apart. In a previous project, I ran these big daily status meetings and they tended to run long. Everyone hated it so I dropped it for a few days but then the code started breaking due to lack of communications. We decided to split the meeting into smaller groups and they ran quicker and there were less complaints. However we were still able to keep the code quality.
But I think the most important things is "one size doesn't fit all." If something is not working, have an open discussion within the team and suggest some alternatives. If there is no avenue to give feedback, that is the fundamental problem.
Small anecdote about choosing stand-up time: We previously had stand-up at 9:15am, but management wasn't happy that we would all immediately after go for coffee (taking around 10-20 minutes). So standups were moved to 9:45 on the condition that we would get coffee 'before work'. Instead what happened was that people wouldn't get into work until 9:43am and everyone still went for coffee after standup.
Interesting language. "We let them" sets of an alarm for me. Why do they need to be allowed to the choose time of day? Are they not self-organizing? Or is this organization still in the midst of transformation?
In an Extreme Programming team provide a good opportunity to swap around pair-programming partners.
It's also a good opportunity to decide how many tasks the team has capacity to take on today, which isn't entirely straightforward. There may be someone off sick which means we can run fewer pairs. There might be an urgent production issue from overnight which requires a pair's attention. It might be that one of the next tasks needs some research and doesn't warrant a pair. It might be that one of the next tasks is a bit challenging/contentious and could benefit from mob-programming[0].
They are also useful to update team members who have been away or stuck in meetings, and for them to update the rest of the team. Not everyone can be in all conversations all the time.
As with most agile practices the mantra of "If it hurts, do it more often" applies well to standups. Synchronization is useful when working in this way but it shouldn't need to be long and painful. Having multiple focused sub-5 minute standups is better than one that drags on.
e.g. break along functional lines. Limit morning chat to what are we doing today, who is working with whom?. Have separate sessions for updates on progress, discussing impediments, or product planning updates.
Informal "huddles" work quite well too. Convene everyone ad-hoc when there's a decision to be made or as soon as an impediment arises.
When mob-programming most of the reasons for standups disappear. The whole team stays synchronized all the time.
There's the implicit motivation in saying "I got this done!" for the first part, even if it is a review. There's an opportunity to prompt offline discussions when you talk about what you're going to address today.
With regards to "blockers should have been brought up already", of course they should have! The standup, however, is the opportunity to make everyone aware, not just those involved in the blocking issue. Perhaps someone was going to pick tasks today which would have hit that blocker, and can change their plans. Or perhaps someone in another discipline has a solution they now know to bring to you after the meeting.
Summaries are really important, in acedemic papers, technical writing, forum posts (TL;DR), and daily life. Explain to someone what you're about to tell them. Tell them. Explain to them what you just told them.
Sure, I saw you walk up to the board 5 times yesterday, but I was too busy doing my own work to understand the implications. Sure, I know what's still on the burn down list, but are we thinking about taking the same tasks? Glad I now understand that the database problems prevent us from picking up one of the ten widget tasks on the burndown list.
A better title may have been - 'Are daily stand-ups an anti-pattern?'. Like with most applications of the term to social interaction it is based on too many variables unique to the individuals involved. He says as much at the end of the blog.
I don't think it's like saying "burgers taste bad." I think it's like saying "burgers are high in cholesterol and will contribute to an early death from heart disease." Even the best-run startup inhibits you from hiring remote, or being completely free to work whenever you're most productive. (A 9am standup has this effect for anyone who's most productive at 9am or 3am.)
We use stand-ups as opportunities to discuss obstacles that people are encountering and discuss opportunities for pair programming. I use them as an option in my training toolkit. If we're working on fairly routine things (like setting up unit tests, database layers, etc.) then I don't bother with stand-ups at all unless I sense a need (like someone hitting a wall).
* Creative
* Detail-oriented
* Outside-the-box-thinker
* Insightful
* Meticulous
If you restrict your hires to all excel in a single attribute, such as "self-starter", you may be missing out on some fantastic developers who excel in other things.
In short, some of your developers may very well find daily accountability to be helpful, and this doesn't necessarily mean they aren't fantastic developers in other ways.
Rant: Not everyone is an isolation-loving codemonkey. Some people need the feelings of team involvement, urgency and repercussions. If I'm just left to sit in the corner all day, and no one knows what I'm doing, and no one gives a shit if I do nothing... guess what? I'm going to end up doing nothing. Perhaps people like me are flawed, but we're still very talented and capable -- and not every company can afford to pass over the extroverted developers.
Anyways, I agree with some of the complaints. The tools can help out a lot. I disagree about the firefighting comment though. The whole point of scrum is not to firefight and leave that up to the scrum master so you don't lose focus.
But the standup is not about you micromanaging. The standup is about the team. It's not about having an accountability red-flag to force people into labour, it's about creating a benign cultural incentive to work. Some people actually like discussing what they've done. And if someone is having a slight episode of procrastination then knowing one needs to tell the next day gives an extra motivation to sharpen up.
It's not about putting collars and leashes on people. It's about giving visibility to work. Often visibility without explicit punishments nor rewards is sufficient to give an extra boost to efforts. It's an automatic reminder to people on what is important, without being irritating or nagging.
The commenter didn't say it was the only motivator, they said it was a motivator. It isn't some black or white thing- it's just another aspect. Unless you naively think your developers are robots, they will all have varying levels of motivation at different times, and this can help.
Why did you applauded his behaviour? So you could blame the method (which you didn't follow) later?
While such a thing may be true, and may need to be communicated to a manager, it probably looks bad to do it in front of one's peers.
If you're not motivated to do the items in your Sprint anyway, then you got a bigger problem than what your standup can fix...
I've actually wondered about this, ever since finding inconsistencies in the psychology literature about this subject, particularly those which echo my own experiences.
For example, Ordóñez and colleagues' 2009 paper, "Goals Gone Wild: The Systematic Side Effects of Overprescribing Goal Setting", identifies some of the negative effects: "narrow focus that neglects nongoal areas, distorted risk preferences, a rise in unethical behavior, inhibited learning, corrosion of organizational culture, and reduced intrinsic motivation."
Other work related (Sivers, McGonigal, etc.) to this effect has also argued that announcing your goals make you less motivated to accomplish them. There's yet other work, by Brown (in the book Daring Greatly) that shows that for certain personalities, these types of environments have a very opposite effect to enhancing motivation: instead, they generate anxiety, guilt, embarrassment, humiliation, and even shame.
I'm not doubting your experience, but my experience is more aligned with the items I've just mentioned. So it'd be interesting to try to tease out why some people experience the benefits you outlined, while others don't, even within the same scrum team. At one point, I conducted an informal study within our own team on scrum experiences and the results are completely bimodal. It's perplexing.
Asynchronous communications are best for development teams. Taking out an exclusive lock on every developer's full attention for 15 minutes is extremely dumb. Stop interrupting, you dumb-ass managers, and let your team do their work. They're smarter than you.
People may start (culture/nation dependent) e.g. 8am , 9am or 10am. I am usually a late starter so I hate stand ups at 9.30am as that as soon as I get in and I have no recollection yet of what I actually did the day before. And had I started a lot earlier also a sudden forced break may be breaking the flow.
People are more flexible on when they can go for lunch, (and to encourage people eating together in general for better team spirit), why not have the stand up 15, 10 or even just 5 minutes before lunch. E.g. 12:45 each day or 11:15 (depending when lunch hour is appropriate for where you work).
When people realise unnecessary prolonging the meeting is eating into their lunch hour some may keep their stand ups shorter :) And there is not much lost productivity by just stopping for a few minutes before lunch.
(I did rant about this once http://blog.flurdy.com/2013/04/do-not-stand-up-in-morning-do...)
Ah, you're from the HN Etiquette Police it seems? Apologies officer! ;)
Since we do stand-ups in chat, it takes a whole 30 seconds of my time, and I just read what the other guys are doing when it's convenient.
The only in-person planning we do now is our sprint planning.
I'd also like to say standup works great for remote teams.
A daily standup for a team which communicates well and has good interpersonal communication between collaborators and clients is kind of overkill. So when this happens, you jump through these hoops because that's what they put there. My experience is that it's not worth bringing up the lack of value added to the manager, as they see that as impugning their better judgement.
I can envision situations where a daily would be helpful, yes. It is however, currently overused/abused as a management tool, in my opinion.
It's ok if everyone briefly answers these 3 questions and moves on. 1 minute/each, no big deal. I find it a bit useful when I am work on something totally unrelated to the rest of the team.
The problem arises when someone abuses it and starts going into great irrelevant details about what they are going to do or did and carries on for 5 minutes. Everyone loses focus, gets annoyed or interrupted, time wasted. Same for managers who use it as a chance to discuss details with each member of the team.
So all in all, little to be gained and 15-30min of time to be lost by everyone. Not worth it :)
Then the team gets a chance to practice figuring out what's going wrong and fixing it themselves. No SM or outsider needed.
Really 5 minutes should do it. 30-60 seconds for everybody there, no more than 7 people on the team. If you're going 10-15 minutes? Somebody is talking too much.
Having said that, what I look for is a 3-minute standup that's over quickly -- and then folks mill about for another 10 minutes freely grouping and talking about the stuff they've just learned and how to fix it. This should be an emergent thing, and only happens when the team is working through a tough problem. If somebody is managing that process the standup ain't working right.
Stand-ups are a purposeful interruption, but they should also be energetic, to-the-point, and a way to prevent folks setting up a bunch of stupid meetings to waste peoples' time even more.
When I ran agile-driven development teams it really helped me and my team in three ways: 1) any blockers they needed to escalate got to me at 9 AM not at 11 or 1 or whenever is more convenient for you, op, 2) it made it immediately clear who was not making progress, 3) it kept people honest about staying focused solely on their story.
The latter was the most valuable because I had people who would agree to let (for instance) our deployment tool handle differences between releases as it was designed by the vendor, and then try to check in a zip or tar file because they couldn't be sure about the deployer.
Or my guy who would agree to bang out a simple static page and next thing you know he's trying to write a framework. Some of these people were new to agile but the process including the standup helped me break them of a lot of bad habits.
Still, I feel ya about early meetings. My boss is in a later timezone so my day starts at 7 local time, man. It could always be worse.
The real problem is that we do the meetings in person, rather than by writing a slack post/email, but there you go.
Every process of the team is open to change at retrospective: "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." So change it. :-)
team 1) At my first job I had a manager who spent his entire day putting out fires. I would sometimes go weeks without speaking to him. During that time, I would run out of work, be waiting on meetings he was supposed to arrange, work on the exact same piece of work as another programmer, fall asleep in my chair, etc. That team desperately needed a 5 minute meeting in the morning just so I could touch base with him and let him know what I needed and stay on task.
team 2) My second job was at a large company. Stand ups were regularly derailed by one or two people droning on about trivial details. The room had white noise generators which made it impossible to hear soft-spoken introverts (almost all of us). Management used it as a platform to inform us how to properly fill in time sheets and that was probably the most useful information anyone ever gained out of those meetings.
team 3) My current team is small with several remote employees. We communicate regularly through various channels on Slack. We recently decided to sync up once a week, and that seems to work well. Daily stand ups have been considered, but it really feels like a solution seeking a problem.
I'm personally not a fan of the daily stand up. Team 1 needed them, but only because the manager wouldn't take 5 minutes away from his insane excel macros to check up on the team. While the meetings did nothing for me on team 2, I do think they were helpful for management. Team 3 has no need for a lot of the same reasons outlined in this blog post.
I would love something less synchronous and centralized.
The cost goes up quadratically with the number of people you add (every single person has to spend 1 unit of time and attention for every other person) while the benefit is limited to either the people working together most directly—who should be communicating constantly anyhow—or for the manager.
Having everyone stand around to update the manager is not great for anyone but the manager, but of course they're the ones mandating and organizing standups in the first place. I've seen a few cases where that's what standup devolved into.
It's easy to do standup wrong, and the benefits of doing it right are not immediately obvious. I don't think they outweigh the costs, and I am not a fan of the practice.
This is a feature: it incentivizes keeping the functional teams small.
> or for the manager.
This is your problem. The "manager" is not supposed to be present in a daily standup, according to the design documents that introduced the term "standup". The daily standup is for the dev team to sync up.
Worst of all I felt that this meeting was a built-in context switch so I had to stop what I was doing, participate in the meeting, then get back to what I was doing which took a little bit of time.
Where I've seen it work we had competent and motivated people who wouldn't wait for a problem to fester on the side or delay the whole project. Also we ended up using tools (I know, anti-Agile) like Jira which really helped us keep track of where we were and where others were in their work.
I'm not a big fan of the daily stand-up but I'm sure there's a place and time for it. You just have to be honest if it's working for your situation or not.
I've also worked in places where you need to have a daily session where we communicate, because there are so many different (often unforeseen) things happening.
Communicating is a necessary part of working together, and a daily standup gives everyone an arena to talk with each other - not everyone are good at communicating as much as they should be, unfortunately, and this makes everyone reflect and vocalize what they're doing ... which is a good thing.
Personally - I don't need daily standups, but development is a team effort.
That being said, I think stand-ups create a "common time" where everyone can get be aware of what everyone else is doing, which removes that worry/distraction from everyone's mind at every other time. (I think being aware of what other people are doing is important, especially on a small company).
I've found they are more valuable on some projects than others because of the number of people on the project, how sharp they are, timeline and amt of work to be done, etc.. We've found them more necessary in projects with larger groups and shorter timeframe.
One counter-intuitive thing about them. "Oh great another meeting".. You may get back some time spent on email correspondence or impromptu meetings when every issue has to be emails back and forth. Just hold it until the next standup.
The author said you don't want to wait 8 hrs until the next mtg to alert the PM of a blocker, but often you can make progress on other tasks - save the emails - or even worse - the impromptu meeting. Often, it can wait until tomorrow.
Most important, don't let the standups get off track. Either a PM who tries to turn it into a regular meeting. It's not a 30 or 60 min. status update they may be used to. Or - who lets people run wild. It's 15 minutes and that's it - and take things offline.
It's also always code for "this is going to get ugly", or "this actually involves thought". So again, don't really get why "offline".
Additionally, I find it amusing (and agree with the author about standups btw) that anything which actually requires discussion among team members, and is interesting, and usually...worthy of us MEETING with each other...gets ordered out of the "meeting". Mundane status updates generally get ignored while everyone else looks at their phone or fidgets.
But more often that's not the case:
1. "Members of the team already know what I did yesterday, because they can see the completed items in the "DONE" column on the Scrum Board." - this is not true, because in case someone is a slacker in a team and does nothing you won't be able to track that, you can't see progress of "doing nothing" unless two days in a row you hear the same person still "working on the same problem". Everyone who participates in a stand-ups knows that bad feeling when you are on a standup and you don't have to say anything about what you have done, you force yourself to fix that because that embarrasses you.
2. "This question is a little maddening, isn't it? I can tell you what I'm planning on doing today, like maybe finishing the task that I just told you I was halfway through, and then grabbing the next..." - this is to prevent multiple persons on jumping the same task, that's your daily planning.
3. "Waiting for the daily stand-up is a terrible way to deal with impediments." - again, nobody forces you to wait for a standup to deal with problems that arise, this is used to explain why were you spending so much time on fixing some small bug. For example - you spent whole day trying to fix a bug, but the fix itself was a "one-liner". After looking to your commit I could make a false assumption that you were slacking the whole day and only made a single "change" where on a standup you have time to explain what problems forced you to spent whole day on tracking down that bug... Another example - someone spends whole day on a feature but still doesn't finish that even though it's trivial to implement, he might either explain that he faced a problems that prevented him from implementing that feature faster or he won't have anything to say because he was slacking
"A company--"
"Is like an enormous clock."
"--is like an enormous cl--yes, precisely!"
I'm a bit tired of this idea that because we work with other people we should be in a near-constant state of "collaboration" with others. (See also: the most common excuse for cubicles wuth waist-height walls instead of actual fucking offices.) Sometimes cranking out a piece of code requires nothing more than focus and sitzfleisch. One function of the stand up is to provide a Schelling point for team members to synchronize their models of what's getting done, after which they can go back to their distraction-free deep hack mode to actually do it.
Yup, because only developers should be at standups. Designers, UX, BAs, data guys, etc... should not be allowed to come to standups.
And your project is so small, you can track when everyone moves their cards.
> I can tell you what I'm planning on doing today
Yup that is fine. If you are being constantly prevented from finishing that, then that is a problem.
> Waiting for the daily stand-up is a terrible way to deal with impediments.
You are doing it wrong. Deal with the impediment straight away, and then start tracking it on the board. Keep everyone informed about the impediment, so that if it touches other people, they know about it.
"visibility"
This is the reason why I like standups. This gives everyone a good view on where everyone is, how they're doing, or if they're having a problem. This gives more focus on the product and business value and keeping everything on point.
It's the Daily Scrum.
> 1. What did you do yesterday?
> 2. What are you going to do today?
> 3. What impediments have you encountered?
Seemingly the main purpose of Scrum is to exert more pressure on the individual team member to avoid loitering.
I'm happy to see new processes appear, where that kind of extra hassle is removed, like: http://timeblock.com
In timeblock, communication happens when a developer can't get his task done. Otherwise everyone can assume that the week will proceed as planned.
In practice this seems to keep people happier than Agile/Scrum.
When in 3 words you can ask for help from someone who's done it before, and save a lot of time for the company.
There a lot of personality types that just won't ask for help, unless you make it a part of the routine.
Stand ups go bad when employers try to use it to "control" employees(You must be in at this time, put social pressure on you to complete things etc) as opposed to just a casual routine thing.
Tends to be good when implemented by devs themselves, bad when its enforced as strict policy, and business people trying to squeeze the last bit energy from the dev team.
The interrogation-style way of iterating over people imho does not work as well as iterating over work items (kanban board).
That said, in the end it is just a tool to align people. If you have a distributed team over many time zones doing daily stand-ups might not even work well.
In the end it is about achieving the alignment, not about doing the ceremony.
All in all processes can be super helpful, but they are just a tool. Similar to frameworks and libraries in programming you need to know when and how to apply them to the situation, they don't magically make your own code better.
And standups fascinate me. I have seen teams that were communicating horribly -- one guy would go off and work by himself, one person struggled with some new tech but couldn't admit it, one person was too shy to talk about his problems. You get them doing standups well and suddenly these things start to work themselves out.
But the really crazy thing is that those same teams, when things start working out? Many times the same members will leave the standup going "Geesh. What a waste of time."
It's like when you're inside a standup you can't see it working. Very weird.
I agree with most every point the author makes here. I do not, however, agree with the conclusion.
Communication in a team is a completely different type of thing than programming or math. It's not just the movement of data around. It's a social thing. There are no red lights that go off or alarms that flash if you're doing communication poorly. Everybody just keeps working as if communication was going along fine. So it's not something you can do, inspect to see how it's working, then adapt. The feedback loop is too subtle.
So standups end up being something akin to brushing your teeth. You do it daily -- sometimes multiple times daily -- because over the long run folks have observed that you'll be much happier. You do not brush your teeth and then go "Wow! I feel so great because I brushed my teeth!" Doesn't work like that.
If I had to toss out every piece of process BS I could, I'd probably keep standups, co-location, and mob/pair programming. Some kind of kanban/story board and TDD/ATDD would come a close second, but only under certain circumstances (commercial software work, more than 2 folks, etc) In general you add in stuff as your project grows more complex, but standups are pretty useful even if it's just you and another coder talking over the phone every day at 9.
One nit with the article. In it he says that the third part is "What impediments have you encountered?" I prefer to phrase this as "Is there anything we can help you with?" People have problems when they work. What I'm really want to know is "Have you taken some time to think about whether other folks on the team can help you with anything? Because that's what we're here for". Yes, you should be doing this constantly. No, people do not do this constantly because they get their head stuck in their work and need a moment to look at the other guys and reflect.
Individuals and interactions over processes and tools
but is explaining that his tools (github etc) should let his team know what he did yesterday, and that he finds it pointless to tell them face to face.
Now, the daily standup is one method of updating the board with the added benefit that it provides maximum bandwidth of information of team status in a brief time to all team members.
The author stipulated that in their team everyone else already knows what others are doing. If so, great. However, I think it is really naive to think this would hold for all teams. For teams that lack this amount of coordination and transparency I would see a healthy standup that is brief and to the point improves teamwork as it helps synchronize work.
Not all teams are composed of equal members. There can be coherent products whose team members work on completely different areas of the code and the product to implement the feature and in those instances I would imagine it would slow down total velocity if everyone would need to keep tabs on what everyone else is doing. For instance, a dedicated tester might be a part of the team, who is not so interested in explicit submits but rather what is the current end-user interface status.
Not all people are comfortable in asking support due to shyness and so on. Having an explicit process of synchronizing work and announcing impediments can help there a lot. Since impediment removal is part of the process, the person asking for help does not need to feel like a bother (and they notice others need help too), the work progresses and everyone is more relaxed. The counter argument is that people should already be good at teamwork - sadly this is not true, great teamwork is not inbread to humans, but, everyone can learn it and having a teamwork supporting process in place helps to maintain a healthy culture.
So, I suppose, in the end, it's not necessarily about standup vs. no standup, it's about having processes that helps supporting a healthy team culture, whatever it is. For small teams with long term stability this is less of an issue but the more ephemeral the team constitution is and the larger it is the more value a healthy standup process can bring (healthy as in by-the-book-scrum healthy - to follow the manifesto style - I prefer a by-the-book-scrum standup that is about bringing value to the team to a standup that is converted to a managerial status update).
* Stuff you deemed important?
* Stuff the team deemed important?
* Stuff the customer deemed important?
The biggest gripe I have with daily stand-ups and I am sure there are others (including the author) who agree with me on this: they often run over and turn into meetings/debates. While some workplaces I am sure have it down to a science, I routinely encountered stand-ups turning into group bitching sessions about a bad deploy, a changed requirement or issue someone is happening as a result of something that someone else did in a previous release or a management decision. Instead of staying on task, they would often derail. Even when someone would try to steer the stand-up back, it was too late. It would be short-lived and it would derail again. Time after time.
There is nothing worse than the feeling of being in a stand-up knowing that you have a few tasks with looming deadlines that you want to get done. This sinking feeling in your stomach that time is escaping you and there is nothing you can do about it. That the 15 or 20 minutes the stand-up is going for, you might have been able to knock one of the tickets off your list and reduce your stress levels a little bit. It's a horrible feeling and one I have felt many times over the years. It's a kind of anxiety that stand-ups seem to make even worse.
More often than most, the question of what did you do yesterday usually results in: I don't remember. And you know what, if you have a lot on your plate, that is a fair statement to make. What is the point of saying what you did yesterday other than to appease to micro-managers (as the article points out)? Does Steve the system administrator truly deep down inside care about that bugfix I finished yesterday? No. The stand-up seems to operate on this purist view that people have a set plan of what they will work on for the day. As a developer what I plan on doing for the day about 90% of the time never works out how I would have imagined.
I come into work with the greatest intentions of finishing off an outstanding task or finishing off some low-hanging fruit tasks in Jira, but then something will break, someone will ask me to do something and say that it is urgent and BOOM! there goes my "planned" day of doing what I planned to do invalidating what I just said in the stand-up.
I feel like I am in a minority that views stand-ups as distracting, starting out as status updates that usually diverge into meetings that cut into my precious morning. Don't get me started on what happens when someone is working from home, has to dial in and all you can hear is children screaming or dogs barking (I've beared witness to that a lot).
These days we have tools like Slack or Hipchat, we have collaboration platforms like Github, Bitbucket and peer review applications like Crucible. I feel like the stand-up is an outdated relic in todays development ecosystem. Instead of making it a single discussion everyday, how about we work on making teams talk together on a daily basis when they have a problem instead of waiting until the following day to bring it up?
A place I contracted at recently used Slack and they had a #standup channel in which people would post what they would be working on today, there was no requirement to dwell on yesterday only the today. And if there were any blockers or issues, you were encourage to create an issue in Jira and tag your manager instead of voicing them in the chat. In my opinion this was a good approach because it meant people could give an update without distracting others and on their own terms.
Stand-ups encourage anti-communication in that they seem to be used in place of actual communication, they can also feel like pitchforky at times: meaning people often get publicly implicated and blamed for issues/hold-ups which usually results in a defensive response. "I can't do anything until Michael addresses my blocker" to which Michael would reply, "I can't get to Daves blocker task because I keep getting asked to do other things"
In my last job (best one of my career so far), I was able to convince my superb director that stand-ups suck and he allowed us to replace them with a meeting-free written-by-a-certain-time variant. What followed for our team was one of the most productive periods that I have ever witnessed. This contrast convinced me that stand-ups are one of the reasons development has started to suck for most developers; we are being gang-statused to death by cargo-culting ignoramuses. When I saw the movie Zero Theorem, I instantly sympathized with poor Qohen Leth - he just wants to work but is constantly harassed and statused by various minders, who really should not exist in an efficient workplace.
In my current job, this tired old stand-up specter rose its ugly head once again today, for reasons that have nothing to do with the development team's productivity. I am ready to quit if it actually makes an appearance - my notice is ready in my drafts folder.
15 min is the limit of the standup but it should rarely get to that. A well run scrum team does daily standups in less than 5 minutes.
In agile, the team self manages and decides how much of the process they want to follow: if some higher up comes down dictating "thou shall be standups", I would be giving my notice too.
I see a lot of people talk about 5 min stand-ups or 15 min stand-ups but that misses the point. The main issue is interrupting someone for any period of time for an (IMO) unproductive and trivial statusing when so many other methods exist to get their daily status and leave them alone.
> I had multiple other meetings daily but I felt these had more utility as they were related to design and requirements.
Well, that's a problem. In agile there should be only one planning meeting per iteration where you discuss design and requirements.
In my last job we agreed to designate one team member as a rotating "support guy" for the iteration. One guy takes the plunge, gets interrupted all the time and attends all meetings so nobody else has to. It worked great.
In my last job we rotated scrummasters every iteration. Daily meetings were not starting on time and running long.
My first turn I closed the door and said: "Ok, I want to keep this under 5 minutes so lets go around quickly". A couple of the guys who usually showed up late came in when we were almost done. I completed the meeting with a friendly reminder the meeting starts at the agreed time, sharp. After that, everybody showed up on time and meetings ran less than 5 minutes average.
> More often than most, the question of what did you do yesterday usually results in: I don't remember. And you know what, if you have a lot on your plate, that is a fair statement to make.
Someone having "a lot on their plate" is a symptom of poor iteration planning: no team member should be working in more than one thing at a time. Also, tasks should be sized between half a day to 2 days of work (around 3 to 12 ideal hours)
If your scrum board shows a bunch of small tasks less than half-day work, then your team went too far micromanaging and should combine them into single tasks that take no less than half a day to complete.
If a debilitating bug is preventing your users from using your app, you're going to make the team go out of their way to fix it (even if it was not planned). If "higher ups" want to implement a last minute feature because an investor meeting is coming up and a competitor just launched said feature, no manager is going to firmly say "no, you can't have it unless we plan for it" to the very person(s) that pay their salary. Sprint planning meetings and poker are great for estimating new features most definitely, but they fail to really and realistically take into account that sometimes SHTF and no amount of planning can accommodate for that.
In the real world developers don't get to go into sprint planning meetings, get a set amount of work and no that's all they'll be working on. I mean, that's how Scrum is supposed to work, right? But how many developers can honestly say it stays that way? Scrum/Agile does not stop people going outside of the framework (and in my experience there are always people that do) and assigning you work or asking you to do what they think are "small tweaks" and "quick changes" which usually blow out into one or two day tasks that take you out of the sprint workflow, then the burndown graphs start looking bad and your manager starts wondering why the graph is not looking so good.
The issue with Scrum/Agile is not the fault of the methodology itself, it is the implementation. On paper it looks great, but in the real world and this I need it now society we have created, it becomes increasingly hard to stick to set fixed processes when things need to be done right now. I don't doubt that some places are doing Scrum/Agile right, but from what I have discovered and again this might just be on account of bad luck, most places are not doing Scrum/Agile correctly and it only takes a little imbalance from the methodology to throw everything into disarray.
In my experience sprint planning does not equate to less work or more balance, it doesn't reduce the stress. Yeah, you know how much time you have in your sprint period, but usually there are tasks that only specific members of the team can work on. Meaning someone is usually doing more than someone else. Once again though, maybe I have just been unfortunate in the places I have worked which haven't implemented the pure and originally intended form of Scrum/Agile.
It just takes one higher up MBA who thinks he can do Scrum/Agile better to try take over and screw the whole thing. When that happens I usually turn my 2-weeks notice. You can't run Agile properly without management backing.
Well, Scrum/Agile isn't a thing, its two very different things, and if you implement either of them in its "pure and intended form", you are absolutely not implementing the other in its "pure and intended form", since Agile is an approach that disfavors rigid externally defined methodologies in preference to adaptation to the needs of the team, and Scrum is a rigid, externally defined methodology with a rulebook of specific practices which, if you aren't following, you aren't doing Scrum.
An organization taking an Agile approach may adopt Scrum as a starting point for its internal processes as it evaluates what works for the teams it has on the problems it is working on, and adjust the details from that baseline. But if you are working within the defined bounds of Scrum you aren't Agile, and if you are Agile you are not committed the rules of Scrum.
Confusing Scrum for Agile or vice versa is a sign that someone doesn't understand either Agile, Scrum, or both.
How do you do that? My company has many small products/projects. Can't staff them all full time, and can't schedule them to be independent (project A is worked on Jan 1-15, B on 16-31, etc). It is inevitable that you will be working part time on several things at once.
> If your scrum board shows a bunch of small tasks less than half-day work
Some tasks are half day. Get Windows installed on this server. And so on. Oh, you can make a task "get windows installed on the server, and update the FooBar documentation" but that is just artificial.
Not everything fits into scrum.
You can manage multiple small projects just fine this way. I just left a place where the team was doing just that.
> Not everything fits into scrum.
You are absolutely right. SCRUM is great for processes which are empirical in nature (same inputs, different results).
Software development is empirical: give 2 teams of devs the same requirements and deadline, both teams might return code that essentially does the same but the code bases will be different.
IT support stuff such as installing Windows is better managed with a defined process (same inputs, identical output every time).
Wikipedia article on the Empirical process control model: https://en.wikipedia.org/wiki/Empirical_process_%28process_c...
And in a multidisciplinary team, standups help with cross-pollination. I'm an ops guy, but in standup I find out what the design guy is doing. He doesn't commit to a repo that posts notifications, but I get an idea of where future ops work is going to land.
If standups don't work for your team, don't do them. But they're not an anti-pattern.
That's the useful information I like to see. HipChat + Bitbucket is the most powerful combo I have for keeping up with what everyone on the team is doing.
No one (except for terminal middle managers) likes status meetings but the alternative (in many settings) to a fixed daily status meeting is random, unpredictable status pings from management which are far more disruptive to the daily work flow. I'd rather give status at the same time every day than deal with the irritation of a "What's happening?" interruption.
As long as people actually stand and the meeting ends at 15 minutes and there is absolutely zero risk of follow-on meetings, stand-up is probably more good than bad. Done properly, it eliminates the resentment and politics that come from the "Does Tom actually do anything?" type of speculation.
That said, Scrum is just horrible. The whole package is a bundle of fail. Senior developers will resent it and leave, and while junior developers may benefit from the structure, what they really need is mentoring and they're not going to get it when all the seniors are either (a) trying to make an acceptable "user story point" count for the week or (b) looking for other jobs. Scrum sucks. It never adds, it's either meaningless or it detracts.
If you're really not convinced, read my take-down of Agile/Scrum on Quora: http://www.quora.com/Why-do-some-developers-at-strong-compan...
I don't know why it is that all this Taylorist pseudoscience that failed in the rest of industry has made a home in the software industry. Fuck Scrum and fuck Agile, and this is not "excessive negativity" because I have seen that shit burn down (pun intended) billion dollar companies-- not meaning "the culture became something I didn't like" but "Scrum directly caused it to lose 80% of its market capitalization". That shit is fucking toxic.
As a result, I didn't think Scrum was all that bad, until the worst job I ever had instituted the daily stand-up meeting.
Anecdotally, Scrum will do nothing to help an already good development process, and will make an already bad development process much, much worse.
As such, it means nothing to me if a company "uses Scrum". I have to look at the individual development teams, and see for myself how they really do their work. A decent development team can create a facade over their own working process that looks enough like Scrum that management won't interfere with it. A horrible team can create a Scrum facade over their own process that multiplies aggravation for everyone with no benefit to productivity.
I'd even go beyond "fuck Scrum" to spurn any development process that has a brand name and a dedicated consultant ecosystem.
Anyway, behind your rant I just sense the notion that YOU think scrum doesn't fit YOUR working style. Doesn't make it an antipattern by a long shot.
It's just 15 minutes to give people a status update, sync up on what you are working on, and surface any problems. After that you can get back to your keyboard, headphones on and be anti-social for the rest of the day.
Too much process is bad, but complaining about a 15 minute sync up is just petulant.
The OP argues for more communication and collaboration throughout the day: Don't wait for the standup if you're blocking. Share status information immediately. Keep up to date with teammembers constantly.
Also, dammit, it's not a sync! And if your team has so many members that it last 15 minutes, there are too many people on the team (or the team is being too lenient with the format).
Instead, 15 minutes at the start of the next day are ideal to get a batch update on how the development of component X or the provision of server Y is progressing is perfect.