4 ms·

I've heard this, and I've even seen it in plenty of poorly performing businesses, but I've never actually seen it in a highly performing, profitable tech compan

I've heard this, and I've even seen it in plenty of poorly performing businesses, but I've never actually seen it in a highly performing, profitable tech company. Other than at the new grad level but it's treated as net-negative training while they learn how to build consensus and scope out work. Not coincidentally, the places I've seen this approach to work are the same places that have hired me as a consultant to bring an effective team to build something high priority or fix a dumpster fire.

tikhonj 9mo ago
A lot of highly performing teams don't even use tickets.
- win311fwg 9mo ago
  Do any highly performing teams use tickets? A fly-by-night charlatan successfully pushed ticking into our organization in the past year and I would say it was a disaster. I only have the experience of one, but from that experience I am now not sure you can even build good software that way. I originally hoped it was growing pains, but I see more and more fundamental flaws.
  - yurishimo 9mo ago
    I’ve worked at one, but it required a PM who was ruthless about cutting scope and we focused on user stories after establishing a strong feedback pipeline, both technically through CI/CD/tests and with stakeholders. Looking back, that was the best team I’ve ever worked in. We split up to separate corners of the company once the project was delivered (12 month buildout of an alpha that was internally tested and then fleshed out). Maybe I had greenfield glasses but I came in for the last 3 months and it was still humming.
  - layer8 9mo ago
    How do you keep track of tasks that need to be done, of reported bugs and feature requests?
    - win311fwg 9mo ago
      Previously? There was an understanding of the problem trying to be solved. The gaps left the pangs of "this isn't right". Now I have no way to know where things stand. It's all disconnected and abstracted. The ticket may suggest that something is done, but if the customer isn't happy, it isn't actually. Worse, now we have people adding tickets without any intent to do the work themselves and there isn't a great way to determine if they're just making up random work, which is something that definitely happens sometimes, or if it truly reflects on what the customer needs. You might say that isn't technically a problem with ticketing itself, and I would agree. The problems are really with what came with the ticketing. But what would you need tickets for other than to try and eliminate the customer from the picture? If you understand the problem alongside the customer, you know what needs to be done just as you know when you need to eat lunch. Do you create 'lunchtime' tickets for yourself? I've personally never found the need.
      - whstl 9mo ago
        I find that the current way we do Scrum is way more waterfall-ish than what we had before. Managers just walked around and talked, and knew what each person was doing. We traded properly working on problems for the Kafkaesque nightmare of modern development.
        win311fwg 9mo ago
        Thing is, Scrum isn't supposed to be something you do for long. As you no doubt know, Agile is ultimately about eliminating managers from the picture, thinking that software is better developed when developers work with each other and the customer themselves without middlemen. Which, in hindsight, sounds a lot like my previous comment, funnily enough, although I didn't have Agile in mind when I wrote it. Except in the real world, one day up and deciding no more managers on a whim would lead to chaos, so Scrum offered a "training wheels" method to facilitate the transition, defining practices that push developers into doing things they normally wouldn't have to do with a manager behind them. Once developers are comfortable and into a routine with the new normal Scrum intends for you to move away from it. The problem: What manager wants to give up their job? So there has always been an ongoing battle to try and bastardize it such that the manager retains relevance. The good news, if you can call it that, is that we as a community have finally wisened up to it and now most pretty well recognize it for what it is instead of allowing misappropriation of the "Agile" label. The bad news is that, while we're getting better at naming it, we're not getting better at dealing with it.

tikhonj 9mo ago

A lot of highly performing teams don't even use tickets.

win311fwg 9mo ago
Do any highly performing teams use tickets? A fly-by-night charlatan successfully pushed ticking into our organization in the past year and I would say it was a disaster. I only have the experience of one, but from that experience I am now not sure you can even build good software that way. I originally hoped it was growing pains, but I see more and more fundamental flaws.
- yurishimo 9mo ago
  I’ve worked at one, but it required a PM who was ruthless about cutting scope and we focused on user stories after establishing a strong feedback pipeline, both technically through CI/CD/tests and with stakeholders. Looking back, that was the best team I’ve ever worked in. We split up to separate corners of the company once the project was delivered (12 month buildout of an alpha that was internally tested and then fleshed out). Maybe I had greenfield glasses but I came in for the last 3 months and it was still humming.
- layer8 9mo ago
  How do you keep track of tasks that need to be done, of reported bugs and feature requests?
  - win311fwg 9mo ago
    Previously? There was an understanding of the problem trying to be solved. The gaps left the pangs of "this isn't right". Now I have no way to know where things stand. It's all disconnected and abstracted. The ticket may suggest that something is done, but if the customer isn't happy, it isn't actually. Worse, now we have people adding tickets without any intent to do the work themselves and there isn't a great way to determine if they're just making up random work, which is something that definitely happens sometimes, or if it truly reflects on what the customer needs. You might say that isn't technically a problem with ticketing itself, and I would agree. The problems are really with what came with the ticketing. But what would you need tickets for other than to try and eliminate the customer from the picture? If you understand the problem alongside the customer, you know what needs to be done just as you know when you need to eat lunch. Do you create 'lunchtime' tickets for yourself? I've personally never found the need.
    - whstl 9mo ago
      I find that the current way we do Scrum is way more waterfall-ish than what we had before. Managers just walked around and talked, and knew what each person was doing. We traded properly working on problems for the Kafkaesque nightmare of modern development.
      - win311fwg 9mo ago
        Thing is, Scrum isn't supposed to be something you do for long. As you no doubt know, Agile is ultimately about eliminating managers from the picture, thinking that software is better developed when developers work with each other and the customer themselves without middlemen. Which, in hindsight, sounds a lot like my previous comment, funnily enough, although I didn't have Agile in mind when I wrote it. Except in the real world, one day up and deciding no more managers on a whim would lead to chaos, so Scrum offered a "training wheels" method to facilitate the transition, defining practices that push developers into doing things they normally wouldn't have to do with a manager behind them. Once developers are comfortable and into a routine with the new normal Scrum intends for you to move away from it. The problem: What manager wants to give up their job? So there has always been an ongoing battle to try and bastardize it such that the manager retains relevance. The good news, if you can call it that, is that we as a community have finally wisened up to it and now most pretty well recognize it for what it is instead of allowing misappropriation of the "Agile" label. The bad news is that, while we're getting better at naming it, we're not getting better at dealing with it.