3 ms·

High-trust and low-trust understate the severity of the phase change, which is more accurately described as a shift from trust-density to trust-sparsity. You go

High-trust and low-trust understate the severity of the phase change, which is more accurately described as a shift from trust-density to trust-sparsity. You go from a state where people spawn with the "bozo bit" off to one where they spawn with it on. You get a completely different political dynamic when that happens. Obviously, trust has varying degrees and context. In Japan, you can leave your laptop at a cafe; in the U.S., you probably wouldn't. That doesn't mean that we're "low trust" or trust-sparse. We might generally trust most people to be decent while aware of the ~0.05% (?) chance per person (that someone steals the computer. What is changing is trust with regard to competence. People were never so foolish as to trust all others without limits, but there used to be an assumption of competence in the professional world. Institutions like universities are less trusted, and so are people in general when it comes to basic competence and readiness for autonomy. It would be unthinkable, 20 years ago, that 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. Right now we are in an era of organizational decline. It's not necessarily catastrophic; it might not even be bad. What it does mean is that institutions (universities, professional organizations, corporations, and even unions) have lost their role as central brokers of trust. It raises interesting questions. Thus far, most of the successful startups have been beneficiaries of institutional decline (and, again, some of those institutions deserved to break down, so I'm not moralizing) and there doesn't seem to be any economic reward to build institutions (as opposed to mere corporations, smaller in scope) up... so it doesn't happen.

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 ago
  I'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 ago
    I'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.

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 ago
I'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 ago
  I'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.