Hacker News Reader

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."

Joe: "Nothing to report."

It's over in 1 minute.

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.

simple things like updating the board are done at best inconsistently

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.

"Nothing to report" is both longer and more boring than saying "quack" and having it received as "I have nothing to report."

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.

why not an internal blog or wiki? Or a compromise, someone transcribes essentials from the standup to the blog or wiki.

Internal wiki hits the same problem as email (although partly because companies always seem to choose terrible wiki implementations (confluence)). Too much information goes on there, terribly organized, and no-one ends up being able to find anything. Mostly these kind of things are immediate announcements that need to be acted on once and never again, so a semi-permanent store isn't appropriate; also the whole point was that everyone needs to be notified, but people can't watch every wiki change.

Blog I haven't seen tried, but I imagine it would hit the same problems; either you notify everyone and have the same problems as slack, or you don't and have a big risk of someone missing an update.

I figured out a work-around. Before I go to my appointment (or vacation day, etc.), I go to the meeting board and put a big green check mark next to all of my completed tasks.

This has an amusing side effect: For some reason, even if I attend the stand-up after all, nobody debates my completed tasks with the big green check marks. So I now do this before every stand-up.

Sounds surprisingly similar to some of the worst meetings. "Nothing to report" is just as meaningful as the assumptions about the knowledge of everybody else it builds on are not entirely wrong.

I guess we are drilling down to the similarly fundamental yet pointless truth about communication: it's easy when it is working well.

Surely if there are any "heads up"s they should be emailed to the team as soon as they happen. What's the point in waiting until the next morning to tell everyone that the test databases have moved?

>> Specifically, if you have a team that doesn't communicate effectively on a daily basis,

I concur. My people don't communicate very well and have no real team spirit. The stand up meeting helps to alleaviate that.

Of course, people who "don't communicate" and "have no real team spirit" are not fit for Agile and stuff, but that's another story :-) In my case, Agile, having frequent deadlines and frequent stand up meeting, helps me a lot to maintain a soft pressure on people. I don't like that (I'd prefer a team of super motivated people), but that's the best I can do. Having a more formal method like RUP wouldn't help because the analysis/coding cycles are too long. Having a kanban could help a bit, as Agile with such a team feels a bit artificial.

I can only go by the 4 sentences you typed above. But you don't come off as an inspiring person to work for.

"My people" are all terrible and need "soft pressure" to succeed....

"It's not that these managers are incompetent or bad-intentioned"

+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've used word "replace" in another comment about pair-programming. It feels now that it's a trend in "cargo-cult-agile" to somehow inverse agile manifesto principles. E.g. replace understanding of how team should work with a formal sertified scrum process - "you do iterations, standups and stuff - you fine!" Burn-down carts and sheer numbers of closed tasks disguise real state of the software being developed(just create more tasks and then split them to create volume).

> Specifically, if you have a team that doesn't communicate effectively on a daily basis, then the standup gives you -- the manager -- a place where you can get and keep your developers on the same page.

The standup should not include the manager as a participant; that's broken. The standup is supposed to be for coordination among the team, not status reporting to the manager.

Isn't the manager part of the team?

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.

Maybe for single-team scrum projects, but if you have one manager per team you've got way too much management.

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.

EDIT: phrasing

> 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.

I just had a weird idea.

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!

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'm not sure whether I'm replying to heavy sarcasm or not, but the Cambridge Computer Lab has exactly this as an organised thing for many years: http://www.cl.cam.ac.uk/~mu232/random/teaclub.html

It's a lot easier to be collegiate in a college.

No sarcasm. Cool to read about!

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.

why if your doing real Agile DSDM/RAD all of the stake holders should be in (or represented at) the daily meeting!

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

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