daily meetings are fine but they should be really fast. last team I was on had 3 teams of devs and our meeting lasted 15 minutes. was well run. new team only has like 5 devs and often we sit there for 45 minutes. its always at least 30. just terrible.

meetings should be for gauging progress to plan releases and so devs can indicate if they have an issue and need help.

Wolfram,

While you get up to speed, why can't these developers review and accept/merge each other's PRs?

Yeah, the stuff that's farther out isn't going to be broken down to the same detail as the stuff for the next sprint. The cone of uncertainty and all. In Jira I'm pretty sure we were using Epochs for those, which didn't get supporting stories until much closer to when they were going to be worked on.

That's interesting, I don't know that I like the idea that the teams don't try and hit their sprint commits. A lot of the Religion of Agile is that high performing teams can manage their commitment, which means doing whatever it takes to finish everything every sprint.

However, scheduling a team at full capacity is a great way to burn out a team and slow throughput of work items down. From a planning perspective I'd rather this was managed by scheduling a 50 point a sprint team to only 40-45 points than to be scheduling stuff you know isn't going to get done.

Stuff like unplanned work, PTO and break fix can eat up that spare capacity and result in moving things out of the sprint so the team can make their sprint commit. The goal is to know what a team has done so you can plan what they can do in the future better.

Exactly! That was my plan all along. This guy seemed to have an issue with it.

Like what possible input can I have on a new module that has hundreds of lines of code in a tech stack that is pretty new to me in a code base that I literally saw for the first time 7 days ago?

To clarify, I've been working at our company in backend java for 6 years along with some nodejs for web clients. This stack is c++/nodejs hardware modules for retail terminals. Even though I know some nodejs, I'm not an expert and not at all familiar with operating system level nodejs.

Don't let people sit down during stand-ups, it's in the name.

Yeah. And if the noise situation is manageable, don't even reserve and go into a "meeting room." Standups can happen where you work. Get rid of the 10 minutes of bull**** *around* every meeting too (waiting for participants, gathering somewhere, having to remember oh right it's meeting time etc)

Hey guys, let's do our standup. You go. OK, good, now you. etc.

This is basically the problem, right? In order to hit some artificial goal you just reduced the amount of work you’re going to do. People will hit the lowered goal and then coast for some amount of time between when they’re done and the next planning.

If instead you plan for 60 points and are happy with 45 done (we also don’t estimate and I’m super happy about that) people always know what should be worked on next, have a reasonable goal each sprint, and have a hard goal each sprint as well.


I’m not sure what you mean by moving stuff out of the sprint. Do you mean doing that mid sprint? Seems like a reasonable way to work, but it’s not what I would imagine as a team always hitting their sprint goals. Like if you always hit the goal by removing the stuff you didn’t have time to work on, that doesn’t seem particularly meaningful as an accomplishment.

In the end I doubt it really matters much though and there’s probably lots of ways and approaches that can work.

I was just reading some agile documentation. Man there is some strong kool aid out there.

One thing talked about 4 hour sprint reviews and 3 hour sprint retrospectives for month long sprints. That seems like crazy town to me. It doesn’t even include the planning / stand up meetings.

I'm surprised you guys find stand-ups useful. In my experience they're only useful when a portion of the team is working on a project with interdependent pieces. I guess most of our work is more isolated than that so stand-up becomes I'll be working on A, B, and C today. Which while very short, provides zero value imo.

I guess there are two parts:

1. Somebody needs to know in general how the team is doing. Whether its a team lead, tech lead, PM, Scrum Master, ... someone is presumably responsible for the workings of the team. Daily meetings help with this a lot.

2. Team members should know what each other are doing so they avoid duplicating work, can give meaningful reviews, know who to ask for problems/help in the future, have meaningful feedback on bigger picture team goals, etc. I guess if there are no dependencies or related work between team members (even not necessarily immediate but over time as well) then you have a very poor team structure and stand ups probably aren't your biggest problem.

We always have a PM/scrummaster - and sometimes that's even two different people. It allows us devs to act like bratty kids, and make the scrummaster do all the moderation work.

