First, let’s stipulate that lots of people don’t know what they’re doing or why in technology development. Unless you’re coding, it doesn’t really feel as if something is going on, i.e., it’s a waste of time. In most cases, it is. Your instincts are correct.
Second, I did not finish reading the article. I did not finish because the author doesn’t know what they’re talking about, or rather he is responding to the way he’s been taught and observed stand-ups happening, not how they actually work.
”…The majority of meetings are a waste of time. And in my opinion, one flavor of meeting that tops the charts in uselessness is the “status update” meeting. You know this meeting— the meeting where everyone gets together to share what they’ve been doing…”
Yes. Shoot for meeting-free work areas. The way you do that is dynamically get together and talk about stuff as needed. The way you do that? A stand-ups. Stand-ups are the (in my mind) only fixed time and place where everybody gets together and asks for help. You don’t give status, you don’t report to anybody, you don’t ask or answer questions unless you can’t make out what the person is saying. You just take a minute and verbally review where you are and ask for help if you need it. Then we get to work. Maybe somebody has a problem that is going to be huge, so we hang out for an hour or two trying to solve it. Maybe nothing’s going on. Great! Two minutes later we’re all working on our own stuff. Works either way. It’s dynamic.
The problem here is 1) people are used to status reports so that’s what they gravitate towards doing, 2) there’s pressure to build-up your work and deny having any problems, and 3) when it’s working right there is no positive feedback. It’s like brushing your teeth. You do it, it’s quick, and if you’re doing it right you never think about it. In fact, the more you think about it, probably the worse you’re doing it.
In my experience, unless time limits for people talking are heavily enforced, they are largely a waste of time. If no one is willing/able to enforce hard limits for the amount of time any one person has in the stand up to talk, you almost always end up with senior people on the team who enjoy listening to themselves speak taking up 95% of the time, with the remaining 5% of the time given to those who need real help.
Yeah they can go wrong in a lot of ways. Turns out having people talk to one another isn’t as simple as writing a for-next loop (grin).
One of the fun things I used to do when teaching standups is a game where a team has to do a standup, but one person is the “ringer” – they’re given a dysfunction to display and the rest of the group has to deal with it. I found it was much easier to teach dysfunctions when people were only playing as opposed to directly addressing them.
There’s also the guy that has to question everything, the one who never needs help, the one talking about nothing to do with work, and so on.
That’s a fascinating approach. Thanks for sharing it.
Personally, I like having a daily standup because I get to see what everybody is working on and which tasks are getting pulled out of the queue, which gives me some idea of what I might work on when I finish my current task. Also, reporting what I’ve done the previous day ensures I pay attention and keep track of it. Don’t know where the author gets the idea that blockers should only be brought up at standup. Common sense says to email or message the person or team blocking you immediately - bringing it up in standup is a secondary thing to explain why you’re working on a different task or to see if anybody on the team knows a work around.
Also, I’ve always considered the argument about standups interupting productivity to be a little disingenuous. Few (if any) people are really being productive 100% of their working day, and it isn’t a big deal to plan around a 5-15 minute meeting when you know it’s going to happen every day.
Am I missing something or did the author just restate classic manager techniques as if they were novel ones? I didn’t notice any suggestions that I didn’t already assume a manager was doing in the background.
It’s the circle of life. Young dev starts working. Young dev is so smart and everyone is dumb. Young dev points out stupidity of things not understood. Young dev ages, convinces others to stop stupiding.
It’s hard for people to understand everything that’s happening and what’s not visible directly and immediately. Some people assume that stuff is unnecessary. Sometimes it is unnecessary.
I look forward to OP’s blog post in 10 years about whatever wonderful communication meeting technique. Or OP goes into consulting and writes a post every month on the subject.
I think it’s wild reading Brooks’ Mythical Man Month that was written 40 years ago and same themes still apply.
Agile-style standups certainly don’t seem useful in the environment the author describes in which products are launched infrequently over large time periods, one of the main things an Agile practice avoids doing. A daily standup is much more useful when paired with sprints or short-term focused development.
This person seems stuffy, talking about what you did over the weekend does help you build good products. It builds team emotional interactions. We are humans beings, and adding in casual updates helps us to understand and read one another. I worked at several startups without daily check-ins, and this person seems like they suffer from hero complex.
“The majority of standups are short, yet often meander into casual conversation where people talk about things unrelated to work, like what they did over the weekend.”
I suggest renaming the article:
“Why talking about our weekends instead of status is useless, and how to run great product team meetings”
I found the argument so poor, I am a bit…
I agree with the gist of the post. I think focusing on things that unblock or catalyze completion of the project (blockers, decisions not made) is a good idea.
The main value that I think standups could provide is sharing of information that is explicitly selected or filtered because it is identified as potentially useful to others, like: pitfalls discovered in code, an upcoming maintenance window, a new hire, blockage of a card which needs specific person P to take action X.
Something I think should be asked of any given meeting: Can we achieve the same purpose or derive the same value as this meeting by way of async tech instead? (email, Slack, SMS)
The only times I have seen the theory that standups should just be “status meetings and no discussion” is when they’re done via Slack or Basecamp’s check-ins, not meetings.
Tag proposal: Why you should stop doing X
You should care what they worked on yesterday because it might fuck you over today. If nobody’s work meaningfully interacts why are you even on a team?
When people complain about agile being nothing but a buzzword-laden wet blanket thrown atop their otherwise superior capability for productivity, I posit that one or more of these is true in their organization:
Management doesn’t “get” agile and sees it has a process to follow for increased productivity rather than what it is: a prescription and framework that values flexibility, communication, iteration towards improvement, and general open-mindedness. (There is no “right” way to do agiile, but there are plenty or wrong ways to do it.)
Even if they buy into it, management is not properly supportive of agile and won’t dedicate the time, resources, flexibility, or even change in business practices required in order to be successful with it.
The biggest one: Agile requires a certain kind of team culture. If everyone (or even anyone) on the team thinks of themselves as some kind of superstar lone coder, you won’t be agile. Many of us are in this profession because we have strong introvert tendencies but agile requires an almost uncomfortable level of cooperation and communication with the rest of the team. Even and perhaps especially with people you don’t like very much. Some kinds of personalities are not cut out for this, and this is not a knock against them, but they may not necessarily be a good fit for an agile team.
A final somewhat obvious observation: It is way easier to start a team with an agile philosophy than it is to convert one to it. Converting a team to agile can be done but it’s a painful process to ditch well-established processes and habits that “have always worked just fine for us in the past” in favor of experimenting with something new.