4 ms·

Man, this hits hard. Especially this point: Efficiency + surprise = shocking price tag. Resilience + surprise = a minor bump. Reading it after the fact sounds

by whstl 4y ago

Man, this hits hard. Especially this point: Efficiency + surprise = shocking price tag. Resilience + surprise = a minor bump. Reading it after the fact sounds obvious, and I kick myself for not realizing it before, but yes. One of the most stressful parts of my career was when we accepted trying to a crazy plan from a crazy CTO, where "every release has to have a new special feature". "Nothing big", we thought, until we saw the insanely detailed deliverables from design. I tried to push back but got called a pessimist. We then obviously worked on 100% capacity for a few months and it "worked", until it didn't. Things started collapsing due to technical issues, bit rot and "random" security issues. In the end we found the design and product teams were also working on 100% capacity. The plan had been hailed as a fantastic achievement in a company-wide meeting, so scrapping it took an insane amount of convincing.

claytonjy 4y ago
Corollary from your anecdote: "crunch time works, but not for long". I suppose crunch time is >100% efficiency (extra hours), so that's why your CTOs plan lasted way longer than crunch time ever should. Looking back, how much earlier would you have had to pull back efficiency to avoid the later issues? Would a month have been fine? Maybe two?
- whstl 4y ago
  Good question. IMO, one sprint or two weeks was already a lot. The damage was done from the beginning. It generated a lot of stress, eroded the relationship of design and dev teams, and between the CTO and employees due to our complaints not being addressed on time. I think the distinction between this and "crunch time" is that crunch time is meant to be temporary, even when it isn't. In this case the prospect that this wouldn't ever change eventually became as stressful as the work itself, or perhaps more.
  - claytonjy 4y ago
    That makes sense; it's not just "this sprint sucks", it's the expectation the next one will also suck, and the one after that, etc. Was the design team fine during this time? They had no trouble designing enough stuff for you to implement, it didn't weigh on them in the same way?
    - whstl 4y ago
      No, some of them also confided they were heavily stressed due to pressure to deliver. I urged them to "work less" but the pressure was still coming in from above.
      - jcelerier 4y ago
        how much $$$ did the company make, before and after?
        whstl 4y ago
        That's a great question! Because of this strategy? I wouldn't say it moved the needle in the slightest, and that was entirely expected. There was however a lot of churn because the platform we operate on launched some features that made our own product obsolete. The goal of this strategy was merely to make the process and the releases more predictable, but it ended up being at the expense of designers and developers.
- nicbou 4y ago
  Kitchen analogies have replaced car analogies as ny favourite. You can only cook for so long without cleaning your work area or prepping more ingredients. Eventually, the efficiency gains of not doing those things catch up with you.
manfre 4y ago
Crunch time is often better described as a death march.
draw_down 4y ago
[dead]
danjac 4y ago
The "insanely detailed deliverables from design" is a red flag and indicates a factory conveyor belt mentality: product comes up with idea, hands off idea to design, design hands off to developers, who then have to implement the design down to the pixel. The "hand-off" approach is incredibly wasteful and counter-productive. The design team should be building designs in tandem with input from developers and product, so that the final agreed-upon design takes into account business requirements and technical constraints. Nor should this be "final" in the sense that during implementation there may be unexpected problems that require modification of that design - "hey, turns out this widget doesn't work in Safari, we're going to have to come up with a workaround". As long as what comes out in the end is a usable implementation of the business requirement, it doesn't matter whether it matches some arbitrary design ideas from three months ago.
- whstl 4y ago
  Yep, good observations. One of the main complaints was that we regressed to a waterfall process and we were doing Scrum only for show.
  - danjac 4y ago
    I think the problem with agile (whatever the exact flavour) is that if you don't adopt the mindset across the organization, and just enforce it in your dev team, you just end up with waterfall-with-extra-steps.
    - whstl 4y ago
      Good point. In this case we had a misapplied "dual-track agile" structure, which in theory means the whole organization is "doing agile", but since the feedback loop is super long, it's indeed just waterfall-with-extra-steps. This is not the first time I see this happening. Product Managers love it. IMO it is classic micromanagement. Product Managers want more control of the process than is afforded by a "self managing agile team", so the only chance of control is achieved by isolating team communication and having "small" deliverables that they have full control over. IMO that's alright, but it's waterfall. You can't expect the advantages of an agile process to apply to this.

