4 ms·

Companies that are very Scrum focused aren't actually all that common in my experience. If your job is depressing because of it, it may be time to look around.

Companies that are very Scrum focused aren't actually all that common in my experience. If your job is depressing because of it, it may be time to look around. Remember to ask how the new place does things, so that you're not stuck with more of the same.

OJFord 4y ago
Not in the sense of 'scrum masters' and certification and all that - that sounds bad but in a different way and I've never experienced it. I just mean 'sprints' and 'tickets' and 'points' and 'stand-ups' really. (Which I assume isn't what you're saying isn't that common, certainly seems it from.. HN I suppose.)
- Ensorceled 4y ago
  How much time are you spending on these artifacts? Sprint planning and 'tickets' should take at most a few hours a sprint for developers (my effort is much higher, of course), standups are 15 minutes a day, points are just estimates.
  - BlargMcLarg 4y ago
    The vast majority doesn't behave like this in practice. Inb4 "That's not Scrum" yes, we know.
    - Ensorceled 4y ago
      Right, I'm trying to lead the OP there :-) I've worked, briefly as a contractor, in one these places before: full day sprint planning, 3 hour retrospectives, 1-2 hour standups, breakdowns of simple stories into sub stories etc. etc. ... but I didn't blame scrum and points for the fact I was miserable.
      - OJFord 4y ago
        I think your point is kind of what I was alluding to with the 'or makes it [i.e. it exists without it] unapologetically transparent' parenthetical? Certainly it's not 'scrum' per se that bothers me - I was carefully not saying 'agile' because I think that's fine it's just the typical method of 'doing it' that I meant, but seem to have fallen into a different trap in the process - but it is the breaking down of the job into actionable work pieces, 'tickets', and some of the ceremony around that, whether strictly 'scrum' or not. But that's just me right, obviously some (lots of) people like it! My initial comment was that it's surprising (to me) how few seem to not like it, so I'm perfectly aware that's just my (and some few others') opinion.
        Ensorceled 4y ago
        > But that's just me right, obviously some (lots of) people like it! My initial comment was that it's surprising (to me) how few seem to not like it, so I'm perfectly aware that's just my (and some few others') opinion. I guess it's a continuum ... I have people on my team right now that are working on a single story, other people who have a few dozen this sprint. If your team is breaking down what would be a single story on my team ... I could see that being annoying. Now, the developer working on that story has a breakdown of tasks that they are managing as sub items in the story, but that's not getting managed with story points or any other heavy weight system.
  - OJFord 4y ago
    It's not really about the time it takes for me, it's the division of work into tiny boring pieces, such that they often feel like they're taking as long to discuss & 'estimate complexity' (don't get me started - we don't have 'capacity' for a certain 'amount of complexity' within a.. two week period, so stop pretending it's not a time estimate - anyway..) as they would to do. I'm reminded slightly of an article submitted here recently - https://martinfowler.com/articles/bottlenecks-of-scaleups/03-product-v-engineering.html https://martinfowler.com/articles/bottlenecks-of-scaleups/03... (though they're not really discussing motivation as such) - it's the detachment of engineering from product, I suppose. Little 'ownership' of or time to spend on thinking about the product experience, just 'do this', 'add that'. If I compare to people I know in other professions - accounting, doctors, tax - they all work more directly with a client or case, manage their own work. Of course they have managers too, but that relationship is more like 'I need some help with this problem that has arisen, let me now brief you on what I've been doing because otherwise you have no context' or longer-term performance etc. - not 'what tiny thing(s) did you do yesterday and which tiny thing(s) will you do today' every bloody morning.
    - robertlagrant 4y ago
      > 's the division of work into tiny boring pieces This is only useful if you want to ship changes iteratively. If you're working a on a big blob of a thing that can have waterfall-style estimation and delivery then you'll avoid all that. > it's the detachment of engineering from product, I suppose This is more likely the cause. The emergence of product as a ruling class over engineering is a problem. Product is a useful concept, but I think we've all assumed only a person with a Product job title can be a product owner in a team, when I think Product adds much more value as a slightly more distant integration point for engineering, marketing, sales, customer support, legal, etc.
      - Viliam1234 4y ago
        > If you're working a on a big blob of a thing that can have waterfall-style estimation and delivery then you'll avoid all that. It seems that among the cool kids, "waterfall" is considered a bad thing that everyone should avoid. I admit I miss the days when I could have spent weeks working on a project without being interrupted by daily "agile" meetings.
- jlokier 4y ago
  > I just mean 'sprints' and 'tickets' and 'points' and 'stand-ups' really. (Which I assume isn't what you're saying isn't that common, certainly seems it from.. HN I suppose.) Those are not common in my experience either. Perhaps I've just avoided working at depressing places :-) I've never worked somewhere which actually named things 'stand-ups', 'points', 'stories', 'retros', or even 'sprints'. I'm familiar with the concepts, both from general reading, and thanks to someone who taught me all about Scrum, which was enough to put me off both Scrum and it's perverted form of Agile. If I hear those things mentioned in an interview, I soon have more questions, because there's "good Agile" and "bad Agile". Sprints have occurred, in that there have been places with regular meeting and review cycles. That can work really well, imho. But even then, from the sound of it I've avoided the kinds of places where people feel under constant 2-weekly pressure to count up story points and highlight competitive ticket metrics. I have a feeling I'll be starting at a place like that soon though. They use Jira, require a ticket for every PR, and by the sound of it are doomed to take a very long time to do anything. The tickets are written for accountability and reporting every change to management, so not written for developers. The approach smells like an anti-pattern to me. I don't expect to stay long; it's just a contract. I wouldn't choose a place like that for a long-term position, but I'm looking forward to the experience to find out what it's like with an open mind. I was hired as an interim team lead, but politics already changed what the role is since signing, and it's also been made clear that TLs there don't get to decide how anything is actually done. We'll see. I tend to bring new energy to a system.

