wonderful article, both entertaining and educational. helped to pass the time during my hour-long stand-up.
The only times where I can actually pay attention is in meetings where I have the right to (and it is conducive to) constantly interrupt with questions. Then my brain suddenly sees the information as useful because I'm looking for opportunities to say something.
* Control people who talk for too long or go into detail that's not worthwhile
* If you have a board, run through each ticket in progress/in review for a casual update, record it as a note
* Have an icebreaker (1 minute) before or after, ie "fun fact of the day" or something and randomly choose people to do it
* Ends with a section on anything else to add, if anyone is blocked, whatever, and have people break out into their own meetings if necessary
* If it spills over 15 minutes then continue to trim down on the update complexity
This business of hour-long standups sounds insane and so wasteful. If it's taking devs that long, it sounds like something is missing elsewhere.
Here are some questions that might help identify the problem. Are you using a good ticket/issue tracker? Are devs talking/collaborating during the day? Is there a sense of group ownership of work done? Is there a tech owner/point person for each epic/larger unit of work? Are you breaking tickets down into small pieces (no more than a few days of work each)? Do devs discuss implementation plans regularly? Are business requirements clearly communicated? Do you practice continuous delivery (release each ticket directly to production when done - if need be, behind a feature flag)? Does the business optimize for DORA metrics? Do dev teams own decoupled vertical slices of technology?
There's just no fixing that.
The media has been proclaiming "Agile is dead" recently. I wonder if all these tech layoffs have come simply because that hour was gained back for productive use?
All that while devaluing or ignoring the power of individuals and interactions and responding to change.
It turns out that who you hire, how they interact, and how productive you allow them to be have far more power to create value than applying certain "Agile" processes and tools.
I feel like having to resort to tricks to keep people engaged in a meeting is a good sign that the meeting isn't a good use of time.
This goes for all meetings (and literally all roles in all workplaces even outside of tech). It's there to build first hand understandings and empathy and, if these meetings are a waste of time, empowers the entire team to change it or abandon it.
For the past 10 years I'd say most of my standups have been painless, quick, and productive, but I've both selected good jobs and/or worked with the team for that to be the case.
Mine usually don't last more than 10-15 minutes, no one has to read ticket by ticket and give detailed status updates, we simply look at 2 columns on the board (for what's in progress and what's in waiting/blocked) and ask: "anything someone want to bring up about these tasks?" to have a sanity check if everything is alright or if someone needs help, or if someone wants to share some quick information. After there's a general question "anything else you want to bring for the standup?" for the stuff we don't have a ticket for, or quick updates from PMs/EMs about things outside of our current scope/context.
Any further discussion is taken after the standup, if some topic starts to grow into a discussion we are strict about bringing it for discussion with the interested ones right after the standup. Those discussions never last more than 20-30 min, if they need more time we schedule a meeting with proper agenda, etc.
Whenever I worked at a place with dysfunctional ones I either managed to help correct course, or quit the job.
To me teams with good standup hygiene will very likely have meetings/processes hygiene as well, and is a very good signal of a well functioning team.
The thing I hate most is sprint planning and refinement. People make such big deals about everything and it can easily last over an hour. I especially hate all the drama about making sure our workload is right and moaning about how long things will take and politics and such. I'm starting to think it's some sort of cult of unproductivity ever since the senior frontend guy said that an angular upgrade would take us 2 years and loads of seniors so it's not worth starting this year. It's a massive load of version but ain't no way that's gonna take 2 years and that we can't do it with the one senior frontend, one mid frontend and one junior fullstack (me).
sadly it took me years to understand that this is a perfectly valid solution.
But damn, that's so hard to do (at least to me :-))
I try to push for people to actually stand up during a stand up, because that encourages the meeting to be short and to the point, not an hour of pointless waffle (and if it's an hour long meeting, waffle is probably an apt description).
It was brutally effective, especially those who went last sounded like a new Eminem single. Standupps went from >30 to <1 minute immediately
I propose that whoever is talking must stand. This punishes people who get into details of their task, and nobody else.
Having a good product owner is important for coordinating meetings in general. Standups should be for tracking progress on tasks and nothing more. If someone is blocked they should briefly state why and follow up ASAP, but after the standup.
Then what's the point? I probably don't care about someone's status in the first place, and when I do a big fat notification informs me when the status has changed the second it changes. "Duh. I'm still working on it, obviously." doesn't tell me anything.
> If someone is blocked they should briefly state why and follow up ASAP
If someone is blocked by my doing, they would have already told me 23.5 hours[1] before the scheduled meeting came around, when they became blocked. I don't need to hear it a second time. If it has nothing to do with me, I don't care. What's the point?
[1] Or even longer if not on a daily meeting schedule. Way too long if you sit around and wait for the meeting to finally come around before talking to anyone.
The daily standups are for management and whoever else is invited from time to time. You're 100% correct that you shouldn't wait for tomorrow's standup to discuss something technical with another developer. You shouldn't be getting lost in the weeds during standups anyway. That's one of many reasons standups can take forever.
Also, a well run standup can be as simple as one person sharing their screen while walking through the tasks and asking yes/no questions. You don't need everyone to speak all the time because as you said that wastes time. Anyone can read the issues statuses at any time or query what they need.
These meetings are for more insightful questions than that from management: "You and a couple of other devs on this story said your tasks are blocked because this servicenow ticket for another team is still in progress? I've reached out and they said they're going to be done by noon. Will you complete your in progress tasks by then or should we reassign or push their dates back so you can continue this higher priority ticket?" ... "Great I'll update the backlog for the sprint starting next week and your time in the capacity tracker" ... "You scheduled PTO? We've got everything all set for the next sprint so no worries. Have a nice vacation!" It's not a dream. Agile done right is like this.
If you hate the idea of a meeting like this it's possible your managers suck and don't listen to you. They're supposed to be working for you to keep the runway clear. When they hear all the status updates all at once in daily meetings they should be getting ready for the next sprint and coming up with good ideas behind the scenes. That includes bringing in resources, making sure dependent tasks on other projects are completed so you don't get blocked, etc.
Granted, that waste keeps people employed. The tech layoffs of late is unquestionably because "Agile" isn't cool anymore, and those hours wasted to standups are now, by and large, put to productive use instead.
That doesn't sound like Agile, at least not the Manifesto one. Agile is pretty clear that there are no managers. It, ultimately, offers suggestions of what you need to think about if you are to move to an ad-hoc organization structure. For instance, per the 12 Principles, "Business people and developers must work together daily throughout the project." There is no room for a manager in that. There is no independent "keeping the runway clear" or "coming up with ideas behind the scenes". That's the work developers and business people are doing – why they are working together.
Here's a few more:
* "Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale." – Translation: Without a manager keeping tabs on everyone's progress, the easiest way for the team to stay on top of progress is to see it.
* "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done." – Translation: Don't accept people into your group who need someone (i.e. a manager) to hold their hand.
* "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation." – Translation: There is no manager ensuring everyone is aligned and on the same page.
* "The best architectures, requirements, and designs emerge from self-organizing teams." – Translation: With no manager to organize the group, you need to figure out who is going to do what on your own.
* "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." – Translation: You don't have a manager watching over to see where improvement can be made. Figure it out for yourselves.
Whether or not Agile is suitable for your organization, or any organization!, is another matter. Indeed, one should not accept Agile into their life just because it has a catchy name. Probably not at all. One must remember that the Agile signatories live in a different reality to most developers.
> If you hate the idea of a meeting like this it's possible your managers suck and don't listen to you.
Whether or not they are listening, I'm not sure what I would want to tell them? What I do know from many, many years of experience is that when you have a good manager, you won't even know they exist. A manager who needs to gather the group around the campfire each day is decidedly not a good manager. Heck, even most staunch standup supporters will tell you that managers shouldn't be invited to the standup as it easily becomes a crutch for bad management.
Standups shouldn’t be a rubber duck session with the entire team.
And, of course, fantastic use of alliteration.
And I thought my organization was dysfunctional.
> standup
what
(For those who aren't looped into the irony: the entire reason why it is called a "standup" is because you are supposed to stand up to create subtle pressure against long unnecessary meetings. Sitting down for a stand-up isn't just a quirky paradox of jargon-meets-reality, it is a fundamental rejection of the entire premise while cynically parroting the terminology itself.)
My stand-ups are 10-15 minutes, usually. When they use the full allocated 30 minutes it's because somebody wanted to dig into a specific topic (and anybody not interested in that topic is free to leave).
This is a normal agile development team - 1 manager (me) and ~6 engineers. We do the quick round-robin update, I'll make any announcements or ask for clarification, then if there's something that requires it, a deep dive (as deep as you can get in the remaining time).