by whstl 4y ago

claytonjy 4y ago

Corollary from your anecdote: "crunch time works, but not for long". I suppose crunch time is >100% efficiency (extra hours), so that's why your CTOs plan lasted way longer than crunch time ever should. Looking back, how much earlier would you have had to pull back efficiency to avoid the later issues? Would a month have been fine? Maybe two?

whstl 4y ago
Good question. IMO, one sprint or two weeks was already a lot. The damage was done from the beginning. It generated a lot of stress, eroded the relationship of design and dev teams, and between the CTO and employees due to our complaints not being addressed on time. I think the distinction between this and "crunch time" is that crunch time is meant to be temporary, even when it isn't. In this case the prospect that this wouldn't ever change eventually became as stressful as the work itself, or perhaps more.
- claytonjy 4y ago
  That makes sense; it's not just "this sprint sucks", it's the expectation the next one will also suck, and the one after that, etc. Was the design team fine during this time? They had no trouble designing enough stuff for you to implement, it didn't weigh on them in the same way?
  - whstl 4y ago
    No, some of them also confided they were heavily stressed due to pressure to deliver. I urged them to "work less" but the pressure was still coming in from above.
    - jcelerier 4y ago
      how much $$$ did the company make, before and after?
      - whstl 4y ago
        That's a great question! Because of this strategy? I wouldn't say it moved the needle in the slightest, and that was entirely expected. There was however a lot of churn because the platform we operate on launched some features that made our own product obsolete. The goal of this strategy was merely to make the process and the releases more predictable, but it ended up being at the expense of designers and developers.
nicbou 4y ago
Kitchen analogies have replaced car analogies as ny favourite. You can only cook for so long without cleaning your work area or prepping more ingredients. Eventually, the efficiency gains of not doing those things catch up with you.

manfre 4y ago

Crunch time is often better described as a death march.

draw_down 4y ago

[dead]

danjac 4y ago

The "insanely detailed deliverables from design" is a red flag and indicates a factory conveyor belt mentality: product comes up with idea, hands off idea to design, design hands off to developers, who then have to implement the design down to the pixel. The "hand-off" approach is incredibly wasteful and counter-productive. The design team should be building designs in tandem with input from developers and product, so that the final agreed-upon design takes into account business requirements and technical constraints. Nor should this be "final" in the sense that during implementation there may be unexpected problems that require modification of that design - "hey, turns out this widget doesn't work in Safari, we're going to have to come up with a workaround". As long as what comes out in the end is a usable implementation of the business requirement, it doesn't matter whether it matches some arbitrary design ideas from three months ago.

whstl 4y ago
Yep, good observations. One of the main complaints was that we regressed to a waterfall process and we were doing Scrum only for show.
- danjac 4y ago
  I think the problem with agile (whatever the exact flavour) is that if you don't adopt the mindset across the organization, and just enforce it in your dev team, you just end up with waterfall-with-extra-steps.
  - whstl 4y ago
    Good point. In this case we had a misapplied "dual-track agile" structure, which in theory means the whole organization is "doing agile", but since the feedback loop is super long, it's indeed just waterfall-with-extra-steps. This is not the first time I see this happening. Product Managers love it. IMO it is classic micromanagement. Product Managers want more control of the process than is afforded by a "self managing agile team", so the only chance of control is achieved by isolating team communication and having "small" deliverables that they have full control over. IMO that's alright, but it's waterfall. You can't expect the advantages of an agile process to apply to this.