One of the most important things that I've learned over the years is that the Daily Stand-Up is a tool that solves a particular problem.
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 part about the stand up that's "what did you do yesterday? what will you do today?" is the part that is the anti-pattern. In a well functioning team, the only thing that needs to be communicated is "Heads up: you need to know this now..." That's the part of the stand up that really matters.
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."
Agree that that's the ideal situation, but I've found that stand-ups can be invaluable in detecting and avoiding wasted effort that's about to happen because not everyone on the team has all the context needed to avoid it. For example:
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.
Plus: as soon as you have some people on-site and others remote, simple things like updating the board are done at best inconsistently. Having a standup with your remote devs on hangouts/whatever can save you a whole day's duplicated work.
We've switched our standup format to only talk about the tickets on the board and the daily actions needed to move them to the next stage in the process. This avoids pointless status updates and keeps everyone focused on getting the priorities done.
It also keeps the team together as a team. The team I work on is in three geographically separated locations. Without the standup we would tend to become three separate teams.
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.
What happens to Fred, who had an appointment and wasn't at the standup? I suppose in this example he'd notice that he isn't able to work, and ask around, but ...
It's imperfect, but IME a standup is more reliable and usable than any alternative I've seen tried. Emails get lost in the noise (that people get too much email at companies is its own problem). A Slack highlight can be more of an interruption, and non-technical people find it hard to use / won't always be responsive there.
Internal wiki hits the same problem as email (although partly because companies always seem to choose terrible wiki implementations (confluence)). Too much information goes on there, terribly organized, and no-one ends up being able to find anything. Mostly these kind of things are immediate announcements that need to be acted on once and never again, so a semi-permanent store isn't appropriate; also the whole point was that everyone needs to be notified, but people can't watch every wiki change.
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.
I figured out a work-around. Before I go to my appointment (or vacation day, etc.), I go to the meeting board and put a big green check mark next to all of my completed tasks.
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.
Sounds surprisingly similar to some of the worst meetings. "Nothing to report" is just as meaningful as the assumptions about the knowledge of everybody else it builds on are not entirely wrong.
I guess we are drilling down to the similarly fundamental yet pointless truth about communication: it's easy when it is working well.
Surely if there are any "heads up"s they should be emailed to the team as soon as they happen. What's the point in waiting until the next morning to tell everyone that the test databases have moved?
>> Specifically, if you have a team that doesn't communicate effectively on a daily basis,
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.
I've used word "replace" in another comment about pair-programming.
It feels now that it's a trend in "cargo-cult-agile" to somehow inverse agile manifesto principles. E.g. replace understanding of how team should work with a formal sertified scrum process - "you do iterations, standups and stuff - you fine!"
Burn-down carts and sheer numbers of closed tasks disguise real state of the software being developed(just create more tasks and then split them to create volume).
> 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.
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.
I think it's actually the opposite: everybody is invited to the daily standup, even the janitor if she/he so pleases... but only developers can talk.
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.
> I think it's actually the opposite: everybody is invited to the daily standup, even the janitor if she/he so pleases... but only developers can talk.
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.
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.
I actually like to run standups as "all business": everybody says their piece and goes back to work as quickly as possible.
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 find I have a natural tendency to talk about non-work things because I feel guilty about not being more social. If we did that in my team I'd probably spend 20 minutes talking about netrunner with the other player and not actually mention any of my blockers.
But by all means try it out; if it works for your team, great!
That's good to be aware of. And your self-modulation helps the team. But don't let that be an excuse for not sharing what you learned yesterday that you think the team needs to know.
Technical teams often have a team lead, who can be the line manager for the developers. This person is part of the team, and can help identify problems and fix them. I think this works better than managers who are not involved in the daily work of developers.
I'm the team lead for my team and that's more or less what I do. A lot of the developers on my team are juniors and haven't developed the sense of knowing when there has to be an obviously easier way to do something and ask someone or search for it. Standup helps me to see who's stuck or where I can help them with an issue that could be done more efficiently from my own trial/error and experience.
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'm with you brother , don't give into obsessive insecurity. Retrospect for the win , have faith . an hourly pulse does not help you predict a heart attack any better than a weekly sampling
I tend to have a problem with managers who think doing Agile™ yields a better quality product.
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.
"Agile", or "XP", or anything else along those lines is no substitute for leadership. For giving a damn about the team, the product, or the company.
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.
A clear sign of a broken Scrum process is having daily standups with 5+ people who know/care little about what the other team members do.
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.
Somehow "Individuals and interactions over processes and tools" become "Follow this process and you'll get better software" and people mostly don't even criticise agile methodologies of hipocrisy.
Totally agree - i'm currently a scrum master and doing development in the team. I try to reduce meetings as much as possible because the process itself doesn't yield results - te team does. An empowered, enthusiastic and communicative team gets stuff done. And mostly, developers enjoy their work which is the actual software development so they should spend as much time as possible doing that (plus issues with context switching).
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.
The Agile that works is the manifesto. I was once reduced to literally quoting the manifesto in a retrospective, to try to get across the point that our process was excessive and not helping.
(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)
There is something ironic in how the Agile movement, originally the antidote to heavyweight processes, has been used to justify an explosion in highly detailed and prescriptive methodologies. To be clear, this is not intended as a criticism of agile methods per se, but merely a comment on how the world works.
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.
I'm tempted to replace developers who can't be bothered to help the rest of the team out by putting in the tiny amount of effort required to keep everyone up to date with what's happening with the current tasks. Really, it's five minutes out of your day which makes everyone happy because they know that tasks aren't stuck or forgotten about and doesn't require you to interrupt your flow.
I literally work in a team of 2, that also has a PM. We've been parachuted in another team's standup.
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.
I think that you and evilolive can be each experiencing your respective problems. At times I've been the developer who has failed to update tasks for days/weeks. I've also been pressed for updates 5-6 times in a day by different managers and "managers". Both problems are fixed by all parties respecting others as people and doing their jobs correctly.
The version control hoster that we use has an integrated ticketing/bug tracking solution, which lets you easily reference tickets in your commits to do this sort of task updating.
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.
Ours does too. I find that it is nice to have the additional information when the commit message is a bit general. Although this is a problem with the message itself.
It also can be helpful months later when needing a reminder why something was changed based on an assumed unimportant detail at the time.
Yeah, it's fine if you have external people listening in. If there's five people at your standup though, it means they probably don't have anything better to do (like idk, manage).
Standups can be very useful for entire team. But what bothered us was the sync aspect of it. People knew standup is coming at given hour and they need to schedule their work around it because they know they will be interrupted.
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"
That's excellent! I find the cost of a "15 minute" standup is more like 1.5 hours. First, it's hard to get any work done in the 30 minutes leading up to the meeting because I'm trying to come up with what to talk about. The meeting never lasts 15 minutes, it's always 30 minutes, and it always involved being immediately ordered by the manager to talk about some BS nonsense that came up in the meeting. Then it taks an hour to get back in the zone to be productive after the meeting.
My current team does a standup immediately before lunch, scheduled for 15 minutes and often coming in shorter. Those "oh, we should talk about that" realizations that come up then often wind up, when they do (and it's not every day), then often happen casually over food. It winds up pretty comfortable, although I certainly see ways it could go bad if we were focused on keeping the form of it rather than whether things were working well.
Ouch. A 30 minute standup? Even in places where I worked that had insane 20-30 person standups (we pleaded to have the group split up, but to no avail, as they were really for the multiple PMs and POs to keep track of what all the devs were doing) it only took 10-15 minutes.
Since Agile became a buzzword (and before that "Extreme Programming!!1!") about 14 years ago, I've never seen it work right. I've never seen either of these have a net addition to the performance of the team. 2 developers pair programming don't get new features done twice as fast. (though it's great for fixing a bug or transferring knowledge for a particular piece of code.)
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?
The worst standup I've seen was lead by a fitness fanatic tech lead / manager. He used his superior endurance to 'win' technical arguments by just talking until people gave up because they wanted to sit down. These were typically hour meetings, but could extend to three. I'd give them 15 minutes then start sitting on the table.
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.
God damn it, everything you write on here is so valuable and good. You are making the rest of us look bad. Stop it! ;)
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.
That hasn't been my experience. I've never been in a standup meeting lasting more than 20m, and almost always < 10m.
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.
I've been xp/scrum (what a god-awful word btw) since 02. I've seen it work extremely well many times, with very large teams, and small (process weight shrinks w/team size).
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.
Stand-ups vary so much between teams that it's naive to say flat out that they're an anti-pattern. What the author really meant (or should have) was stand-ups in his team are an anti-pattern.
It's like saying 'burgers taste bad'. If your burger tastes bad, then maybe you're making it wrong.
It's not especially constructive to to reply to a detailed article on "X is bad" with simply "you're doing X wrong", without offering additional advice on what the author has missed or how to do it right.
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?
Standups do provide a useful habit of synchronizing regularly. More mature teams can probably do this without a scheduled meeting.
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.
Here are a couple things we tried for our scrum teams.
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.
> We let them choose the time of the day for the daily stand-up.
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?
Yes we are in the midst of a transformation and most people are new to this. And those with previous experience with scrum teams had lots of bad experiences elsewhere (hour long stand-up meetings and inconvenient times, etc.)
I agree with this. Standups for our team don't replace regular communication, but they do help to focus on what's important: knocking off tasks.
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 hear this from standup advocates a lot, and it always sounds very condescending to me. "If you're using our technique incorrectly, then you're not worthy to critique it."
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.)
When the author states "The first question of the daily stand-up is pretty pointless: What did you do yesterday?", he misses the real value in the question, which is to motivate me to do something today which I will be able to talk about tomorrow.
I don't agree with this. People who aren't motivated or didn't do anything just make things up. One day I helped another developer fix a simple bug. By help, I mean I sat on his computer and fixed it while he watched. It took me ~20 seconds. He then talked about how he fixed the bug in detail for a minute and a half the next day. Apparently that was all "he" accomplished. Everyone (myself included) stood silently and nodded our heads.
badthingfactory may have been waiting for a more tactful time to say it, rather than blurting out "You're full of it, I did that for you!" in the team meeting.
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.
> which is to motivate me to do something today which I will be able to talk about tomorrow.
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.
As a lead developer, if my developers are only motivated to do something each day because of being held accountable the next day, then I hired the wrong people. I want people to be self-starters. I shouldn't have to babysit and micromanage what they're doing each day.
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).
.. and so on. I've found that with any such list, people will already excel in some, and still be growing in the others. Oftentimes these attributes are contrary to each other -- your most creative developer is probably not your most detail-oriented developer, for instance.
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.
There are plenty of talented, productive people who aren't self-starters. Your company will be missing out on them. You can easily say they're the wrong people, but you could also say you're the wrong leader.
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.
" I shouldn't have to babysit and micromanage what they're doing each day."
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.
As a lead developer, if my developers are only motivated to do something each day because of being held accountable the next day
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.
"I shouldn't have to babysit and micromanage what they're doing each day." Sorry, you call 15 minutes a day micromanaging?
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.
That seems to motivate you to do something that can be talked (bragged) about, not something that is actually useful/needed, that takes more than a day to work out fully.
Stand-ups don't work because the attendees are too focused trying to keep their mind full of their current stack of work, to not forget anything, whilst the 15 minutes of managerial meaninglessness plays out. It can be mind-numbingly boring listening to other developers speak about some bug they are working to fix when all you want to do is go back to your desk and continue with your own work that is far more interesting.
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.
This has been my biggest peeve with the standup idea. Quite often I'm in at 8 or 8:30, so if I actually get started working, rather than dinking around doing email before a 9:15 standup meeting, I'll just be getting into the flow of what I'm doing when it's time to come up and switch gears to do the meeting.
I not totally against morning stand ups but with people starting at different times it may be easier to have a lunch time stand up.
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.
And some people may not... leading to the whole team missing their lunch break on a regular basis because of that One Guy who won't shut up. Guarantee that would have happened in the last team I did "Agile" with.
Coding and associated work efforts are largely individual. You sit (or stand) at your computer and work alone. But in reality you are working in a group. The standup reinforces the team nature of the overall effort. Humans are naturally social, but the computer engineering work effort is done largely individually. Something is necessary to maintain the social element and that's where standups come in. Other meeting patterns could work, but one at the beginning of the work day where everyone "checks in" seems to work well from the standpoint of managers whose job it is to corral independent workers of different strengths. If your team doesn't need a standup that's great, but if the team starts to need one you will wish you had been doing it all along before the balance got out of whack.
In my team, we do stand-ups in chat. It's basically just to get a sense of what the UX guy is doing, how the UI is coming along and what APIs that I need to build or fix for them are, etc.
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.
+1 Chat is awesome for standups and generally does all the required things. Wish everyone did it this way. The one thing I'd like to see is more scheduling of breakouts (conf calls) though. An ideal standup for me schedules at least 2 conf calls per day to work through issues. This is very rough estimate, fewer is fine only if everyone is chugging along great and knocking off tasks quickly and cleanly.
I'd also like to say standup works great for remote teams.
My take on this, from my experience, is that some managers manage by cargo cult. They skim HN, HBR, etc. and introduce things --whether they are appropriate or not. Many times these are new (but not always young) managers who are just learning and don't have a lot of experience to go by beside reading some management books on the side.
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.
Stand up is not easy to do well because people tend to abuse it a bit.
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 :)
One of the ways I train stand-ups is having teams do fake standups. Everybody gets a card. Some cards just describe a couple of new things to report. Some cards provide instructions to destroy the stand-up. Things like "Ask a lot of questions when somebody else is talking" or "Ramble on for a long while about the story behind a problem you had"
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.
My current team does the daily standup and we discuss only "what's changed" (no changes - move along). It takes 15-20 minutes usually and I find them very useful: they bring everybody on the same page, help spotting issues earlier, prompt for deeper discussions after the standup.
I mainly resent standups because most employers I've ever had scheduled them at 9am, and I'm not really ready to talk to other humans yet at that hour.
Consider it the price you pay for potentially spending the balance of your day unmolested.
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.
Why not change it at retrospective? If daily standup has become rigid, it has violated the most important part of the manifesto: "Individuals and interactions over processes and tools."
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. :-)
I've been on three different teams in my career and each had different needs in terms of daily stand ups.
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.
To me it's also annoying as an unnecessary point of synchronization—for everyone on the team. Everyone has to be there at the same time, which means that either everyone has to arrive at the same time (annoying, inconvenient and unnecessary) or everyone has to interrupt their work at the same time. Aren't interruptions grand?
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.
> The cost goes up quadratically with the number of people you add
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.
I see where he's coming from. In practice I've used the daily stand-up at a large company and we pretty much did the opposite of things he mentioned in the article that the stand-up is supposed to do. We ended up doing the stand-up for not just one project but multiple concurrent projects. People would try to solve problems and went way off track during the meetings. They lasted a lot longer than 15 minutes for sure.
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 worked in places where people just say "nothing to report", and the meeting was over in one minute, and that's great - the team is using good tools and communicating well.
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.
Agile, in my understanding means "adaptive", and people often forget that part. If meetings or whatever else aren't working FOR YOUR TEAM, then don't do them. I think the retrospective is the only real cornerstone. It should happen, even if everyone just says "I think everything is working fine".
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).
This is the best advice possible to people who have dysfunctional agile implementations. If what you're doing isn't working, stop doing it and try something else. The only thing that you should consider mandatory is a regularly scheduled retrospective. (And if people complain that the process keeps changing too quickly, you can always decide in the retrospective as a team to have less frequent retrospectives).
Some thoughts about dailys as we've started to embrace some scrum elements over the last few years.
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.
Where did the term "offline" come from? It's bewildered me for the past decade. It's always used in a meeting, which is inherently "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.
I don't think that's an anti-pattern. You'll be surprised how difficult it is to keep everyone focused on the goals of the sprint, or even to make sure they are working on the tasks of the sprint. I've seen teams that fail to stay focused even with daily standup meetings AND a huge scrum board.
You might agree with the author if you are working with self-managing team where everyone is capable to deliver something daily.
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
> Each member is not a silo, but a cog in a highly functioning machine (you're much more than that; I'm terrible with analogies) that needs to work cohesively with the rest of the machine to function successfully.
"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.
Monkeyfighting snakes on a Monday-to-Friday plane ain't got nothing on autocorrect censorship: "pain in the arose", "what the duck?", "you're gonna see some serious shot".
> If they don't happen to see me move my task around, they probably noticed my Pull Request being put into GitHub, and various comments and discussions going back and forth on the code and feature. Additionally, we use HipChat, which receives notifications of GitHub activity as well.
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.
The daily stand-up for me is summed up in one word:
"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.
I've used Scrum/Agile for several years and daily stand-ups seemed to the thing a lot of people hated. As a started my own business (Financial Analytics for SaaS) I finally understood why. An effective process shouldn't need polling to keep it going - which the meetings really are.
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.
The problem with a lot of developers is that they just want to be sit in a corner, and figure stuff out on there own.
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 more people you have the more complicated it is to align everyone. Stand-ups are a way to help with that.
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.
I worked at a place that did a stand-up once a week, and that worked pretty well. The communication between everyone was pretty good, so maybe other places that don't communicate well could not get away with that.
Verbal communication is far richer than written. You gain insight into how a developer feels about aspects of their work. Is there something they're not happy with but aren't comfortable talking about, are they enthusiastic about something which motivates other team members? Team dynamics can't be distilled into written communication. The standup can surface things like tensions between team members or a drop in morale. It's not just there as a status update, it's there to solve softer problems to help turn a group of developers into a great team.
I teach this stuff. I am also not a process wonk. In fact, I'm just a coder. I help teams because as a coder I've seen hundreds of teams in dozens of industries. All I care about is what works.
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.
If you have a team that works fine, then yes, okay, don't do that stand-up. But usually people don't know what the other guys are doing in the other office or even just the next guy, because projects are complicated in real life. And if you really follow that pattern, then each member takes less than a minute and you are done in 5-10 minutes with a whole team. There is nothing to optimize, even if it's unnecessary.
I think a scrum/kanban board is a very strong instrument in implementing a healthy development process. There should be an explicit method to updating the board - even if the method is just "you can move only your own tickets". If there is an intact development process that lacks a board&ticket system I don't see it is necessary to implement one. However, broken development processes often have a problem of priorization and communication and discplined ticket and board tracking system can help there a lot.
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).
I've never worked on a team that did /daily/ standups & I plan on never doing so. Heck I missed half the meetings we had on my previous job and we only had maybe three a week. Was I a jerk? Yes. But I also got 3x more done than by sweating the superficial stuff.
I cannot agree with any of the specific points (1., 2. and 3.) being generalizable enough as arguments against standups. They may be valid notions where the author works. Perhaps this writing was intended rather as tool in office politics than general rumination on the topic?
The worst part about it is it becomes a way to force people to come in at a certain time. Look, if I only have GOD FORBID 6 hours of time overlapping with someone and want to come in 2 hours later, I think I can SOMEHOW catch them. Especially since they sit to my left.
I don't agree with the term anti-pattern in this case, but I find standups boring and a chore. I also think standups drive a culture of velocity instead of progress, which can be a little maddening.
I have worked in quite a few Scrum/Agile workplaces over the years. I have seen it work really well and I have seen it work horribly as well. The weakest part of Scrum is definitely the daily stand-up. I have often questioned whether or not I am wrong over the years because it seems the bulk majority of those who have worked within a Scrum ecosystem seem to like the daily stand-ups. I have voiced my concern about them over the years, but it usually riles people up and ends up being a one-sided debate with those in favour making you feel like a bad employee.
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"
> 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.
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.
> no team member should be working in more than one thing at a time
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.
Let me clarify: no team member should be working more than ONE TASK at a time.
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).
In my experience rarely is Scrum/Agile implemented into an organisation in its pure and intended form. I think companies start out with the best intentions, but the nature of modern software/web development is things are sometimes difficult to plan for. In the beginning it can be great, but once again, things start to derail. Sometimes companies want to implement process, but they realise the amount of organisational work that goes into adhering to Scrum & Agile, they get half of the way there and half-implement it.
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.
> In my experience rarely is Scrum/Agile implemented into an organisation in its pure and intended form.
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.
What you describe here is what usually happens when a manager thinks he "knows Scrum" but really doesn't.
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.
You are not alone. I despise stand-ups with a passion. It is not because I haven't given them a shot - I have spent (wasted) ~1000 x 15 min (avg) of my life on this useless misery with nothing to show for it but an overabundance of stomach acid.
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.
Did you have to attend other meetings during the week besides the daily standup?
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 had multiple other meetings daily but I felt these had more utility as they were related to design and requirements. We were unfortunately forced into daily stand-ups due to a department-wide "process" so to your point about self-managing, that was quite absent here.
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.
What if I tell you in exchange for 5 mins everyday you no longer have to attend any other daily/weekly meetings? Does it sound like a good trade off?
> 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.
So, our commit notifications in hipchat all come from the same user(s) who pushes changes to master. You can't always tell who made the commit, and not all commit messages are informative. And even then, not everyone religiously watches chat or issue boards, so monitoring what your teammates are doing using that mechanism doesn't work for everyone.
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.
Shouldn't you also see the pushes everyone is making to their upstream branches and the Pull Requests?
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.
The daily standup, if people actually stand and if it's timeboxed to 15 minutes, is the least broken thing in all of Scrum/Agile. Honestly, I think it can be a good thing.
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.
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.
I worked for a few years in a company that did salutary scrum, which is to say that we shoehorned our developer-led process into the correct buzzwords and cargo cult practices to make the management think it was Scrum. That was the best job I ever had. I was very sad that the company was purchased by a larger company with a history of annihilating their acquired development teams without thinking. (That practice actually called into existence one of their current major competitors, as an example of the Batman Effect in action.)
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.
The author sounds like someone who doesn't want to communicate and would prefer to stare at a screen all day.
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.
While I broadly disagree with the OP, I don't think this critique resonates.
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).
There is some stuff on the edge of my perception and interest that I don't want to hear about immediately.
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.
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."