7 ms·
> CS graduates from MIT and Stanford could be expected to justify hours of their time in "Scrum ceremonies" (which means that they aren't trusted, which means t
by Nacraile 11y ago
> CS graduates from MIT and Stanford could be expected to justify hours of their time in "Scrum ceremonies" (which means that they aren't trusted, which means that their credentialing institutions and work experiences aren't trusted). Even average programmers in the bowels of Fortune 500's IT organizations had more autonomy than the typical "Agile" programmer today.
If that's been your experience with Agile, you've have the misfortune of seeing Agile done horribly wrong in a patholgically unhealthy workplace. You may also be romanticizing a bit about old school way of doing things (I have a co-worker who used to work at a major jet engine manufacturer. They were expected to be sitting at their desks when the bell (literally!) rang at 8:30 am. They were expected to wait for the bell to ring break time in before they went to the washroom. As a programmer! Scrum ceremonies aren't sounding so bad).
Seriously, stand-up isn't supposed to be about accounting for your time, and it isn't supposed to be a vehicle for top-down micro-management. If it's either of these things for you, the problem is your organization, not your specific process.
In my (very positive) experience, stand-up is about maintaining situational awareness in the team. It's a well defined point for people to raise general questions if they've run into ambiguity, or cast a wide net if they've run into impediment. To-do lists are de-emphasized; it's an opportunity to pick the collective brain and gain some clarity / help with what you're doing.
- s73v3r 11y ago"Seriously, stand-up isn't supposed to be about accounting for your time" And yet, in most places, it devolves into just that. "In my (very positive) experience, stand-up is about maintaining situational awareness in the team." And how could this not be more easily done with bug trackers and status emails? "it's an opportunity to pick the collective brain and gain some clarity / help with what you're doing." Most people don't pay attention to other's updates; especially updates that they know aren't relevant to what they're working on.
- Nacraile 11y ago> "In my (very positive) experience, stand-up is about maintaining situational awareness in the team." > And how could this not be more easily done with bug trackers and status emails? As far as I'm concerned, bug trackers and status emails are functionally equivalent to stand ups at a scrum board. I find email to be a terrible form of communication for open-ended discussion and would much rather do so face to face, but it's self-evidently a matter a personal preference. > "Seriously, stand-up isn't supposed to be about accounting for your time" > And yet, in most places, it devolves into just that. The fact that some people do it wrong is a straw man. > "it's an opportunity to pick the collective brain and gain some clarity / help with what you're doing." > Most people don't pay attention to other's updates; especially updates that they know aren't relevant to what they're working on. I've always found people are pretty good at picking up on the verbal cues when somebody's asking a question and answering it, even if they weren't paying particularly close attention.
- conradfr 11y agoI'm dubious of DSM's merits. I've asked people (in small team nonetheless) less than one hour after a DSM what others have done / were doing and usually they couldn't remember. I personally think a good team leader / project manager and an issue tracker + git annotations is better.
- Nacraile 11y agoI'm not surprised that people quickly forget irrelevant information. The value is in the times somebody says "hey, it sounds like you're touching code I'm working in, lets co-ordinate" or "it sounds like you're doing task A the hard way, lets talk about it". On my team, the throw-away todo listing usually goes very quickly. The value is in the discussion it frequently spawns. In my environment, stand-up spawns such discussion sooner and more reliably than CR/commits/etc.
- meatysnapper 11y agoAgile is the gonorrhea or methodologies. At best, it is a minor annoyance; at worst it really impacts your ability to get it on.
- jackmaney 11y ago> Seriously, stand-up isn't supposed to be about accounting for your time BWAHAHAHAHAHA!!! No. Stand-up is all about accounting for time: * What did you do yesterday? (That's accounting for time) * What are you working on today? (That's also accounting for time) * What roadblocks/hurdles are you encountering (That's accounting for things that take unexpected amounts of time...ie also accounting for time)
- michaelochurch 11y agoFirst of all, some kind of periodic status meeting is a necessary evil. Everyone hates giving status reports and justifying time. It's humiliating and time-consuming. It probably has to happen. If you don't have a scheduled, formal status reporting, you end up with impromptu status pings that are astronomically more annoying and lead people to give up on getting anything done (because there's nothing more anxiety-inducing and flow-breaking than an unreliable environment in which you can be expected to give status at any time). The upper limit for senior people before they start to get pissed off is probably: the lowest of 10 minutes per week person, or 60 minutes for a weekly meeting, or 20 minutes for a daily meeting. So with a team of 8, you can either have a 60-minute meeting or daily 16-minute meetings. With a team of 4, you're limited to 40 minutes for a weekly meeting or 8 minutes of status reporting for a daily meeting. Standups are good insofar as they allay toxic suspicion that <Person X> isn't contributing. They're like prisons: not innately good, but the aspect of human nature that they exist to control or mitigate is worse. Of course, most seasoned people realize that the game of status reporting is like playing Scrabble. It's not about dropping the 100-point words. It's about not opening up the board (and getting nagged with follow-on questions). Now, I believe you that most of these Agile methodologies were designed with better intentions. I absolutely agree. But they devolve. We've seen that, over and over and over. They don't fix things. They make tolerably broken things more intolerably broken. If you're in an environment where business runs the show and engineers just implement (i.e. business-driven engineering) then the right thing to do, often, is to become politically inert, silently learn new skills, and save your energy (slack) while opportunities are few so you can step up when the business-driven engineering regime goes away (or when you change companies). Scrotum gets in the way of that, and by putting such an emphasis on micro-estimates (numbers that will always turn into political tools) it generates politics.