4 ms·

> in my org tickets overflow from one sprint to the next all the time, tickets get added mid-sprint That's not Scrum then. You don't add stuff mid-sprint, tha

> in my org tickets overflow from one sprint to the next all the time, tickets get added mid-sprint That's not Scrum then. You don't add stuff mid-sprint, that's the whole point. Unless the world is literally on fire, you don't touch the sprint content. What's your scrum master doing when you get stuff added? It's their job to prevent it. And if work overflows, you need to spend time grooming the tasks to manageable chunks and adjust the team velocity. You can always pick up more tasks if you run out of stuff to do.

ResearchCode 4y ago
Why do you need a "scrum master" to prevent that? Linux kernel seems to be doing just fine without them. The real solution is of course not to have any "sprints" at all. A manageable chunk of work is a 3 to 6 month project. Non-tech enterprise treat software engineers as children and create bad software. FAANG and adjacent companies treat software engineers more as professionals and create better software.
- theshrike79 4y ago
  Linux kernel is more like Kanban than an Agile project, you can't really compare it to a project with an actual client who pays money to receive features in a timeframe. Stuff gets done when it's done and the BFDLs decide when the feature gets into the actual kernel. Waterfall-style projects had 3 to 6 month timeframes of delivery and we all know how that goes. The result is always either out of date due to changing requirements or not what the customer wanted because there is no way to change course after the project specification was locked. ...or you spend so much time doing an exact specification that the Agile team has already delivered 3 incremental versions.
  - ResearchCode 4y ago
    I don't see what use a "scrum master" is. That sounds like a small task for the software engineer or their real manager. There is nothing showing that heavy agile actually leads to features being developed earlier. In my experience it's the opposite as you build up heavy tech debt by micro-managing and optimizing for a 2 week return instead of the long term. Waterfall were 1 to 2 year projects with heavy up-front administration. 3 to 6 months is well-balanced and that's what the "elite" companies and research groups tend to use. Two weeks is the current fad at non-tech enterprise.
    - theshrike79 4y ago
      The task of the Scrum Master is to make themselves redundant. They just make sure the team follows the structure they agreed on + runs interference for external issues. After the team is mature enough, one of them can take the SM duties in addition to other tasks because the actual process runs without extra management.
      - ResearchCode 4y ago
        Sounds like they were redundant from the very beginning. Those sound like small tasks for the engineers or the actual manager.
    - midoridensha 4y ago
      In my experience on a scrum team, the scrummaster was basically a coach. They helped deal with external issues as the other responder said, so the manager (team leader) didn't waste his time with that and could use his time dealing with team members and doing engineering work too. In my case, the scrummaster had this role for a bunch of parallel teams, not just one, so it was a full-time job for him. The org structure seemed to work very well for the type of work we were doing.
      - theshrike79 4y ago
        Yea, pretty often scrum masters are hired coaches that are let go when the team knows how to self-manage - or like you said - they coach multiple teams at the same time.
        deleted 4y ago
        [deleted]
        ResearchCode 4y ago
        What qualifications does a "scrum master" have that a software engineer does not have when it comes to creating a self-managing team? The "scrum" pamphlet can be read on a lunch break and I don't think the certs even have exams.
IshKebab 4y ago
See that's the main problem with strict scrum. Why can't you add things to the sprint mid sprint? Sometimes things come up that you didn't think of. There's really no point being that strict. I think two week meetings/sprints are good for keeping focus and as an opportunity to agree short term priorities. But the point is to get work done, not to precisely obey scrum rules.
- theshrike79 4y ago
  Depends on what the "you" is here. If the "you" is the team, go ahead. Add anything you want, as long as you deliver what you promised in the beginning of the sprint. If the "you" is an external person asking for a "quick job", then the default answer is "talk to the scrum master" whose default answer will be "No.". Then they can start discussing if it is so urgent and important that it can't wait 1-10 business days for the next sprint and/or small enough not to disrupt other work. The rules are there to protect the team. If the team is willing to take ad-hoc work, nothing in the agile rules says they can't do so. The point is that nobody outside of the team can force them to take on extra work mid-sprint and disrupt their planned work.
  - IshKebab 4y ago
    > If the "you" is an external person asking for a "quick job", then the default answer is "talk to the scrum master" whose default answer will be "No. I hate working with people like this. So unhelpful.
    - theshrike79 4y ago
      I hate being interrupted by people too, that's why I like the Scrum style of working when there is an external client (or an unruly internal one).