OJFord 4y ago

Not in the sense of 'scrum masters' and certification and all that - that sounds bad but in a different way and I've never experienced it. I just mean 'sprints' and 'tickets' and 'points' and 'stand-ups' really. (Which I assume isn't what you're saying isn't that common, certainly seems it from.. HN I suppose.)

Ensorceled 4y ago
How much time are you spending on these artifacts? Sprint planning and 'tickets' should take at most a few hours a sprint for developers (my effort is much higher, of course), standups are 15 minutes a day, points are just estimates.
- BlargMcLarg 4y ago
  The vast majority doesn't behave like this in practice. Inb4 "That's not Scrum" yes, we know.
  - Ensorceled 4y ago
    Right, I'm trying to lead the OP there :-) I've worked, briefly as a contractor, in one these places before: full day sprint planning, 3 hour retrospectives, 1-2 hour standups, breakdowns of simple stories into sub stories etc. etc. ... but I didn't blame scrum and points for the fact I was miserable.
    - OJFord 4y ago
      I think your point is kind of what I was alluding to with the 'or makes it [i.e. it exists without it] unapologetically transparent' parenthetical? Certainly it's not 'scrum' per se that bothers me - I was carefully not saying 'agile' because I think that's fine it's just the typical method of 'doing it' that I meant, but seem to have fallen into a different trap in the process - but it is the breaking down of the job into actionable work pieces, 'tickets', and some of the ceremony around that, whether strictly 'scrum' or not. But that's just me right, obviously some (lots of) people like it! My initial comment was that it's surprising (to me) how few seem to not like it, so I'm perfectly aware that's just my (and some few others') opinion.
      - Ensorceled 4y ago
        > But that's just me right, obviously some (lots of) people like it! My initial comment was that it's surprising (to me) how few seem to not like it, so I'm perfectly aware that's just my (and some few others') opinion. I guess it's a continuum ... I have people on my team right now that are working on a single story, other people who have a few dozen this sprint. If your team is breaking down what would be a single story on my team ... I could see that being annoying. Now, the developer working on that story has a breakdown of tasks that they are managing as sub items in the story, but that's not getting managed with story points or any other heavy weight system.
- OJFord 4y ago
  It's not really about the time it takes for me, it's the division of work into tiny boring pieces, such that they often feel like they're taking as long to discuss & 'estimate complexity' (don't get me started - we don't have 'capacity' for a certain 'amount of complexity' within a.. two week period, so stop pretending it's not a time estimate - anyway..) as they would to do. I'm reminded slightly of an article submitted here recently - https://martinfowler.com/articles/bottlenecks-of-scaleups/03-product-v-engineering.html https://martinfowler.com/articles/bottlenecks-of-scaleups/03... (though they're not really discussing motivation as such) - it's the detachment of engineering from product, I suppose. Little 'ownership' of or time to spend on thinking about the product experience, just 'do this', 'add that'. If I compare to people I know in other professions - accounting, doctors, tax - they all work more directly with a client or case, manage their own work. Of course they have managers too, but that relationship is more like 'I need some help with this problem that has arisen, let me now brief you on what I've been doing because otherwise you have no context' or longer-term performance etc. - not 'what tiny thing(s) did you do yesterday and which tiny thing(s) will you do today' every bloody morning.
  - robertlagrant 4y ago
    > 's the division of work into tiny boring pieces This is only useful if you want to ship changes iteratively. If you're working a on a big blob of a thing that can have waterfall-style estimation and delivery then you'll avoid all that. > it's the detachment of engineering from product, I suppose This is more likely the cause. The emergence of product as a ruling class over engineering is a problem. Product is a useful concept, but I think we've all assumed only a person with a Product job title can be a product owner in a team, when I think Product adds much more value as a slightly more distant integration point for engineering, marketing, sales, customer support, legal, etc.
    - Viliam1234 4y ago
      > If you're working a on a big blob of a thing that can have waterfall-style estimation and delivery then you'll avoid all that. It seems that among the cool kids, "waterfall" is considered a bad thing that everyone should avoid. I admit I miss the days when I could have spent weeks working on a project without being interrupted by daily "agile" meetings.
jlokier 4y ago
> I just mean 'sprints' and 'tickets' and 'points' and 'stand-ups' really. (Which I assume isn't what you're saying isn't that common, certainly seems it from.. HN I suppose.) Those are not common in my experience either. Perhaps I've just avoided working at depressing places :-) I've never worked somewhere which actually named things 'stand-ups', 'points', 'stories', 'retros', or even 'sprints'. I'm familiar with the concepts, both from general reading, and thanks to someone who taught me all about Scrum, which was enough to put me off both Scrum and it's perverted form of Agile. If I hear those things mentioned in an interview, I soon have more questions, because there's "good Agile" and "bad Agile". Sprints have occurred, in that there have been places with regular meeting and review cycles. That can work really well, imho. But even then, from the sound of it I've avoided the kinds of places where people feel under constant 2-weekly pressure to count up story points and highlight competitive ticket metrics. I have a feeling I'll be starting at a place like that soon though. They use Jira, require a ticket for every PR, and by the sound of it are doomed to take a very long time to do anything. The tickets are written for accountability and reporting every change to management, so not written for developers. The approach smells like an anti-pattern to me. I don't expect to stay long; it's just a contract. I wouldn't choose a place like that for a long-term position, but I'm looking forward to the experience to find out what it's like with an open mind. I was hired as an interim team lead, but politics already changed what the role is since signing, and it's also been made clear that TLs there don't get to decide how anything is actually done. We'll see. I tend to bring new energy to a system.