But the best thing by far we do is have SQA on every standup and other meetings from day 1. So they are always in the loop They also sit in the same area with the devs and are pretty much involved with everything.

I've worked on other teams in a different department where SQA was on another floor. It's like night and day. There's a ton of miscommunication and passive aggression. Common workflow is 1) SQA creates bug, puts it in dev queue, 2) dev replies it's not a bug because of XYZ. SQA refuses to close bug. Bug sits there until one party finally takes the initiative to talk about it. It drove me nuts.

This looks interesting: https://github.com/funkia/list?WT.mc...itter-jeliknes

jfc just let me write javascript

I think I've had this discussion before ITT too, but I also don't miss having QA people. I think they have tough jobs but the process of building and testing your own stuff (or your teammates stuff) just seems so much better to me.

I do agree that if you have them they have to be equal to the devs. Absolutely.

At my old job - if we didn't have QA we'd be much slower. They allowed the devs to focus mostly on golden path and not spend a ton of time testing for every edge case. Which is very time consuming due to stuff like setting up test users - which has to be done with a bunch of hairy back end systems we don't control.

I also like the primary detailed domain knowledge of *what* the system does residing with people who know nothing about *how* it works under the covers. Feels cleaner to me.

I've had a couple standup experiences, both at my current company

Situation A: when I first started here, very small team (5-6 engineers), had a brief standup every morning to sync, there were lots of connections between our work so it was pretty useful

Situation B: on a much larger team, forget if it was daily or 3x/week but there'd be a morning standup for the whole team of ~30-40 producers + engineers. Worthless, total waste of time, I very quickly figured out I could avoid it because I didn't sit in the same area as the rest of the team so I peaced the **** out of that one

ya this is super important. most of the reports from devs should just be "no update". they should only be commenting if they need help with something, need to communicate something important that may effect others, or need to set up a meeting later for deeper discussion. its absolutely not a time to rattle off all the work you are doing. no one curr.

I think the first part is maybe very company/product specific. My general feeling is that developers should be able to automate and do all the things that you're talking about because thats the best way to actually test stuff (which they should be doing!).

I disagree with the *what* and *how* comment. It does feel cleaner, but it feels like a "false win" in the sense that those two are so tightly interconnected in practice that its going to be way more efficient to expect people to know both of those things. For any sort of complex system I don't see how developers can add new features without a good understanding of the existing features and how/what they're suppose to do.




I remember getting to this point (~20-25 people in the all-company scrum). We switched it to a monthly (optional) demo where people could show what they're working on. Easy way to still showcase what you're doing to everyone without being a giant waste of time.


A few years ago I switched from doing standup with individual updates and instead go through Trello. We have a list of QA tasks and a list of In progress tasks and we just go through those and whoever has anything to say, says it. Often the update it just "Working on it" or "Didn't work on it".

Then at the end I ask if anybody has anything to add or anything we missed.

I actually like it way better than the personal updates because its less opportunity to ramble off topic or list out all the non team things they did.

Definitely there are. My understanding is that if it becomes obvious someone isn't going to hit their commit during stand-ups; whatever the reason, the team figures out how to get those stories across the line. If that isn't feasible the team negotiates to move those stories out of the sprint. Likewise if someone finishes their stuff early the team can negotiate to bring additional work into the sprint.

The goal is for neither situation to be common, if it is there is something wrong with your estimates or with what you think your velocity is it should be talked about at the retrospective. You do this at stand-up to increase accountability and transparency in the process.

This seems cool maybe: Proton Native, React Native for desktop w/ native components (no electron/chromium)

My team has backend java developers and front-end javascript developers so it's very helpful to do standup everyday since I'm not really aware of their progress on a daily basis (nor them for me) and we rely on each other so tightly.

Jesus if I had a meeting every morning I might kill myself.

Sent from my Pixel using Tapatalk

I have a 7 am every Wednesday and am being pressured to start attending the 630 Monday and Thursday calls

Why?