3 ms·

This doesn’t really sound like SCRUM. One of the key notions is that teams work at a sustainable pace; if there’s not enough time to deal with tech debt and peo

by hyko 6y ago

This doesn’t really sound like SCRUM. One of the key notions is that teams work at a sustainable pace; if there’s not enough time to deal with tech debt and people are burning out then this pace is by definition unsustainable. The working conditions you describe also sound like they have no slack whatsoever (not a SCRUM requirement but not a bad idea either). There shouldn’t be deadlines every two weeks, instead you should be working towards a sprint goal. If the goal is not achieved then you can use that knowledge in the next sprint to reduce the amount of scope you try to complete. There are no deadlines per se, because deadlines try to fix scope and time, whereas a sprint only fixes time. The process of estimation and story pointing is where things become more art than science, but provided you are consistent in your approaches this mechanism prevents our inherent lack of foresight from becoming a catastrophic prediction failure. Meetings like stand ups, retros, and backlog refinement can be super effective tools but they have to be run properly and tightly, otherwise they become worse than nothing. I guess in this hypothetical team the thing to do would be to raise with the Scrum Master that you’re exhausted, raise in the retro that there are deficiencies in the process etc. and get back to a more sane baseline.

BlargMcLarg 6y ago
This has already been repeated ad nauseam. If many people cannot implement the methodology without it becoming warped, we should put that methodology under scrunity. Additionally, many others have already argued against both the common implementation of Scrum, and its "ideal, perfect, theoretical" version. Just the idea of preserving asynchronous communication while introducing fixed, synchronous communication strikes me as an idea by someone who does not understand how people work.
- hyko 6y ago
  If Scrum is too hard for people to adopt, then that's a valid criticism when it comes to its impact on the wider industry. However, what we can't do is fail to adopt it properly and then generalise our criticism of that new process to encompass Scrum as a whole. Its ideal version is not some platonic form that cannot be realised in practice; I have experienced it first hand and it can work reasonably well. I have also experienced all sorts of 'flavors' that were less successful. They usually amount to people either not bothering to RTFM, low levels of investment in process, or senior management undermining the team efforts (through either not RTFMing or not believing in Agile as a concept). Whether that is down to the lack of adherence to the Scrum process itself, or just the lack of competence that would be required to stick to any process is an open question. Scrum as a set of process rules should not be particularly difficult for an engineering team to learn. I submit that if a team cannot operate under such a set of rules, it will be unable to adopt any set of process rules, and in addition to that, it will perform especially poorly under a system of no rules (i.e. direct rule by edicts from kings and queens).
  - mangochutney 6y ago
    I submit that if a team cannot operate under such a set of rules, it will be unable to adopt any set of process rules Good lord it is exactly this kind religiosity that has me running for the exit.
    - hyko 6y ago
      I think calling that statement religiosity is probably a bit too strong, but I’ll grant you that it’s not quite right; it is of course possible to construct a simpler process. I would modify that slightly to state that they would be unable to adopt any set of process rules of equivalent sophistication. That may be for all sorts of reasons. I guess my question to you is, where are you exiting to? If you know of a process or methodology that is better and can articulate the reasons why, then I will gladly follow you!
      - mangochutney 6y ago
        I guess my question to you is, where are you exiting to? This is in my OP that began the comment thread.
        hyko 6y ago
        Ah right, sorry I didn’t make that connection...I thought you were proposing a better way for teams to organise. I guess I won’t be following you through that exit, but all the best and good luck for the future. I admire your courage in the pursuit of happiness.
Viliam1234 6y ago
In my experience, most companies have kind-of-SCRUM and deadlines. Like, sure, you can make a team decision about what goes into this sprint, and what goes into the next one. But the management makes the decision what must be done in three or six months, and there is no negotiation about that.

by hyko 6y ago

BlargMcLarg 6y ago

This has already been repeated ad nauseam. If many people cannot implement the methodology without it becoming warped, we should put that methodology under scrunity. Additionally, many others have already argued against both the common implementation of Scrum, and its "ideal, perfect, theoretical" version. Just the idea of preserving asynchronous communication while introducing fixed, synchronous communication strikes me as an idea by someone who does not understand how people work.

hyko 6y ago
If Scrum is too hard for people to adopt, then that's a valid criticism when it comes to its impact on the wider industry. However, what we can't do is fail to adopt it properly and then generalise our criticism of that new process to encompass Scrum as a whole. Its ideal version is not some platonic form that cannot be realised in practice; I have experienced it first hand and it can work reasonably well. I have also experienced all sorts of 'flavors' that were less successful. They usually amount to people either not bothering to RTFM, low levels of investment in process, or senior management undermining the team efforts (through either not RTFMing or not believing in Agile as a concept). Whether that is down to the lack of adherence to the Scrum process itself, or just the lack of competence that would be required to stick to any process is an open question. Scrum as a set of process rules should not be particularly difficult for an engineering team to learn. I submit that if a team cannot operate under such a set of rules, it will be unable to adopt any set of process rules, and in addition to that, it will perform especially poorly under a system of no rules (i.e. direct rule by edicts from kings and queens).
- mangochutney 6y ago
  I submit that if a team cannot operate under such a set of rules, it will be unable to adopt any set of process rules Good lord it is exactly this kind religiosity that has me running for the exit.
  - hyko 6y ago
    I think calling that statement religiosity is probably a bit too strong, but I’ll grant you that it’s not quite right; it is of course possible to construct a simpler process. I would modify that slightly to state that they would be unable to adopt any set of process rules of equivalent sophistication. That may be for all sorts of reasons. I guess my question to you is, where are you exiting to? If you know of a process or methodology that is better and can articulate the reasons why, then I will gladly follow you!
    - mangochutney 6y ago
      I guess my question to you is, where are you exiting to? This is in my OP that began the comment thread.
      - hyko 6y ago
        Ah right, sorry I didn’t make that connection...I thought you were proposing a better way for teams to organise. I guess I won’t be following you through that exit, but all the best and good luck for the future. I admire your courage in the pursuit of happiness.

Viliam1234 6y ago

In my experience, most companies have kind-of-SCRUM and deadlines. Like, sure, you can make a team decision about what goes into this sprint, and what goes into the next one. But the management makes the decision what must be done in three or six months, and there is no negotiation about that.