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.
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.
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." 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.
" 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 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.
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.
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?
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.)
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.
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.)
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 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.
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.
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?
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.
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.
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 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.
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 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.
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.
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).
"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.
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)
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.
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.
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.
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.
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 ter...
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.
> 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.
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.
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.
> 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.
> 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).
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."
> 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.
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 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 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.
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'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
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.
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.
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.
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?
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,
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.
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.
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-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.
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.
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.
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).
> 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.
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 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.
167 comments
[ 5.3 ms ] story [ 291 ms ] threadWe 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).
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.
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.
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.
[0] http://mobprogramming.org/
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.
http://en.wikipedia.org/wiki/Betteridge's_law_of_headlines
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.)
* Stuff you deemed important?
* Stuff the team deemed important?
* Stuff the customer deemed important?
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.
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.
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'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.
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.
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 ter...
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...
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 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.
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.
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! ;)
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.
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).
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.