Major caveat: they were never doing stand ups to begin with. From the screenshot, the feedback from the team was “standup are becoming very long, a lot of chatting and designing features” (paraphrased)<p>It sounds like they had a 45-60 minute daily meeting that was not a standup. Rather than cancel the meeting, shorten the meeting with a 15 minute hard stop.<p>I run a 10 person remote SaaS company. We have daily morning stand ups. The standup takes no more than 10-15 minutes, but it sometimes goes 20-25 minutes since we often chat for a few minutes before jumping in to standup. (I can’t imagine us doing feature design during that meeting, as they were in the article)<p>The chatting / socializing is something I encourage before standup starts. As a remote team, it’s necessary to have some group interactions to maintain the group’s working relationship.
This article, as with much tech discussion I've seen in the past 5-10 years, seems to take sprints as a given. Are most devs here working in a sprint model? It sounds a bit soul crushing to me to be "continually sprinting".<p>I'm so glad that our company doesn't have them—I think it's a significant factor in me grinding it out for 9+ years. We have feature releases every 4 weeks. If your feature is merged before QA, it goes out in that release. Otherwise, it gets delayed till the next release, and we don't make a big deal about it—several other features will still be in the release.<p>I feel like it gives me a lot more agency and ownership of my work. I think it's the right amount of subtle deadline pressure, relying on my intrinsic motivation to get my feature shipped and move onto the next one. Or to have the freedom to determine that it's not ready yet and spend a little more time to avoid shoving out a pile of technical debt.<p>I'm curious to see what I'm missing, though. Anyone love sprints? Anyone working in a non-sprint model and hate it?
Why are standups even a thing?<p>Like, what is wrong with my reasoning here? Meetings are maximally efficient when the exact set of people who all need to talk to each other are present, and no more. In a team of 7, only 1 or 2 other people might be affected by what I’m working on. The other people are just wasting time pretending to care about what I’m saying.<p>My experience working at tech companies in SF has suggested to me that most meetings, not just standups, suffer from this problem. The time cost of a meeting grows as O(N^2), and yet we routinely have all-hands, weekly syncs, etc. Yes, some level of communication is needed but when the time cost of these things is so tremendous, it seems irresponsible not to at least ask if what we’re getting out of it is worth the cost.<p>Meetings are apparently the one thing that no one tries to optimize, in our industry ostensibly hyperconcerned with optimizing things.<p>Disclaimer: I hate most meetings.
They stopped regular work and had a hack week and morale improved. Now they're back to the regular work and having standups again. What does this show other than taking a break is fun?
"our standups are growing and spend alot of time chatting / designing new features". So your standups are inefficient and your solution is to cancel them? Talk about a false equivalency. Fix your standups, dont cancel them.
I much prefer stand-downs (I’m claiming the name now).<p>At the end of the day, you tell your team what you accomplished for the day in an email. Everyone already knows what they’re working on next because that’s part of the ticketing and schedule system your company uses, and decided at the beginning of the release period. If you’re blocked you go tell the person whose blocking you, or your manager.<p>When everyone wakes up and goes to work they can just get to work.
I've found standups to be probably the biggest waste of time of all Agile ceremonies (and I'm really not a fan of Agile as-is, but I'm too young to have experienced anything else so I can't say it's definitively bad).<p>I think the one caveat, though, is that standup is useless IF the team is high-performing, close with one another, and self-motivated. The team I'm currently on probably does not need any sort of formal Agile workflow at all besides setting our current sprint's worth of stories at the beginning of each sprint. But, that's because everyone on the team is very self-motivated and even remotely we're still very close with one another.<p>I've been on other teams where, without standup, people would go for days without working on or talking to anyone.<p>I think, if anything, this is proof that no company should have one method of delivering software. I work at a massive company, and forcing each team into Agile is probably easy at a top-down level, but can be very frustrating at a bottom-up level.
A bit click baity.<p>The team experimented with cancelling stand-up AND started doing a version of 20% time with a strict rule about "fun projects only".<p>As with any process experimentation, mixing two initiatives at the same time makes it impossible to understand the results.
Anybody else a infrastructure engineer and do Agile?<p>We do and I just don't think it fits for our work. Maybe it's good for development but our work rarely fits within in a sprint (which is a week for us which I think makes it worse).<p>And I cannot stand stand ups. They feel like a waste of time. I'd much rather do two meetings a week to catch up on things and look at our tracker in between.
Cancelling standups during a "fun projects only" hackweek doesn't say a single thing about the efficacy of the standup meeting. The costs of cancelling it, will only show up over the medium to long term.<p>Also, it makes me cringe a bit to see there are people who think number of pull requests are a good measure of productivity. It incentivizes blasting out a lot of quick, easy changes at the expense of doing more challenging tasks that may be essential for long term code health.
With JavaScript turned off, the link goes to an empty page. There's some template stuff, but no content.<p>Which could be taken as a rather funny take on "here's what happened" ;)
On the teams I've been on that are actively doing software development (not in some pre-coding phase where we're still figuring out requirements or something like that), if there wasn't a stand-up individuals created an identical coordination mechanism in an ad hoc manner. This tells me that there is something valuable to stand-ups, even if we don't always love them. If a team's stand-ups are not effective, there are lots of things you can try: refocusing the team's attention, have someone other than the normal "stand-up leader" guide the conversation, or change the time so that it's next to another interruption (for example, right before most people get lunch... this has the added bonus of incentivizing people not to ramble).
There is an important piece of information they didn't take into account. They cancelled stand-up right before the Covid lockdown.<p>What they are tracking is not the effect of no stand-up, but the pattern of their workers during the lockdown. The April drop in pull requests can be explained by workers feeling overwhelmed after staying home for a month.
Daily stands ups are the quickest way to waste your time.Even if can limit the stand up to 5 to 10 minutes, a study from the University of California Irvine revealed that it takes an average of 23 minutes and 15 seconds to get back to the task at hand. That means you lose half an hour of work from each of your team members each day, 20 hours a month.<p>I trust my team to keep me updated if a ticket takes longer than expected. If it does, I can arrange a meeting with the required developers to discuss a way forward.
Stand-ups are pretty dumb. Yes, the idea is that they exist to surface and resolve impediments, but there are problems with that:<p>(1) impediments shouldn't fester for a significant fraction of a day, and usually don't require synchronous team-wide communication.<p>(2) stand-ups inevitably, even if timeboxed effectively, become either rambling or ritualized status meetings, because people very quickly learn how to resolve, or at least surface and start working to resolve, impediments without waiting for them.
Wow, I'm kinda impressed of all the negative comments here.<p>What's making a short and focussed daily synchronization meeting (aka: Daily/Standup) useful for me:<p>* Short and focussed, 15min max, no excuse<p>* Focus on impediments and try to figure out if the team can help.<p>* <i></i>VERY<i></i> short update on what I'm planning to do today (to make synergies visible)<p>* And the least important one I'd skip quite often: Short update on what was done yesterday. (Looks like, lot of ppl are focussing on this one)
Classic army of apologists with 'you are doing it wrong'.
Yes we get your intricate textbook philosophies but the average Joe, works at AverageCo and has an average Schmoe manager that takes your buzzwords, weaponizes it and turns our life into hell. So don't be surprised when people are angry with you. You invented the deadly rituals that an entire industry now suffers from.
The calendar picture is interesting. One of the problems I have with standups or any meeting first thing in the day is how it affects my mental state. That period directly after I start work is precious. It's when all the things I've had in my mind overnight are ready to be realised, and I'm calm and my mind is receptive to sitting down to a focused session.<p>Splurging a meeting into that period can completely destroy that precious time. I can have a whole morning of work just disappear because I can't focus properly after an interruption like that.<p>Another way of looking at it is that people understimate the cost overhead of having a meeting. For me, you can pad the time around it with about an hour before and after and assume my productivity will be severely impacted. In that context, a 15 minute standup is about the stupidest thing you can do for my productivity. If you're going to have a meeting, make it real and decent and worth the overhead of holding it.
During most of the time at <current company> I've had a standup in the morning, one in the afternoon, and I have to put my daily summary in a chat room so that more people (architects, CTO) know what I'm doing. I'm a developer.<p>In the past when I was a manager I hated making my team do standups. In fact, one reason I quit was that I got a new boss who was an agile evangelist and I had to implement things his way. I didn't like how it made us less efficient and eventually quit.<p>One thing I did as a manager was for pre-sprint planning each developer would meet with the product manager for 10mins, one on one, which the team loved by the way. Instead of giant 1-2 hour grooming session.<p>I think I was an effective manager, but no company wanted to hire me because nobody works like that, so I went back into development.<p>I hope that my company keeps growing so I can do the things the way I want and keep as much BS as I want out of my life (or delegate it, I guess).
A couple observations: First there is a lot of "no true Scotsman" in the comments here, saying, for example, thaht they were not doing standups correctly. Secondly "Agile metrics" is the "diet snacks" of project management. Yes, their metrics improved. But does that really tell you if they made great high-value software?
As hardware engineer that does a hybrid software/hardware role on a team that uses sprint/scrum planning, I find it a terrible idea for a lot of applications. It is great for certain situations but I find the discussions more about what task we should do rather than what problems we should solve and the value added. If things are breaking on a product/project because you didn't know about some upstream or downstream interface, the company itself has an underpinning issue on transparency and ownership. I have rushed hardware projects (expensive mistakes) involving capital equipment (expensive) and everything interfaced correctly given the fact that the ownership and responsibilities were transparent with decent planning in the beginning.
The worst thing about standups is that they tend to be scheduled in the morning. Half of the team I manage are night owls. They suffer when they have to wake up in the morning just to attend a short meeting. That’s why I do everything I can to cancel standups. People become more productive because they gain more flexibility. Now they can work on something till the evening if they are in the zone, without worrying that they have to wake up early the next day. Works even better now that everybody is working from home.
Seriously, does anybody do literal standup meetings anymore during coronavirus and work from home? Or any of the other agile busywork chores? It always struck me as ridiculous to create task cards like in kindergarden, especially in IT. The inability to manage projects using computers is totally unconvincing especially when your team is tasked with creating computer programs. I hope we can finally get rid of agile bs rather than skeuomorph physical task boards and cards into team workflow software.
Since lockdown started, we switched to 3-Ps - everyone post 3 micro tasks they are working on today on a team discord channel before the meeting starts, at 9 we all hop on a team call and go over all the 3ps.<p>short and sweet.<p>and gives enough insight for people to ask for help or just get a feeling of progress...<p>tricky sometime not to list macro tasks, which takes more than a day to complete. but other than that. its also nice to force every on to think about and commit to a few small things they want to work on for the day.
Stand ups are supposed to be good if it has a focused purpose but eventually it morphs into a “I’m continuing to work on X and no blockers”. Then everyone resents what a waste of time it is because the team basically knows 80% of what everyone is already doing. Or the blockers/issues/new features they have won’t be sufficiently explained in the stand up, and everyone pretends to understand or care for it.
There is a really important part here I don’t is picked up on. One reason why it’s a ‘stand up’ meeting is because you’re supposed to be doing just that - it helps keep the meeting short and to the point.
A really good example of this is the Privy Council. Queen Victoria got tired of long meetings with her Council, so she just kept standing during it, meaning everyone had to as well and couldn’t drag on. They still stand up today.
This doesn’t translate well to remote working but like others are saying, the idea is to keep things brief and on point. Longer conversations can follow after.
That heatmap calendar was upside-down from the typical calendar UIs which I've used; it showed time flowing bottom-to-top rather than top-to-bottom. Is this the typical style for Haystack or related tooling?
This sounded like: we changed our routine and then had our most productive week ever. While I think there is a point to what they are saying, I wouldn't take the fact that they had a great week as proof of a better work methodology. If people had voted to have ice cream every morning they might also have had a really productive week because ice cream is fun and changing the routine is fun. But I wouldn't bet the farm on making a company more productive in the long run with ice cream breakfasts.
I vaguely recall research about process changes reliably boosting productivity temporarily but eventually reverting to the mean. Does anyone recall if that effect has a name or a canonical study?
<a href="https://uploads-ssl.webflow.com/5ed57622ee14fb96d022d544/5f6cc2313f047785e14bf727_11.png" rel="nofollow">https://uploads-ssl.webflow.com/5ed57622ee14fb96d022d544/5f6...</a><p>Is this list representative of the entire scope of the sprint? Unclear from the article. If so, while the sprint was arguably successful in that the engineers felt good about it, it didn't really succeed in improving the customer experience directly.
The biggest point for me from the article isn’t the stand ups.<p>It’s that their fun projects are, mostly, improving their quality of life while working. Improving deployments, faster compilation, analytics... those aren’t fun because pure fun, those are just necessities that should have been tackled earlier.<p>Improving that kind of stuff always makes development less frustrating, narrowing the time between something is coded and something is running in production.
In my opinion <i>daily</i> standups are pointless when there is no short term delivery goal. In my dream company standups, or better dev meetings, would peter out to about once a week and then ramp up as the team approaches a delivery.<p>I once calculated that daily standups, sprint planning, sprint retrospective, sprint demo, and for some sprint of sprints consume one full day of the week. Now unless the Agile ceremonies make the team at least 25% more productive, to make up for the full day "lost", in my opinion, it is counterproductive.<p>But none of those activities made our team more productive, effective or deliver faster or better. Our dev teams had a built a great product that customers loved and a customer service that customers frequently lauded us for. In fact, customer loved so much they moved some of their staff into our offices and asked if we had any other product/services to sell to them! (Go figure) We had achieved all this without doing the Agile thing. We simply met and talked though issues. Senior engineers were given the freedom to innovate on the modules that they delivered. It was great, and it worked.
The company I am currently in never had standup, everything is communicated in Slack and Jira and everyone works well together for many years already. This article feels more like a promotional piece for their own SaaS lol
I'm a scrum master, but I'm happy to not do daily standups anymore. I prefer to work harder on todos and concepts and enabling teams to do their work written without talking.
OMG your managers must be feeling like they are losing control and scared their importance is diminishing.<p>Who cares that you are getting more done.... Will somebody please think of the manager's poor egos!
There are so many things that are not FUN, but have to be done anyway. And more often than not the not-fun things are the direct consequence of the "FUN" projects.
Honestly, if you think spending 15 minutes (we’re closer to 10 though) talking to your team to ensure that you know what others are working on and they know what you are working on, then I don’t want to work with you.<p>It’s not wasted time, and even if you don’t care what I’m working on I still care that you know so that we don’t spend two weeks building something only for you to go “Oh, that won’t work after the changes I made to the core.... why didn’t you come by my desk and ask me “are you intending to change the core code in a way that invalidates all assumptions we had two weeks ago when we started working on this?” And do so like clockwork every day, even though I’d answer no 6 times before suddenly answering yes?<p>“But we already communicate in the team outside of the Stand-up!” You say. Ok then, tomorrow at your standup, have everyone go though someone else’s points, I’ll say what you did yesterday, if you have blockers and what you’ll do today. If everyone does this flawlessly, then yes the daily is wasted time, but for every mistaken assumption you hear, that is a potential mistake or missed opportunity or just general annoyance you avoided simply by talking 10 minutes together.<p>Now don’t get me started on the number of bad excuses that you avoid by having daily stand ups that’s a whole other subject, but also an extremely valuable element. “I’m waiting on Kevin to finish X” “Does Kevin know this?” “Yes of cause! “ Kevin: “Wait what? Err what am I supposed to be doing? That’s not on the board”. Etc.
I want to share a core tenant of scrum that isn't in the scrum guide and most people don't cotton on to.<p>Here goes: 'Meetings' are a time to do a specific thing.<p>This seems very simple, but my own experience as a scrum master and in multiple a businesses trying to implement scrum, along with the gripes people have in this thread, show that most people just don't get it.<p>So the answer to "why are we having this meeting?" is often very simple and I'll list all of the meetings and what their purpose is for your benefit. This way, when you find yourself doing something else during one of these meetings, you can safely assume that it's not scrum at fault, it's you and your crappy implementation of the process.<p>> Planning, this is a meeting for planning.<p>> Backlog, this is a meeting for grooming the backlog in preparation for planning.<p>> Retrospective, this is a meeting for retrospectively looking at the sprint to improve the process for the next sprint.<p>> Standup, this is a quick daily checkup for each team member's progress, planned actions and blockers.<p>Notice how Standup doesn't include "this is a meeting for small amounts of planning." That's because it's not there, you're not meant to do planning in standup, there's a meeting for that. So, if you need to do post-planning on a task it's not ready for pickup.<p>Easy so far right? Now the bit that people struggle with.<p>If you've achived the meeting goal, there's no need for a post standup checkup about where someone's at. So people can do their job knowing that the "hey where did you get to with X" question isn't going to disrupt them from 09:15 onwards.<p>Hey! That sounds great... but 15 minutes is 15 minutes I hear you say. The "time to do a specific thing" is the most efficient way of achieving that specific thing. That's the point of these meetings and why a successful implementation of scrum is more efficient that your other crappy process.