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?
“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.
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.
But in 15 years, any time a standup was below that target, people commented on how unusual it was to be done already.
The standup is either early enough in the morning that it becomes a passive aggressive way to get people to show up 15 minutes early to work (because if you try to show up on time, you'll be late for a short meeting, essentially missing it), or it is late enough that early risers have to avoid flow state tasks early in the morning or also miss the meeting.
If you are in the middle of something, a 15 minute meeting clears working memory every bit as much as a 3 hour meeting. So if you're going to lose your spot, you might as well get something else out of it. Which contributes to the "but it's never 15 minutes" phenomenon.
If you've goon 15 years without any stand-up being under 15 min, then you are doing something wrong. Is your team absurdly large? Is your scrum-master not fluent in scrum? Does no-one in your company understand how a time-box works? Or do you insist on bringing up lengthy technical discussions that you could perfectly well take with the 1-2 people involved outside of the stand-up? There are tons of ways to do it wrong, and pretty much every single one comes back to people not understanding what the stand-up is and isn't for.
It's popular to shit on scrum, but a lot of the criticism comes out like someone going "Programming in C is rubbish, it always throws segfaults, and it's impossible to create good software in a programming language that isn't pure functional" It's an opinion sure, but it's based off of being bad at coding C and preferring to code in Haskell, where you might ask the person if they had considered actually learning C before shitting on it.
> If you are in the middle of something, a 15 minute meeting clears working memory every bit as much as a 3 hour meeting.
Getting interrupted for a 5 min talk with a colleague is just as interrupting to your flow. Don't pretend to claim that everyday in your 15 years of scrum you have accomplished absolutely nothing on a day if there was both a daily standup, lunch, and a person asked you question.
Yes interruptions are bad and should be minimized.. which is why having 15 min condensed to get everyone aligned is better than having 5 people dropping by randomly to ask "did you commit the feature yet?" "Was it me or you who was supposed to do X" "You do know that I'm waiting for you to finish Y right?" "Are you waiting on me to do Z, cause I prefer doing X first, but no-one needs that yet". And again, if a team has more than 15 min total of those kinds of interactions during a day, you need to reflect and improve. If you have less than 15min, then great, everything is cleared up after the daily scrum.
I don't think this is exclusive to standups: any type of process done repetitively over time can get this upward curve of increasing monotony, even if it doesn't lose its inherent usefulness.
The very act of changing or intervening in a monotonous process might be a boost for people, and to your point is not an argument against the usefulness of the process. I've equally had teams not doing standups get a boost from starting to do standups.
Coming from doing a lot of recommendation systems work, it's similar to how just changing algorithms around often leads to a temporary boost in engagement which then regresses back to the mean (same in general A/B testing).
When I'm managing a process and someone comes to me with a process change suggestion, and I feel like I am well-stocked with evidence as to why the existing process makes sense and is efficient, I now have a meta-assessment where I consider the change because it will at the very least mix things up and introduce changes to thinking. Obviously that is not to be done willy nilly, but my younger self would have pushed back on process changes that were not inherently superior to the existing ones.
I thought the whole point of orthodox standups (and one of the brain-dead things about them), was that you weren't supposed to have discussions at that level of detail.
BUT WAIT HOLD ON, it's 15 minutes of "standup" and 45 minutes of "parking lot." eye-roll
This is every single day, by the way. Our previous manager got the picture and reduced these to three times a week with hard time limits. Then a new manager came on and put daily "standups" back on, after apologizing that he was adding a meeting to our no-meeting day, lol.
I'm dead inside.
It also psychologically feels bad when you have the same update every day (e.g. working on a long-term project) or if you have no update. It's also really fucking stupid to have a "standup" on Friday morning and another on Monday morning.
I'm dead inside. I'm dead inside. I'm dead inside.
Also I take any opportunity to vent about these stupid "agile" methods, sorry.
And yes, sure, that is objectively not the point of the meeting and blaming the meeting for people misbehaving isn't right. But it's a cowpath argument to me. If the meeting is in service of a team and their collaboration, collaborate in the ways the team finds most meaningful. Do not force a team to pretend to be collaborating.
I would understand if you said 2 years or 2 months. But if your road-maps and plans change so rapidly that you can't even assume that features coordinated one day will still be relevant 2 weeks after... then how on earth do you have a functioning team without daily communication? And if you do have daily communication, why not concentrate that to a single max 15 min period to reduce being interrupted in flow?
Not all of us enjoy being micromanaged.
Standups are for managers and 99% of the time can be done asynchronously. If you have to know what everyone else is doing in order to be effective at your job, your planning process needs fixing.
We now have more than 50 devs, and we've remained quite flat and autonomous. It would be literally impossible for me to track what all the other devs are working on, never mind going over it every day in 15 minutes. It probably works better for siloed dev/product teams that stay under 30 people, but that's not how we work.
I share all this to give perspective on a pretty bold statement: "If you [don't like standups], then I don't want to work with you." Ten people is a good size for standups, and I think you may be overgeneralizing your experience when judging people who don't like standups.
Even still, I'm curious how much is changing daily to warrant daily standups? We have a rotating "release team" who runs QA and ultimately performs releases, and they check in daily. But daily checkins for feature development seem very frequent to me.
Then again, we have a small and high functioning team where there's no "waiting for X to finish Y" or blockers that aren't resolved immediately via communication on Slack. There's never a lack of issues to work on. Nothing assigned to you? Well, pick something from the list of issues or something on the roadmap, communicate to the team that you're working on it, communicate when you're done.
For a team of 6, 15 minutes a day is 90 minutes of productivity. That's 7.5 hours a week, pretty much almost a whole day of productivity for a person.
Whether standups are great for your team or not depends on the makeup of your team and personnel, the size of your team as well as the nature of the work and how work is divvy-ed up. I've found success on teams with and without standups, and I'll say that not having 15 minutes of the start of your day spent on being in a meeting is absolutely refreshing
If standup is needed by the team and it feels natural then it probably is useful. Nowadays with remote work I kind of like to have at least 10 mins to see people that I am working with each day.
Stand Ups by nature are to be quick. It is why YOU DON"T SIT.
You can do them over Teams, Zoom, Slack.
Companies allocate millions to billions of dollars for projects and have a need to know how things are progressing and if there are issues and resources that can be brought to bear to solve them.
If your manager or "Boss" is micro-managing you to death, then leave. The culture is toxic and a 10 minute stand up is the least of your issues.
1) Standups are for knowing what your team is up to. 2) Standups are for removing blockers.
If (1) is correct, then let’s just call them what we always did before the SW Project Management Industry decided to buzzword it. Status updates.
And if they are status update meetings, then the simple question becomes why they should be daily. Their cadence should be dependent on the type of work the team is doing. If the type of work you’re doing means the majority of your work items are done in a day or less, then by all means have a daily status update meeting. However, if like many teams, the majority of your work are items which take 2-3 days, if not weeks, to complete, then why not just do 1-2 status update meetings a week?
And when it comes to removing blockers, why have a daily meeting at all. Why not do it in an async format using mailing lists (or Instant message/Teams/Slack/etc) instead. That ensures you’re not blocked waiting for the standup, and everyone is aware of your blocker as soon as is convenient for them.
In practice, however, Standups tend to be a mixture of both (and that’s how they are usually defined...what you did yesterday/what you will work on today is status updates, and blockers is about removing impediments). And that makes even less sense from a purely theoretical perspective (never mind the scores of practical experiences where it’s been a disaster), because those 2 tasks have different ideal cadences. Blockers are something that should be shared immediately, as they happen. Status updates, however, should have a far slower cadence, where you need to balance the need to keep the team informed about your work, and share progress towards goals, with the fact that each update is an interruption, and so the ideal cadence would be dependent on the nature of the work the team does.
The idea of a daily standup is a good fit only for teams whose work happens to be such that once a day happens to be an appropriate cadence for their status updates. And even then it’s not a good solution for the blockers removing aspect.
Software can achieve this, and it's what my startup is trying to make happen. The key is to unify status-as-in-state with status-as-in-active-communication so the two can inform each other.
Once a week, maybe right after each person says what they did, everyone gets randomly assigned a person and they have to explain what that person did last week.
The goal of this exercise: Make people actually pay attention to what others are doing and ensure they really understand it (and feel empowered to ask questions if they don't)
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.
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)
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.
that's true, but it just turns the question into the one of "is it possible to do real standups?". My experience is that I've never managed to do real standups. It's just not possible to relay complex information about what you're doing in 1 minute. You either do it so superficially it's worthless or you it in depth and it takes longer than a standup should.
Assuming you have a Kanban board for your work, and assuming the work is actually accurate on the board in terms of status (which most teams are terrible at without practice) AND assuming you properly have “waiting for testing” “testing” “waiting for review” “reviewing” columns (those waiting for columns are critical to seeing the true state of work), then you simply just “walk the wall” from right to left. As you scan through each column, team members call out if shit is a mess, otherwise you just get a thumbs up and move to the next thing.
Then, just use some analytics to highlight tickets stuck in a status too long, and bubble those up in the standup. “You keep saying this is on track, but it’s been here for a week, what’s the deal?”.
STANDUPS ARE NOT STATUS UPDATES. They’re for resolving blockers in person without letting shit linger too long.
As long as your board is accurate and respected as the source of truth, it is the status update mechanism. It’s no longer a human job.
(And yes, this is actually possibly, my agility team does this with 15+ scrumban teams right now)
The answer to that is yes. But only if you have someone with the authority to interrupt when it goes off-track. I frequently do that, but it usually takes a very long time to convince the people I work with that someone needs to have this authority(interrupting people is usually considered rude, whereas unrelated rambling is really the rude part by being disrespectful of all the people that are not interested in it).
On paper I thought that that's the role of the scrum master. But in practice I've never seen a scrum master do that. I usually offer this to the project owner, but usually the project owner is the one rambling the most in standups.
Practically speaking what happens is that when people start rambling I interrupt and tell them to take the discussion to the 2-3 other people that need to discuss this with him/her after the meeting.
The idea is to make the connections needed with the people present, to help with the issue after standup (Bob is having issues with authentication on API x, and Sally says she might know how to help. They will take this up after the meeting).
Status updates should also not go into detail. You might be proud of your very cool efficient implementation for a sorting problem, but get your ego stroked someplace else please (PR's are a good place for that).
Most important of all; empower every team member to shut down this kind of time wasting for the rest of the team, by simply saying that this kind of talk should be taken up after the meeting.
Me and my team and a financial institution do this, and it does not matter who is in the meeting (PO's, executive directors etc).
Why? Because no matter when you schedule a daily meeting, it will be in the middle of someones deep work hours, and they will have to context switch for 15 minutes just to tell “No impediments”.
When I'm peaking it's stand up time because it's the earliest time when everybody is available.
The best standups I had were at a previous job, after lunch:
1. A major interruption already happened.
2. Your "mind cache" is fresh and you know what blocks you, compared to remembering what you were doing the day before. People systematically forget stuff during early morning stand up then come interrupt you for questions hours later.
My ex-LM is now working for major finance processing company. They went trough major agile transformation everyone in the city was talking about how big success it was. He's a tech-lead. He has to estimate feature development in man-hours to the board and investors. Everyone below him (SM, PO, devs, QAs) estimate in story points. He gets shit for features being late by days (eg. sprint finishes on Thursday next week, board meeting is on Tuesday this week).
They cancelled something they were doing completely wrong, because they never reached for quality material how to do it right. Good for them, it was a waste of time to begin with.
Compare that to hourly <n>-people's time is profligately spent and it has advantages for everyone.
If something needs more discussion, then the interested parties - only - can have their own meeting.
Sincerely, someone who at some point decided to start stand ups early with unofficial goal of "finish before manager gets in"
This sounds like someone bad at moderation punishing not healthy team members. Our hoping people are not fit enough to stand for long.
Be bold. Make change. Improve the way you work.
Was cancelling standups going to far? Maybe. But that's not the point.
I don't mean to pick on you with this comment - you are accurately describing the state of the industry.
But either way, I’m not bashing you, just disagreeing :) No harm in trying things and experimenting to find what works for you.
A well run standup is a minute per person, max. It ensures everyone pulls their head up out of their work long enough to highlight obstacles that might effect delivery, or that someone else on the team might be able to help with, while also ensuring there aren't constant interruptions throughout the day.
Giving people time to express that they are being blocked or that they need help with something increases the chances that they will feel empowered to ask for help or to be unblocked. It also aids in accountability and ensuring that people are getting their work done on time and as agreed with stakeholders, as well as giving other team members an opportunity to mitigate any such issue.
On the other end, formalizing that it is short prevents it from turning into an unexpected retro or venting session or long-winded technical discussion better left for some other forum. Everyone should be able to give a quick update before any member of the team loses interest.
There are reasons behind all of these things, and as aware as I am that not everyone agrees with every tenet of every leadership strategy, the "standup" as commonly formalized is actually really solid and I would expect a good reason not to employ it in the way that it typically is.
There was never any resistance there, and I've never encountered friction in that vein anywhere. No cto or vpe above me has ever wanted to get in the way of someone productive getting into a multi-day flow state anywhere I've bothered to work that hard. Peers or underlings however, the competition that is, it's a different story I mostly ignored.
Having said that, I found standups to be a very obnoxious, passive-aggressive tool management used for dealing with folks unable to maintain a relevant and correctly prioritized todo list, and stay on task day-to-day. It's a group I've dabbled in being part of at some employers, and found quite unfulfilling and frustrating because management is way more meddlesome in that mode and individual leverage is practically nonexistent without playing the politics game well. YMMV
> what if people are working on something for a bit longer than one day and got no news to tell or talk about?
They can just say that they are busy on it. But now the team can coordinate.
Maybe that feature is taking too long, and you should instead spend time on something more important.
Maybe Jerry says "hey, I'm finishing up on issue XYZ. Now I can go help you with that long task."
Maybe you are working on that long task, but hear that another team member has a problem which you know a lot about.
Maybe someone in the team is thinking of starting a new issue which is related to your long task, in which case some coordination may be needed.
Maybe someone thinks your long task is shouldn't be taking that long and they can afterwards help you out. It is easy to get stuff in a bog and not know it.
Scrum is meant to be a team sport where members are helping and supporting each other.
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.
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.
I'm curious to see what I'm missing, though. Anyone love sprints? Anyone working in a non-sprint model and hate it?
At the end of the day, "agile" wasn't originally the monstrosity that scrum-fetishists have turned it into. It was simply these few lines:
"Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan"
It is precisely at this beginning point where most "Agile" teams fall flat on their faces. Instead, it is all about process, rather than said individuals/interactions. Scrum rituals are done because, well, everyone else does them, so that's considered "correct". Whether or not there is any value in the process is secondary.
If you're trying to plan out which individual stories your eng team will be working on 6 months from now, or you have a half-dozen "Sprint Retrospectives" with the same complaints every sprint from your team with no changes being made - you've probably made a wrong turn somewhere.
Having a two week period with a decided set of work allows you to peacefully do this work isolated from incoming requests - unless they are critical, they will always be delayed to the next sprint. Without sprints, our direction and priority changed daily, with no ability to say "we haven't planned for this, please wait". The result was it was incredibly hard to get anything done, and attention was always scattered.
I am happily back at a place that is doing sprints, and I am sure the problems at my previous organization were far bigger than not having them, but sprints do seem like a great tool to isolate the developer from exterior fluctuations. Granted, a great project manager can probably do the same thing.
If you have constant and regular changes in priorities that appears to be an issue with whoever is doing the prioritizing/planning for your team and not a consequence of a specific process.
I do think it's useful to have some cadence for important meetings, but the arbitrary timeframe should not be treated as a goal or even something worth dignifying in and of itself. It's simply a tool, nothing more and nothing less, and we should expressly state its purpose and discard it in situations where it ceases to be useful.
I actually do like the default Agile meetings, but I think they're usually implemented haphazardly. I would prefer standups at the end of the day so that they run no risk of destroying the context of a programming task or block me from starting my work day. I like IPM/sprint planning to refine stories and make sure they're ready to work. I like having a "definition of done" to create a shared agreement of what my commitments are and whether I've met them. I like retro to evaluate how we're doing as a team and to improve processes and working culture. I like technical retros to share learning and troubleshoot architectural problems and identify useful areas of research.
All of these things are great when done well and for the right reason. All of them can be sources of misery when they are done ineptly or as mere formalities, with no underlying sense of purpose.
Two advantages, people that have got "into" the work flow in the morning need to break anyway, people that use the morning for "admin" and then afternoon for work can finish their housekeeping with the standup.
Same applies at the next order of magnitude, start/finish sprints in the middle of the week, not the beginning or end. No one wants to sit in a review on a Friday afternoon.
Retrospectives make sense at the end of the working week. Planning makes sense at the beginning.
As a both a runner and a developer, I find this quite funny and a bit wrong. The fact that we call them sprints can be a bit wrong or confusing if you put them in a different context, but what I can say is that almost every serious runner will constantly check their laps, be it miles, be it km, you will always look at your watch to see how you performed in your last km and if you are on track.
That's what I see useful in sprints, the fact that you stop for a bit and see where you are, you have the time to discuss things that might have gone wrong and try to fix them before it gets out of hand. But in the end I can understand people who dislike the system, because I've worked with a lot of managers with no technical knowledge trying to manage technical projects.
Um, yeah, that's a sprint. That's exactly how it's supposed to work. Like you say, it's a good way to work. What do you think a sprint is?
I've worked in non-sprint models - i.e. no regular time-based cadence - and found them harder. It's very easy for a feature to scope creep if you've not got any regular schedule, and it's harder to feel a sense of achievement if you're not releasing regularly.
I was contrasting with that model, though it sounds like I might not be accurately characterizing sprints. We've had some features that have taken over a year to complete, such as a major rearchitecture. The (generally senior) dev assigned to that task has a lot of latitude to break it up according to their judgement, submit individual parts on their own timeline, etc., all while minimizing bookkeeping and coordination with others. As long as they're continuing to make forward progress according to an initially vague, sensible, iterative plan, we tend to leave our established devs to their own devices. For newer devs and where multiple devs are collaborating on a feature together, we encourage at least weekly check-ins.
On one recent team, we did 2 week sprints with a couple releases per week (basically, one per feature that finishes and makes it through QA).
The 2 week cycle was our planning/work prep cadence. If a feature isn't fleshed out by its owners and stakeholders prior to the start of the sprint, we're not going to ask any devs to pick it up during that sprint. If it is ready, we'll start to plan it, and estimate how long it will take, talk about debt-vs-speed tradeoffs, etc.
I think I might dislike the model you describe because it seems potentially isolated around "my feature" vs "the rest of the team's feature," and because I think making the planning cycle 4 weeks instead of two might cause more planning pain for each release.
We don't have "planning cycles" except for quarterly prioritization to realign on which features matter the most (exceptional features occasionally get prioritized outside the process). When you finish one project, you pick another that's interesting to you that's near the top of the priority list, with support from our Product team and Engineering Operations.
Disclaimer: These are subjective opinions, and I recognise that some developers thrive in this environment. Also, this is a comment on Agile in the wild, rather than in principle.
That's what a sprint is.
Every 4 weeks, we release whatever has been merged in the last 4 weeks. One dev might have 8 independent changes in a release or 0. We typically have a handful of significant changes that land each release and a bunch of minor improvements. Still, there's not much effort to estimate when any particular feature might land.
When a large feature is getting close to completion, the dev might choose to push a little bit to hit a particular release. There's not really any external pressure to do that, though.
That's still a sprint?
And not the work adapt to a mechanistic interaction style.
When we need frequent feedback we do frequent feedback. When we need deep group planing we do group planing periods. When we need intensive coding we do intensive coding with occasional follow ups. We track progress, we monitor workforce. When someone hit the wall that person cries for help and we do something about it - depends on the trouble what and how. In one position we used it but was sooo mechanistic and insufficient to address the varying needs that it died off quickly.
I believe it cold be great for certain situations. Simple repetitive ones? But otherwise looks like yet another holy grail management method people hype for a while and might join the club of all other holy grail management techniques being praised to the heavens in their time throughout the history so the world was adjusted to those not the other way around. Then found yet another holy grail out of disappointment.
Not to mention that seemingly no one knows what it is exactly and how it should be used, some do this was, some do that way. And so we are back to the adaptive management now. : )
It must be good for a certain set of situations but it is odd that this is a crucial bit in interviews if someone have experience in it or not, like if it was impossible to adapt to the management style of the task at hand and it would require special skills or capabilities requiring preexisting abilities or formal training....
I don't have a great opinion of sprints for a couple of reasons. I used to have a job that did sprints. Development was often rushed to fit the sprints which led to a high rate of defects. And now I'm working with a vendor that does development in sprints. When we ask them for changes, it adds a large amount of lag to actually getting them because we have to wait up to 2 weeks for them to reprioritize, and then at least 2 weeks for release.
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.
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.
Meetings are apparently the one thing that no one tries to optimize, in our industry ostensibly hyperconcerned with optimizing things.
Disclaimer: I hate most meetings.
Then there is also the side effect of our monkey brains to give importance to people you see often. Stand-ups cultivate the feeling of "this is a team". It's important to show members what the team is.
Stand-ups however are not a requirement for a good functioning team. I'm leading a small team of senior devs and, despite my praise above, I decided against daily stand-ups. There is sufficient intelligence and communication, and just general professionalism in everyone in the team, that daily stand-ups are not worth the hassle and corporate feeling.
As a rule of thumb, if there are junior devs on the team, I would insist on having daily stand-ups on that team.
"Agile mandates post-it notes" kinda stuff
Standups could be very well replaced by a chat channel, for example. This way it's broadcast, recorded and can be a bit async as no-one needs their turn to speak
I used to enjoy meetings when I first started there because it felt good to have a break from staring at a screen all day but I quickly got tired of being invited to 90 minutes long meetings on project X where my input was only needed for one point out of the 12 on the meeting agenda.
However it's also nice to discover if work done by other devs interact with what I might be working on. Maybe I'm working on changing some logic in a module, and some other dev is about to make an integration for a customer which will involve that module indirectly.
He might not be aware of this indirect dependency, so I can give him a heads-up and now we know we must keep in touch over this work.
It's also good in case someone else has any good ideas for solving an issue. Maybe someone knows of a tool or a service which can do the job. Maybe someone has experience on that sort of stuff, so the dev doing the work knows who to ask for advice.
This is the only regular internal meeting I have though. There might be a case-specific one or similar once or twice a month, the rest is just ad-hoc with 1-2 others as needed via Teams or dropping by the office (pre-pandemic).
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.
I've been on other teams where, without standup, people would go for days without working on or talking to anyone.
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.
Standups are the first time I ever noticed that "X is ableist" without someone else having to point it out to me. My introduction to standup meetings was a bit after I screwed up my ankle. I spent a lot of time thinking in that meeting about all the injuries and disabilities that would make the forced standing still for 15 (or let's be honest, 30) minutes an imposition. Spines, knees, hips, ankles, toes. In our industry you have to be able to manage sitting at a keyboard for 8 hours, until 'Agile' came along.
Writing this out, I'm beginning to wonder if standups (the "Stand Up" part) aren't in fact illegal under US and/or EU law.
We have "standups" without physically standing up. I've worked places where actually standing was the norm, but they definitely wouldn't have made someone stand if they had a medical reason not to (use some common sense!)
The basic premise of a quick meeting to make sure everyone is aligned, and that any blockers are communicated seems sound to me.
However, I would have thought it's taken as given that you only stand if you are able and the real goal is to keep the meetings short and focused; with physical "discomfort" being an inspired motivator.
I'm not too young. Agile is definitely bad. It's a cancer on software development.
Which could be taken as a rather funny take on "here's what happened" ;)
With JS the experience on the mobile web is garbage. It's difficult enough to find quality content as it is, we don't need all the added "benefits" of JS.
They kind of don't though, given this is such a tiny fraction of visitors
Please don't complain about website formatting, back-button breakage, and similar annoyances. They're too common to be interesting. Exception: when the author is present. Then friendly feedback might be helpful.
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.
When everyone wakes up and goes to work they can just get to work.
If you didn’t accomplish anything for the day, you put that in your end of day email/report and explain why, and what you need to do to ensure it doesn’t happen again.
If you’re actually sick or need a day off you notify your superior. They will work with the team to pause or reassign your work while you’re gone, and when you get back you resume your work.
The team experimented with cancelling stand-up AND started doing a version of 20% time with a strict rule about "fun projects only".
As with any process experimentation, mixing two initiatives at the same time makes it impossible to understand the results.
(1) impediments shouldn't fester for a significant fraction of a day, and usually don't require synchronous team-wide communication.
(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.
It's very hard to make the call about when it's worth interrupting another team member. You're potentially setting back their work a significant amount, and it tends to feel like an admission of failure. Having a regular scheduled time to do it takes a lot of the sting out of it.
If an issue can wait for a daily standup, it can even moreso be communicated and any necessary synchronization planned through asynchronous communication which doesn't require interruption at all.
Most people get both standup and constant interruption.
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).
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.
If you're having issues with your work fitting into a sprint, have you dug into why? Are you breaking down the task into small enough units that make them more digestable in a sprints worth of time?
We also punted on standups, I never found them to be valuable and past experiences felt like they were more of a mechanism to get people into the office at a certain time. We do a once a week team meeting with an agenda that you can add to before hand. We discuss anything that needs to be discussed as a team and unblock anyone then. I trust everyone is doing work daily and I can check our sprint board without having everyone tell me what they worked on daily.
Yes - things just take awhile to get done. We split things up as much as possible.
If we didn't have daily stand ups I think that would be helpful.
BTW I am the Lead who acts as both the product owner and scrum master.
Fortunately my current team does 11:15 which works great, especially from home.
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.
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.
That’s great during the induction phase, but if that quality is still valuable to you a year later? Run.
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.
What's making a short and focussed daily synchronization meeting (aka: Daily/Standup) useful for me:
* Short and focussed, 15min max, no excuse
* Focus on impediments and try to figure out if the team can help.
* VERY short update on what I'm planning to do today (to make synergies visible)
* 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)
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.
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.
Means there is a blocker and the person is stuck or meandering and can't or won't explain it. Major yellow flag.
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.
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.
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.
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.
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.
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).
short and sweet.
and gives enough insight for people to ask for help or just get a feeling of progress...
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.
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.
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.
Improving that kind of stuff always makes development less frustrating, narrowing the time between something is coded and something is running in production.
Who cares that you are getting more done.... Will somebody please think of the manager's poor egos!
Here goes: 'Meetings' are a time to do a specific thing.
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.
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.
> Planning, this is a meeting for planning.
> Backlog, this is a meeting for grooming the backlog in preparation for planning.
> Retrospective, this is a meeting for retrospectively looking at the sprint to improve the process for the next sprint.
> Standup, this is a quick daily checkup for each team member's progress, planned actions and blockers.
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.
Easy so far right? Now the bit that people struggle with.
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.
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.