treis 4y ago
That's not a rule in Scrum that I'm aware of. It's an aspiration for sure since an injection implies some sort of emergency or unanticipated work. Ideally you avoid those sort of things. But if they happen it's not an issue to inject something. Constantly doing so usually means something has broken down in planning and/or quality is so bad the team is going from fire to fire.
TobyTheDog123 4y ago
So if we finish all of our tickets early (which is often the case because measuring complexity is impossible to do up front), we're just supposed to sit around until the sprint ends? A scrum master? Man, I thought my team was bloated with process but the fact that role exists elsewhere means I should probably be more grateful.

ResearchCode 4y ago

Why do you need a "scrum master" to prevent that? Linux kernel seems to be doing just fine without them. The real solution is of course not to have any "sprints" at all. A manageable chunk of work is a 3 to 6 month project. Non-tech enterprise treat software engineers as children and create bad software. FAANG and adjacent companies treat software engineers more as professionals and create better software.

theshrike79 4y ago
Linux kernel is more like Kanban than an Agile project, you can't really compare it to a project with an actual client who pays money to receive features in a timeframe. Stuff gets done when it's done and the BFDLs decide when the feature gets into the actual kernel. Waterfall-style projects had 3 to 6 month timeframes of delivery and we all know how that goes. The result is always either out of date due to changing requirements or not what the customer wanted because there is no way to change course after the project specification was locked. ...or you spend so much time doing an exact specification that the Agile team has already delivered 3 incremental versions.
- ResearchCode 4y ago
  I don't see what use a "scrum master" is. That sounds like a small task for the software engineer or their real manager. There is nothing showing that heavy agile actually leads to features being developed earlier. In my experience it's the opposite as you build up heavy tech debt by micro-managing and optimizing for a 2 week return instead of the long term. Waterfall were 1 to 2 year projects with heavy up-front administration. 3 to 6 months is well-balanced and that's what the "elite" companies and research groups tend to use. Two weeks is the current fad at non-tech enterprise.
  - theshrike79 4y ago
    The task of the Scrum Master is to make themselves redundant. They just make sure the team follows the structure they agreed on + runs interference for external issues. After the team is mature enough, one of them can take the SM duties in addition to other tasks because the actual process runs without extra management.
    - ResearchCode 4y ago
      Sounds like they were redundant from the very beginning. Those sound like small tasks for the engineers or the actual manager.
  - midoridensha 4y ago
    In my experience on a scrum team, the scrummaster was basically a coach. They helped deal with external issues as the other responder said, so the manager (team leader) didn't waste his time with that and could use his time dealing with team members and doing engineering work too. In my case, the scrummaster had this role for a bunch of parallel teams, not just one, so it was a full-time job for him. The org structure seemed to work very well for the type of work we were doing.
    - theshrike79 4y ago
      Yea, pretty often scrum masters are hired coaches that are let go when the team knows how to self-manage - or like you said - they coach multiple teams at the same time.
      - deleted 4y ago
        [deleted]
      - ResearchCode 4y ago
        What qualifications does a "scrum master" have that a software engineer does not have when it comes to creating a self-managing team? The "scrum" pamphlet can be read on a lunch break and I don't think the certs even have exams.

IshKebab 4y ago

See that's the main problem with strict scrum. Why can't you add things to the sprint mid sprint? Sometimes things come up that you didn't think of. There's really no point being that strict. I think two week meetings/sprints are good for keeping focus and as an opportunity to agree short term priorities. But the point is to get work done, not to precisely obey scrum rules.

theshrike79 4y ago
Depends on what the "you" is here. If the "you" is the team, go ahead. Add anything you want, as long as you deliver what you promised in the beginning of the sprint. If the "you" is an external person asking for a "quick job", then the default answer is "talk to the scrum master" whose default answer will be "No.". Then they can start discussing if it is so urgent and important that it can't wait 1-10 business days for the next sprint and/or small enough not to disrupt other work. The rules are there to protect the team. If the team is willing to take ad-hoc work, nothing in the agile rules says they can't do so. The point is that nobody outside of the team can force them to take on extra work mid-sprint and disrupt their planned work.
- IshKebab 4y ago
  > If the "you" is an external person asking for a "quick job", then the default answer is "talk to the scrum master" whose default answer will be "No. I hate working with people like this. So unhelpful.
  - theshrike79 4y ago
    I hate being interrupted by people too, that's why I like the Scrum style of working when there is an external client (or an unruly internal one).

treis 4y ago

That's not a rule in Scrum that I'm aware of. It's an aspiration for sure since an injection implies some sort of emergency or unanticipated work. Ideally you avoid those sort of things. But if they happen it's not an issue to inject something. Constantly doing so usually means something has broken down in planning and/or quality is so bad the team is going from fire to fire.

TobyTheDog123 4y ago

So if we finish all of our tickets early (which is often the case because measuring complexity is impossible to do up front), we're just supposed to sit around until the sprint ends? A scrum master? Man, I thought my team was bloated with process but the fact that role exists elsewhere means I should probably be more grateful.