Why your daily stand-ups don't work and how to fix them
lucasfcosta.com
lucasfcosta.com
The amount of process and ceremony required is inversely proportional to the trust level on the team.
Once we had some difficult conversations and realigned expectations, we found our daily standup was extremely redundant. Team members began to realize that others would simply reach out as needed. Everything is much more async now. Only 3rd party interactions require explicit scheduling these days. Prod down, vendor integrations, etc.
Other observations: We seem to somehow spend more time on adhoc calls than our prior scheduled calls, but A Lot More (tm) is getting done regardless. Stress levels seem down as well. Weird how you can have cake and eat it too sometimes.
I don’t know if I would sit here and proclaim that process is exclusively a bandaid for lack of trust, but it certainly seems like one indicator of this condition.
It even went as far as some people having two standups a day, one with their own scrum team, and another with the "leaders" of other scrum teams.
Our scrum ceremonies were always stretched and highly moderator, except for the one that mattered, the retrospective. This was always hijacked by the agile coach, who pushed his agile believes and wouldn't listen to the actual developers who were trying to improve the process.
Obviously following agile to the letter, caused a lot of frustration amongst developers, and lead to almost every project failing. But at least the coaches got paid well.
It really gets quite tiresome, especially since if I needed something escalating I'd have asked them already, and I'm perfectly capable of moving a ticket myself.
Instead I just disengage for the hour and half of standups I have per day (yes, I know)
I remember my previous employer trying that out in one or two departments. Ultimately that company landed on SAFe Agile and it was a complete and utter shit show.
Where I'm at now is "doing" Kanban but the standup is really just a daily status update. I'm slowly getting the management to recognize that these things are problems, why they are problems, and what can be done about them. But I'm much happier with this situation because I can actually push back against it and try to improve the thing. At my previous employer, any attempt to even begin highlighting problems would render you standing alone against what amounts to a committee of management (in this case, specifically, people who are only employed because of the fact that they use these extremely heavy processes) if you wanted to discuss these things.
Otherwise what you have, and I’ve seen this in multiple places, is developers getting blocked by DevOps constantly, so basically setting up “shadow” infrastructure to try and work around the problem.
I never saw scrum master who is doing only scrum stuff myself but from what I read on the internet there are people who saw it.
The latter will typically get managed out or even fired.
There doesnt really seem to be a way to square this circle.
It was somehow hilarious to watch him weasel his way out of missed deadlines and failed project. Every developer ended hating him, since developers got the blame for everything, since we didn’t follow his idealistic view of agile.
Ideally you should quit if conditions make your job impossible - that being the economically "efficient" thing to do. But mortgages, kids to feed and the everpresent reality of the capitalist system often prevents one from doing that.
I went from a company which adopted agile after I joined, to an older company which has never adopted agile.
My current take is that without agile, there's no process to improve. Well, yes, but not on a bi-weekly basis.
We are grown-ups, things work, brokenness gets raised when needed and there's no heavy process crushing people to fix.
Replacing one dogma (waterfall) with another (dogmatic agile), is not agile.
Larger organizations with significant turnover, such as government bureaucracies. Sub-groups of the organization rely on process to interface with each other.
Guild-like organizations that work on individual projects with changes in team composition. Showing up to a new jobsite with people you haven't worked with before means less trust than you'd have on a team that's been together for a while. Process is the glue that keeps things functioning.
I'd rather work on a small team in a high-trust environment, but such a thing doesn't often scale well to large projects in every industry.
When the team evolves to value for team success over individual, then this sort of things is obviously more efficient because everyone is actively engaged in keeping everyone in sync. So I think it is much more about a mature and cohesive team than trust explicitly. However, ime, there are always some who just want to play whac-a-mole and be "done" even when it isn't in the team's best interest.
True! Though usually the mistrust is management of the team.
> Once we had some difficult conversations and realigned expectations, we found our daily standup was extremely redundant.
And conversely, when the team isn't communicating with one another, that's when introducing standups does the most good. Managers wanting to micromanage leads to heavy process.
The second company (that I still work for) is a large tech company, and there is almost zero prescribed process (at least for the teams I’ve been on; can’t speak for the entire company). Counterintuitively, everyone seems to be vastly more productive. In terms of process, the most we might do is to put together a loose project roadmap in a Google Doc or something, but that’s about it. There are no stand-ups. Superfluous meetings are discouraged. I have a weekly 1:1 with my manager to ensure my work and goals are aligned with the team priorities. It’s really nice because I feel like I actually have room to breath and get things done rather than attempt to “have something ready” for the standup the next day.
At my first company, I arrived there as early as I could in the morning and left after exactly 8 hours. At my current company, I don’t have that desire to finish up the work day as quickly as possible. Although that might also have something to do with the second company rewarding performance and impact much more heavily than the first company—hard to tell how all of these different incentives influences employee psychology and behavior.
We have 2 meetings per week, all in the same day.
The rest is intra-teams communication without management butting in.
Everyone is extremely productive.
Why people think that daily standups are useful is beyond me.
95% of the things in the 2 weekly team meetings that we have is already useless for most people (but having everyone there is useful since otherwise you're just waiting to ping someone to respond, you zone out anyway if the topic is not to your relevance).
What really surprised me at the corporate was how much they love to TALK about Agile. We had Agile Coaches, an Agile Centre of Excellence, dedicated Scrum Masters (literally their entire job), Agile Squads to try and improve the Agile Process, mandatory Agile Training and we constantly talked about how things were Agile and if we could be more Agile.
They even experimented for a quarter by adding a mandatory agenda item to every single meeting to review how Agile we were and what can be done to be more Agile.
We got absolutely nothing done. Progress was glacial, decisions took months, it was painful to do anything.
In contrast, at both FAANG tech companies I'm not sure I've ever heard someone say the word Agile directly. It just happens by default, no ceremony and rigour required. Shit gets done, at pace, and people are excited and motivated to do it.
Gist of it: FAANG is very flexible as long as things get done (hinting at really understanding how things work), large corps somewhat flexible between teams (understanding in principle how it works but still being big corps) while start-ups stick to one methodology (sticking what some founder knows, or thinks to know). Brackets are my interpretation.
Based on what I saw in the last year in my current job, that rings true. Agile is the latest shit, so we aoply it to everuthing, from hardware development to ERP roll outs. Not sure if in those two cases it is the right approach.
- most FAANGs are using either informal or formal mini-waterfall SDLCs (i.e. starting with small upfront design/product/marketing document).
- most non-tech enterprises and consultancies are using Agile/Scrum
- startups are somewhat in the middle
There is a google sheet with the detailed list of companies and their SDLCs.
Lastly I do agree that SDLC should be adapted to company size/stage and the industry/vertical.
I.e. don't use Agile/Scrum/SAFe over waterfall/RUP for mission- or safety-critical software (i.e. missile, aviation or automotive). And don't use waterfall/RUP for in-house enterprise software over Agile/Scrum/SAFe, etc.
Use something like Shape Up for a small web SaaS product, use EventStorming for a bank or insurance company, etc.
... but you still got invited to weekly meetings to be questioned on why you weren't meeting your quotas ...
There were multiple daily standups, weekly standups, twice-monthly retros, monthly project updates, bimestrial project updates and quarterly workshops and offsites.
Which meant once a quarter you had at least 2 solid weeks of nothing but sync/update/standup/retro meetings to talk about the work you talked about planning to do, but failed to do because you spent all your time talking about planning to talk about planning to do it.
It doesn't have to be the same person for everything, but having a single designated person to own each decision avoids meandering too much when you're uncertain, or getting blocked by debate when you're confident.
My favourite leaders have come in and quickly said "you guys spend too much time talking about making a choice, X is in charge of this decision, move on".
We had ONE meeting per week, every monday morning, where everyone told what they achieved the past week, what they planned to do that week and the department head handed down news from corporate to us (planned expansions, transitions in corpo IT etc.). That meeting took about 60 minutes and we were then all on the same level for that week with finer coordination done as required by specific incidents/projects.
Haven't yet worked in another institution with such a process but from my limited POV it worked really well, whereas daily meetings to reiterate the same things every, single, day sound like such a waste of time.
> there is almost zero prescribed process ... Counterintuitively, everyone seems to be vastly more productive.
I've never been on a team that was so disorganized that we needed to have a standup every day. I've also never had tasks where you could always make progress in a single day. Meeting once or twice a week matches the meeting frequency to how often things really need communicating (beyond chatting in slack), so the meeting gets used effectively. Meeting every day just trains people to filibuster, and that's a big reason that the meetings stretch out to hours.
I do believe there are teams that get blocked on each other every day and who have tasks that take a few hours to finish. Never been on one myself, but I'm sure Scrum works great for them.
It is a shame because all of the corporate processes are designed simply to overcome poor and ineffective communication. If only we invested in teaching people how to communicate instead. Where I am now, they have switch to SAFe which is the least agile process I've ever seen. Planning 3 months at a time is the opposite of agile. It is really just parallel waterfall that is run as "agile" day to day. It is useless. But the higher up want their meaningless GANNT charts so here we are.
If everyone's communicating and collaborating and effective, suggest trying an iteration without standups. Then compare effectiveness of the two.
Unfortunately, going to once a week or twice a week means teams will tend to drag them out for longer. They become more like discussion meetings or "status" meetings rather than super brief snapshots of the plan of attack for just one day.
We don't use it for planning or detailed discussions. We don't insist on a standup structure, or what must be discussed etc. We just find it useful for greeting each other, sharing context and checking if anybody needs help.
We experimented having no standups(to be completely asynchronous), but we didn't like that and felt it's worth the effort to catch up once a day.
We use a Slackbot to ask everyone for a written standup update, answering a few questions:
- What did you do on your last working day? - What are you doing today? - Are you blocked? - Would you like a conversation with anyone (to get unblocked or anything else)? - Any announcements, like PTO?
And that gets posted in Slack at a certain time. The goal of this is transparency for what folks are working on, giving people the opportunity to raise blockers, and announcements.
We then have a scheduled 15 minutes a day to just hang. We have a check-in question that's not work related and we use the time to socially connect. We are a fully remote company that used to be in-office, and we found the opportunities to build & grow these connections are not available in a remote + scheduled Zoom world like they were in office.
This sounds awful to me. Not sure why it would ever need to come to that: forcing people into a room every day and telling them to connect with each other. It just seems forced and phony.
You already work together full time, and I assume you interact with each other as a normal part of your work? If not, maybe you aren't really on the same team, in which case why not invite accounting and HR into your social time?
When you lose it and you feel the blame starts shifting your way your tendency is to set up more control and visibility. Here comes the daily standup and jira board of tasks. You lose even more flow as yoir team spends majority of time estimating and administering tasks in real time so that when you look at it once a week, it is semi-up to date.
What you were looking for in the first place were to discover obstructions to the flow and finding process bottlenecks. You want to find out that one person that everything depends on to move and everybody slamming them with tasks and now the extra task tracking. You want to find out why that important task is not getting finished because the person is getting blocked on some infra problem and instead of reporting the blockage to you they pick up another task from the queue. Why would they report that if the only thikg you desire reported is what everybody ia working on - the important blocked people will always tell you they are busy enough as they found something else to work on.
As a manager, how are you expecting to get any outcome if you never find the workplace bottlenecks and you only demand pople to get busy.
I think blocked on a high priority task is exactly what scrum with daily standup is sold as surfacing.
A 'daily standup' seems sort of the lowest-common-denominator way of surfacing that. someone recognizing on their own, and reaching out to raise a flag is one way. 1-1 checkins more frequently with those working on larger items would be another.
Well said and exactly the psychological state one feels when participating.
> someone recognizing on their own, and reaching out to raise a flag is one way.
100% agree
Note that the OP has this blocked developer not announcing the block of a high priority item, but rather just pulling another item from the queue and making progress.
Depends on the person and the instructions, but I guess it happens.
1-1 also makes sense to me. That said, I can picture the manager after back and forth playing telephone with blockee sand blockers, believing that an efficient way to handle this is to have all the relevant people in one spot.
And... it likely is more efficient in those scenarios. If something can't be resolved via 1-1 in less than, say, 3 exchanges, get everyone together for a synchronous meeting. But have that be the exception.
Not to mention said manager is (for some reason) laboring under the false assumption that most useful software development tasks can be accurately estimated.
Good morning! Don’t forget to post your update in thread.
Be sure to include:
1. What you worked on yesterday.
2. What you plan on working on today.
3. Any blockers or risks you have identified.
People usually reply there whenever they start working, and everyone knows what everyone else is working on. In case of blockers, people who can help get a nice reminder of an upcoming meeting, so they can plan their day accordingly. Honestly, the blockers bit was the only useful thing for most of us there, but it is nice to know what others are working on.
Then we have a 30-45 minute video call stand up/review/meeting once every week/sprint, to summarise things and to accommodate for the much needed rambling.
What kind of blockers were did you find appearing at the start of work for there to be usefulness derived?
I have only ever experienced blocking situations once I am well into the work. And, as tempting as it may be to take the rest of the day off so you have something to tell at the start of the next day, that's not exactly a realistic business practice. Any blockers that do occur are dealt with at the time, leaving nothing unaddressed by the time the next day rolls around.
Certainly blockers need to be communicated, but timing them with the start of work seems completely untenable. If they could be foreseen they wouldn't be blockers.
You must not be working with micro-services then. It can take a week just to get permission to call another team's API or a month to get an external vendor to respond to some critical question. Now obviously I am not sitting idle while blocked, but assuming that blocker will be removed by next morning seems quite unrealistic and rarely happens in my world.
Territorial people don't last long here.
I can't remember the last time I was really blocked by an other team. It's incredibly rare. They either help or get out of the way.
Generally we don't go walking through other teams code bases unless we have to and we usually consult with the team before doing stuff. They just don't let their roadmap block our roadmap.
We don't use microservices. That helps a lot. We also have teams that manage infra. We do own the code we deploy but anyone can jump in and help if a fix is needed.
Sure, but you are still unlikely to realize that you're blocked by that exactly at the start of your day. Once your blockage has been communicated, likely in the middle of your day, the state will remain until you are unblocked. There is no value in repeating every day that you're still waiting on Outside Vendor. The blocking state has been addressed. It is known that nothing will change until the state has changed.
And it is not like Outside Vendor can update you in an internal stand-up on why it is taking them so long, given that they won't be present, so you're not even getting that value out of bringing it up again.
1) Waiting for someone review and merge a pull request so something else that depends on that can be sent for a release.
2) Some architectural code changes that needed to be discussed with the person responsible for the module before i go ahead with the implementation.
3) Someone waiting on me to finish the CI setup so they can deploy their project
4) Us waiting on external client for more input, so our CEO can go nag them for more requirement updates.
5) Me hoping the someone can fix the frontend code because i was frustrated with my (lack of) CSS knowledge the previous day...
I've worked under that "today/tomorrow/blockers" regime before and never once, in the years we labored under it, did anybody report a single blocker besides "my computer crashed, waiting for IT to fix it".
everyone can see it on issue tracker
> 2. What you plan on working on today.
everyone can see it on issue tracker / Kanban board / etc.
> 3. Any blockers or risks you have identified.
for any blocker/risks I'll encounter, I'll send an email (and file bug/issue/ticket) immediately - no need to wait until the next morning.
Why do we need to use tools that less (or no longer) technical people can understand, if we still required to duplicate this data in email (or god forbid in actual meeting)?
This only makes sense under SDLCs which don't require detailed task breakdowns, like RUP, mini-waterfall, or Shape Up. But Shape Up provides some good solutions for risk management/status updates (e.g. Hill Charts [1]) without going down to daily standups.
--
[1] Hill Charts
https://basecamp.com/shapeup/3.4-chapter-13
No matter how often it gets repeated, not everyone bothers to update the board, while for some psycological reason most answer on messaging apps.
I don't think this is necessarily true. If an engineer is blocked on a difficult problem for a day they don't have time update issue tracker to say they are blocked.
If that's a psychological issue, not sure daily standup can help here, unless the PM/SM will try to interrogate that person, or try to guess if somebody is blocked.
It's best illustrated by the author's failure indicator "If the manager or “scrum master” can’t show up, the stand-up doesn’t happen". That's so very telling.
The alternative approach of the chat reminder tries to minimize friction (short writeup is so much easier to consume than trawling The Board) instead of forcing everybody to be present (and presumably listen, which does not necessarily happen)
Some of us do care and see the big picture of things, but that mostly limited to tech/product companies/startups, much less so to enterprise employees, or agency-supplied contractors.
I.e. it boils down to incentive alignment, and to a lesser extent professional curiosity.
> "I don't care what you do, that knowledge is a distraction detrimental to my own work."
Agree, so it doesn't matter whether this distraction is done by issue tracker, email, or an actual meeting.
At least in the issue tracker case it's stored in a structured database which I can easily query (even programmatically via API/bots), and much less distractive than in email/meeting.
Only if you have a perfect board, no things ever come up out of order, a be everyone has the same idea of granularity. In practice, no, that information is going to be either unclear or wrong.
If it's not, there should be something to discuss in retro.
Use it as a signal, not the signal.
This is the thing about daily stand-ups which I hate the most. I work as a freelancer which requires me to do a dance around social expectation everytime I get on with a new project.
Oftentimes I work with full remote internal teams which are used to dailies in the morning, even when a substantial number of team members hate them. The (private) feedback I get when I'm the one who tries to reschedule them later in the day at the kick-off meeting is very astonishing.
I simply don't get why even many relaxed employers don't realize that dailies in the (early) morning can be a very good way to reduce overall productivity and sometimes even set wrong incentives.
I know a good share of employed people who only came to terms with early stand-ups because it means they can clock in early without doing any meaningful work for the first hours of the workday. But I think it's just fair that those employers with proclaimed "flexible hours" pay them for involuntary getting up before their time. Make me get up early, pay for my breakfast time. Or just stop pretending that you have flexible hours.
Personally I think the solution to this is obvious and apparently so do many others here. Daily standups within a mostly stable and well-functioning team are almost always redundant at best and actively disruptive at worst. So don't have daily standups. Instead work on a culture where people communicate freely whenever they need to and you bring people together for larger and longer meetings when (and only when) you have a specific reason for that.
I'm always a bit amused when Product Owners are suprised that there's nothing to clarify at a daily since the team is constantly transparent towards each other about blockers etc.
True. Whenever I've done freelance/consultancy stuff in the past my rule has been that if a client invites feedback then I'll test the water once. If they're receptive I'll elaborate. Otherwise I'll usually drop any process-related feedback and fit in as well as I reasonably can with everyone else since IME that is normally the most effective way to work in that kind of environment. It's always a bit disappointing if you can see a client making obvious mistakes and you know how to fix them but sometimes it happens and if they're not interested in changing then ultimately that's their decision and their responsibility.
Our current stand-up has evolved[1] to people posting their done/doing/blockers in Slack each day. We still have a daily 15 minute zoom meeting - which was once a stand-up - but it's changed. Now it's a time-boxed meeting where we shoot the breeze, or play small multiplayer games [2]. The rules are simple - no work chat, no politics. We meet in the middle of the day so people have the morning period to get work done.
Our stand-up wouldn't work for all teams. We've specifically hired people that would work well in our team - and they're thus more inclined to work well with the processes we've developed.
[1]: I wrote a bit about this at https://blog.getchinwag.com/posts/calling-all-remote-teams-s... - though our stand-up has continued to evolve.
[2]: Assembling jigsaws has proven to be quite fun in recent weeks - we use https://puzzlegarage.com/
This in itself is an achievement.
We’ve (so far) never had a political debate. Hope it stays that way Forever.
Most things we do simply aren't political (at least not intentionally, not saying they can't be interpreted by others that way), they're just things we do from being on autopilot most of the time. And I strongly want to give people the benefit of the doubt unless it's quite obvious that they meant some form of malice by an action.
I still have no idea what most of our employees' political leanings are. What is important to me is that they are (genuinely) kind and respectful to each other, have a desire to work together, and that we are solving problems and helping our customers every day.
It's important to me that people have one place they can go to, where we work together as a team to focus on the problems we and our clients face, and come up with solutions to those problems in as objective a way as we can, as fellow human beings. That's the kind of team I would want to work with. And since it's in my control, I'm making it happen.
Not saying everything's perfect obviously, we're all still human, but we do aspire to preserve that aspect of our culture.
That said, having a scheduled 15 minute "hello" meeting every day sounds great! I feel like seeing my coworkers and saying hi is the most value I get out of daily standups, so your team's approach sounds great to me.
Sometimes we do fall into political conversations though - politics being a massive part of being human after all. But when we do someone says something along the lines of "alright guys, this is starting to sound a bit political so let's talk about xyz instead" where xyz is your favourite funny cat video or similar.
Spend 10x more time evaluating cultural fit, and you'll spend 10x less time managing people.
This allowed me to simply trust every single person, and let go of the processes and daily meetings/standups, etc.
Simply trusting + communicating in weekly timelines kept everybody calm and productive.
They're for the developers to keep in sync. For tiny teams (1-2 developers) that's trivial and doesn't need a shared conversation. For 3+ people to try and keep in sync, it's easier if they all get together.
Sure, they can stay in sync other ways, but it's more likely that you lose productivity to people de-doing work, having trouble integrating, and losing out on developer experience when someone takes on a new problem.
The real red flag here is that your team doesn't want to talk to one another on a daily cadence. Sounds like a team that isn't really a team, to me, just a bunch of individual developers being managed by the same person.
Teams >>> individuals, every time.
Why do we even have to have a fixed, recurring meeting? That's equivalent to polling a server periodically and asking "hey, any event happened?" - which is extremely unscalable, and should be done only in situations when malfunction of event-driven mechanics is expected. Same with people - if an employee is trusted, meetings with them should only happen on an event - when there is a change of plans, some new work to be done, et cetera.
We have asychronous communication - so why not asychronous organization?
The next question you might asks is, why other people need to know immediately what other people are working? Why cannot there be a dedicated thread (aka PM) who collects this information and makes it available?
Project management would benefit by bringing concepts from operating systems such as scheduling or task switching.
I agree.
Perhaps this is a good time for a Free Software organizational tool, built on such principles.
Because project managers, who invent these things don't want to make themselves redundant.
It's only by pushing the falsehood that the team is so incompetent as to require handholding from someone who likes moving tickets around that they're able to stay in a cushy job.
The interesting thing is: if Agile was invented by software engineers, how come it ended up disfigured in the hands of PMs, reinvented as Agile Coaches? My 2c theory: because the tenets of the Manifesto do not generate interest on the average developer demographics.
The same reason folk religion often focuses on hard, measurable rules (don't work on X, don't eat Y) instead of the more fundamental abstract ones (treat your fellow man as you want him to treat you).
No, I have not considered trying it out, for a simple reason - I don't control any organization nor work in a management position, so I don't really have a chance to do so.
I'd like to believe that I would try out all those things that come to my mind, if I were to have a chance to do so.
For any real dev daily standups sounds as an idiotic practice.
If you're team is so disorganized that they can't collaborate effectively using bazillion of existing tools, and without hand holding/baby sitting of the "Scrum Master", then it's better to fire everyone, and build a new one.
The most common counter to the idea is "but some people don't communicate because "new/inexperienced/personality". Despite being expected to be fully functional adults in many ways and frequently given far more freedom as kids, status quo management seems hellbent on making adults seem incapable of basic communication in a corporate setting.
I don't necessarily disagree with that notion, but there are a lot of inconsistencies if that's the limit of what can be expected from an adult (Why are drinking, driving and taking on massive loans allowed?). Plus in the context of software development, we can easily set up automated communication frameworks to catch the majority of it.
Not sure if it's a quirk of human nature or the protestant work ethic or whatever but the only time I've managed to inhibit it was by being the most senior person in the room and repeatedly pulling rank.
An ordinary manager's presence will pretty much guarantee it happens and make it impossible to avoid.
Whatever the next iteration of the agile cult is I hope it somehow manages to account for human nature and the nature of typical organizations.
This leaves our 10 minute stand up as a convenient forum for announcements and some virtual hallway conversation.
I've been a professional developer at one major software company after another (including ones that have tried SCRUM) since the '90s, and never heard the term "stand-up" at work until last year. That's a broadcast-news term as far as I'm concerned.
Maybe they've been doing them but not calling them that.
That's so wrong.
I worked at medium to large tech co. since late 90s, and only team leads attended regular meetings. Normal devs only attended very infrequent all-hands meeting (monthly at small companies, or quarterly at large).
Of-course we had meetings, but they weren't dailies, but with specific agenda (e.g. design review, bugs, org. announcement, HR, etc.)
This list is good, but it reads like the product of a person with focus and a low tolerance for others with a different pace and style. I can imagine them getting intensely frustrated with slow speakers, rambling PMs (me) and the like.
Does this inherently make them "right" or "more productive" -Yes, at the cost of possibly burn out, and the lack of cohesion from ideaologues who cannot listen or engage with others in their problems unless on the kanban, declared as blockers.
Its intruding another formalism for the one they don't like.
"don't talk to me this way" is a poor basis for mutuality. Maybe its "a little from box A, and a little from box B" ?
if 10 minutes of engagement with others causes this much angst, there's a bigger problem in play.
I don't think the rambling itself is a problem. It will inevitably happen sometimes, and that's fine. It's part of making everyone feel safe.
What I'm advocating for in this post is that we shouldn't create structures or formats which actively encourage rambling that does not add to the discussion.
Furthermore, if those structures are inefficient (i.e. encourage rambling) and instil fear, you won't have 10 minutes of engagement with others, you'll probably have something like 30 minutes of unproductive technical discussion, which will cause the whole team to stop believing in the stand-up's purpose.
That's not to say I disagree with you. I do agree we must find a balance, and that's why I add a few caveats to each of the recommendations, it's just that some practices are more prone to lead to inefficient meetings than others.
Thanks again for chiming in with such a detailed and thoughtful piece of feedback.
For me, the "What did you do yesterday? What do you plan to do today? Is there anything blocking you?" questions work pretty well, with the expectation than nobody spends more than about 90 seconds answering all three. (This might just be because places I've recently worked haven't had well groomed or curated Kanban boards, but have had a mid and senior-heavy dev demographic?)
I truly believe to do what you propose, you probably have to be a high functional unit workwise. If you are, and you know you are, your suggestions are a laudable goal.
What was pretty useful was when daily standups were more IC driven and it was perfectly fine to say "yep, I'm working on the same thing I was doing yesterday" at least half the time. In those kinds of standups the Manager will typically bring broader concerns to the team that might have happened in the past 24h, rather than using the standup to quiz the team on what they're doing. The manager of course also gets to just give their own status as "meetings, meetings, meetings" and keep it short. In those cases we didn't even go through the Kanban board or have it open during the meeting, since everyone understood that you only have one or two things you're typically working on and your status is either that you're working on the same thing as yesterday or something is done and you're picking up something else. In some cases someone would be stuck or some issue would have come up, but this would usually result in two ICs taking over the zoom chat after 15 minutes and letting everyone else drop off.
For brand new team members or junior devs this still works basically the same way but there would usually a bit more heavy use of after-meeting zoom chats or async chats afterwards.
The formalism of doing it every day does work, particularly with remote teams, just to have a little bit of face to face time, and spur those after meeting or async zoom chats. But it needs to be kept lightweight and focused on developer-productivity and doesn't use any kind of issue board most days.
What I don’t understand about the async crowd is why then do you get mad when I email at 9pm at night, or I email on the weekend.
I’m not asking for an immediate reply, that’s the entire point of async (for you to reply on your own terms/time).
However, "Can we take that off-line?" can also come to mean "Stop bringing problems!" :-)
It follows the pattern work by Christopher Alexander [1]. The patterns form a cohesive interlinked language that provides context for each pattern.
Here is what it says about the Daily Scrum: https://sites.google.com/a/scrumplop.org/published-patterns/...
There some useful patterns that might even make sense outside of Scrum on there. Anyways, framing approaches and solutions in a cohesive pattern language is intriguing in its own right in my opinion.
I'm the SM/tech lead of our team. Here's how we do stand-ups. It's mostly a result of me suggesting things (I'm also soliciting ideas from others, but they don't seem to have quite the interest in tinkering with these things I do), trying it out with the team, seeing the results, getting feedback and iterating.
1) Before the stand-up, we all write a few sentences on team chat about what we've been working on, what we plan on doing today, and problems/things to discuss. This means we avoid "the round" and the problems associated with it, gives a broad picture of the situation to team members and provides a nice log for later if needed.
2) In the beginning of the stand-up, I make space for some minutes of casual chatting and joking around. This is on purpose, which I haven't told the others. It's not like it's a secret, it just hasn't come up. It's to make the team comfortable with each other and provide light social interaction, which is important in a remote team. Also to make the whole thing a bit more fun, which is a shared interest of everybody. I try to make everyone feel included here.
3) At the beginning I usually go quickly through what is overall situation, based on the chat messages. I note problems and things to discuss that are written there. Then we go over them together relatively quickly; if they don't need to involve the whole team and take more than a few minutes to discuss, they're usually tabled off for the relevant people to discuss after the daily. Before moving on, I also ask if there's any other issues to talk about, and we treat those the same as issues written out beforehand. Once we run out of things to talk about with the whole team, we end the daily. Usually it's pretty short, less than 15 mins, but if it takes longer, it will not be because of boilerplate; it will be because there's things we need to discuss as a team, and since we're already together, might as well do it immediately.
4) After the daily, we often continue interacting, just not everybody together; after all, it's a break in coding flow/focus anyway, so might as well batch the "meetingy" things together. One common thing we do after daily is a live code review over video chat, if anybody happens to have a PR ready. It has different pros and cons than an asynchronous code review; we mix and match both.
We also don't do the daily on Wednesdays and avoid scheduling other meetings on that day - it's our "deep work day".
This way of doing things works for us; the daily stand-up provides cadence to our work, allows us to coordinate and share information and to interact as people. But if one of us has an idea on how to do things better, we can try it out and keep it if works. This works for us; for another team and situation, something completely different may be in order.
Complaining about stand-ups is a common topic among developers, but I wonder how many try to change the way their team does them? Scrum provides the sprint retrospective as an opportunity for all to improve the team's ways of working; that's what it's for. Maybe your team is incapable of change due to authoritarianism or top-down process thinking, but that's a conclusion you reach after you've tried and failed to change things using your social and political skills. These skills include expressing your concerns clearly and avoiding blame, listing the potential benefits of the new way of doing things, listening and understanding different interests people have and balancing them, and framing new ways as experiments that the team can change back if they don't work.
Generally, good changes would require scrum masters and tech leads to work harder, to really get to the bottom of a wide range of issues outside of superficial meetings, to actually understand how developers, testers and devops struggle, and to solve those problems. But it's easier to put the burden of articulating problems through public speaking on generally introvert developers who then risk incriminating themselves in the process.
> 2) In the beginning of the stand-up, I make space for some minutes of casual chatting and joking around.
In a work environment it is extremely hard for people to truly enjoy jokes and chats when everyone, including soft leadership, is present. People are very much concerned with their standing within the organization and if they are good enough to remain, or advance. If that is not an issue, frustrations with many work-related disappointments and sometimes colleagues are main concerns for software people. It would take a truly remarkable individual to lead such a casual time of cracking jokes in everyone's second language in multicultural teams over video call, when their livelihood or sanity is on the line, rather than it being a stressful performative act for half the team.
My team is a monocultural one, in a Nordic country. We're remote by choice, and because some of us live in other cities. Nordic countries have the lowest power distances in the world, which is relevant to how social interactions work out. Also, in my experience, software developers here don't typically worry that much about their standing in the organization, or about advancing in the organization, or being kicked out. Of course some do, but I don't think it's a cultural focus here like it might be in some other places. If you look at the discussion forums for devs here, those concerns hardly ever come up. Talking about raising salary by switching companies is way more common topic.
We have plenty of time for deep work on other days too. It just that in earlier phases of the project there were more meetings, so we set up the deep work day to make sure one day can be totally uninterrupted.
When it comes to articulating problems, I feel our people are vocal enough. Not all the time, but if there's something annoying or frustrating during a sprint, I feel that it comes out during a retro. It's the process improvement ideas where I feel like I'm the most active one - which is fair enough, since it's an area of interest not all people have.
They are probably bored and planning an escape. You have no idea how visible the scripting is, including all the fake joking around step. Engineers are not children, and if they are you hired the wrong people. Let them get on with work, and do a weekly or by weekly standup instead. Be sure to … “empower” them to talk to stakeholders and let them be proactive.
- A guess with a high level of confidence at mindset of people you don't know, and their mindset in situations you're not in.
- Assumption that joking that may happen is fake, again with people you don't know.
- Assumption that a weekly or biweekly standup is ideal for a team you know nothing about - which implies that it's ideal for all teams, of all experience levels, in all projects, in all fields, in all organizations.
Consider that you may not, in fact, be able to justifiably draw these conclusions from the text you just read. Also consider that whatever the personal experience that informs your conclusions is, it's probably not applicable everywhere.
Be listening to what other people say! See if you can remove or prevent a problem they mention.
Say things that matter to others! Give people a shot at clearing your path/making your life easier.
If you don’t want a daily standup it’s because you don’t trust your team to be able to help you (or you don’t want to help your team), and that’s a highly solvable problem.
Next up in "Holy generalizations Batman": if you don't use dark mode religiously, you're a terrible programmer.
I don't like standups because I trust people to capable of asynchronous communucation and independent, not the other way around. Universal standups are exactly the bandaid I expect from teams unable to figure things out themselves (excluding situations teams want it themselves, hence 'universal').
Let's stop treating people as 'deficient until proven otherwise' for not agreeing with a barely supported methodology, please.
You don’t want to communicate on a daily cadence because the communication costs you more than you get out of it. That’s a problem. You should be demanding a daily standup, not running from it.
>You should be demanding a daily standup
The only things I demand from people in a professional setting are progress and results. How they reach is none of my concern until it is evident intervention is required. A daily standup does not guarantee an improvement in either of the two.
This is 100% a "you" problem if you can't figure out how to get value out of a daily standup, and whoever is leading your agile effort should be helping you.
Honestly I'm tired of people like you getting a pass, which you've clearly become accustomed to, but this one is so basic, so easy to do correctly, and so easy to extract value out of, you must actively be fighting the system in order to struggle at this point.
You literally go through a list of in-progress items, and people say, in a sentence or two, how they've moved that work forward and any issues they've encountered. Other people listen, and chime in if they can help, and stay quiet if they can't. It's dirt simple, and isn't replaced with async anything, as a) it's very quick and costs extremely little and b) there's no other way to know if what you're working on is relevant to other folks or not.
Everyone's opinion is informed by their own experience. In my experience, a standup is about as valuable as having a conversation with a brick wall.
It's a status meeting. It's not supposed to be, but status meetings are good for managers and bad for workers and so they're not going anywhere.
Capitalism would be bad enough if managers actually did care about "the company" or their shareholders, but it's simpler and more degenerate than that. They are optimizing for their own careers. It isn't more complex than that. The "bureaucratic culture of fear" suits them well. The weaponized standup is great for them; toward their real aims, it works beautifully, because it's basically thunderdome in its ability to make workers slug each other and terrorize those seen as least productive.
"Agile" is a case-in-point where engineers, being intellectually intelligent but socially imbecilic, assumed good faith on the part of the people managing them and came up with a framework to make those good-hearted managers' lives and jobs easier... but, of course, the people above were not good-hearted and so any components of these methodologies that actually empowered working people got ripped out while still allowing the bosses to say, "Well, you asked for this."
You do realize that the only alternative to capitalism that's ever been proposed is Scrum for everything inside and outside of work?
What does this even mean? Standup are a report to make sure things are going to be done by the end of sprint. They’re a place to bring up roadblocks and any revisions to estimates. They work really well for what they are.