4 ms·

I don't like scrum myself, but let me try to defend it because I think the problem of most of the people who don't have a good experience with scrum is a misund

I don't like scrum myself, but let me try to defend it because I think the problem of most of the people who don't have a good experience with scrum is a misunderstanding of the underlying principles behind it. Let's just remember that Scrum is just a tool that is trying to replicate some practices of the toyota production system (TPS), and an important principle of the TPS is continuous improvement, and Scrum has this through restrospectives. Another principle is quality built in. Now, how to avoid having a rat's nest after 2 years? First of all, you have to remove velocity as a goal for your team. It's easy to game, and it de-incentivizes finding a _predictable_ velocity, which is the goal of that tool. The goal of velocity, is to know what's the "cost" of building an healthy system. i.e.: Your team ships an arbitrarily 10 points per sprint by doing what they think is right. The same team could ship an arbitrarily 20 points per week. 10 is the _true_ cost of building a healthy system. There is not a lot more to do for good team, honestly, at that point. Management can't say anything, because you bring them predictability, and that's mainly what they want. They might think you're slow, but hey, all of this is relative. Suddenly, what does that mean when your team only ships 5 arbitrary points? That they had to push extra. That there was an unexpected problem. That things were on fire and you had to stop working on features entirely. Basically, that there is something to retro on, find the root cause and anticipate for next sprints, and use to go back to the healthy level of points. I used this at several places. It demands trust, but it always pays off. With some teams I worked with, we set up a technical prioritization planning meeting every week, where basically decided what was going to be prioritized for that week. Each team was picking 2/3 things to do on top of the features. You don't tell anyone. You do it.

ktRolster 10y ago
Your team ships an arbitrarily 10 points per sprint by doing what they think is right. The same team could ship an arbitrarily 20 points per week. 10 is the _true_ cost of building a healthy system. There is not a lot more to do for good team, honestly, at that point. Management can't say anything This sort of thing is only useful for managers who don't understand what is going on. Since they are unable to look at code and understand it, 'points' give them a semi-opaque substitute. If management trusts the team, it is not necessary.
- patothon 10y ago
  I guess if you understand what is going on as a manager, then you might prefer the 10 points team? I know I do.
  - ktRolster 10y ago
    If you understand what is going on, you will get rid of points altogether, and look at the git log from time to time. If you are a leader, and not just a manager, you will help your programmers improve their skill, so over time you spend less and less time managing them. Your programmers will appreciate it because with greater self-management comes greater happiness and job satisfaction.
    - patothon 10y ago
      Totally. Some teams want the points though So I let them have it. But I just set the principles I explained above for the points to have an actual meaning.
    - DougWebb 10y ago
      The points are (also) an estimating mechanism. They let you estimate a new task in points (effort measurement) instead of hours (time measurement), and then use history to predict a likely timeframe based on your typical rate. The extra layer of indirection helps to account for uncertainties in the task, imprecision in the estimate, and chaos (in the scientific sense) in how long individual tasks take relative to aggregated historical metrics.
      - ktRolster 10y ago
        That's surely worth something, but it's easier to think of estimates as a 90% outer bound: "I am 90% sure that the task will be completed by date X." Uncertainty can be incorporated, and you don't need to learn a new conversion factor from time to points.
        10y ago
ubernostrum 10y ago
I think the problem of most of the people who don't have a good experience with scrum is a misunderstanding of the underlying principles behind it. Unfortunately this has become a cliché whenever someone criticizes scrum, Agile in general, etc.: it's never the fault of the idea/process, it's the fault of the manager/team for not understanding it properly or not doing it right. Even if these philosophies and processes are so amazingly great when properly understood and implemented, the fact that hardly anyone seems to be able to properly understand and implement them would be a fatal flaw.
- patothon 10y ago
  Agreed, that's why I specified I don't really like Scrum. Mainly because it's hard to actually implement without all the flaws if you don't try to understand the underlying principles. Unfortunately, Scrum books and coaches rarely go through these.
  - dragonwriter 10y ago
    > Mainly because it's hard to actually implement without all the flaws if you don't try to understand the underlying principles. Unfortunately, Scrum books and coaches rarely go through these. If you are implementing Scrum, I don't see how you do it without the Scrum Guide (which defines Scrum), which is both quite short and does, in fact, go through the underlying principles.
- abritinthebay 10y ago
  > it's never the fault of the idea/process, it's the fault of the manager/team for not understanding it properly or not doing it right. Well, almost every time I see Scrum criticized the described process is not Scrum and merely cribs ideas from it without understand the purpose or how things inter-relate. So it's a fair criticism.
bighi 10y ago
> Suddenly, what does that mean when your team only ships 5 arbitrary points? In my experience, it means some developers failed to game the system that particular time. But you can be sure there were many other problematic moments in previous sprints, but the developer could hack together an ugly mess of a code to avoid the shame of failing in front of everyone in a meeting, and dragging the team's points down. Because the unwritten thing about points is that they are used to shame people. In public. Sometimes not explicitly, but the feeling is there. It's always there.
- vibrato 10y ago
  Scrum really is shame driven development in my experience
- patothon 10y ago
  Yes. That's why, if you have to work with and/or manage a scrum team, making velocity not the focus of the sprint is step 1 for a sane process. We count points, but it's not a contract. We try to reach the points, but it's not a contract. In my parent comment: _First of all, you have to remove velocity as a goal for your team. It's easy to game, and it de-incentivizes finding a _predictable_ velocity, which is the goal of that tool._

ktRolster 10y ago

Your team ships an arbitrarily 10 points per sprint by doing what they think is right. The same team could ship an arbitrarily 20 points per week. 10 is the _true_ cost of building a healthy system. There is not a lot more to do for good team, honestly, at that point. Management can't say anything This sort of thing is only useful for managers who don't understand what is going on. Since they are unable to look at code and understand it, 'points' give them a semi-opaque substitute. If management trusts the team, it is not necessary.

patothon 10y ago
I guess if you understand what is going on as a manager, then you might prefer the 10 points team? I know I do.
- ktRolster 10y ago
  If you understand what is going on, you will get rid of points altogether, and look at the git log from time to time. If you are a leader, and not just a manager, you will help your programmers improve their skill, so over time you spend less and less time managing them. Your programmers will appreciate it because with greater self-management comes greater happiness and job satisfaction.
  - patothon 10y ago
    Totally. Some teams want the points though So I let them have it. But I just set the principles I explained above for the points to have an actual meaning.
  - DougWebb 10y ago
    The points are (also) an estimating mechanism. They let you estimate a new task in points (effort measurement) instead of hours (time measurement), and then use history to predict a likely timeframe based on your typical rate. The extra layer of indirection helps to account for uncertainties in the task, imprecision in the estimate, and chaos (in the scientific sense) in how long individual tasks take relative to aggregated historical metrics.
    - ktRolster 10y ago
      That's surely worth something, but it's easier to think of estimates as a 90% outer bound: "I am 90% sure that the task will be completed by date X." Uncertainty can be incorporated, and you don't need to learn a new conversion factor from time to points.
      - 10y ago

ubernostrum 10y ago

I think the problem of most of the people who don't have a good experience with scrum is a misunderstanding of the underlying principles behind it. Unfortunately this has become a cliché whenever someone criticizes scrum, Agile in general, etc.: it's never the fault of the idea/process, it's the fault of the manager/team for not understanding it properly or not doing it right. Even if these philosophies and processes are so amazingly great when properly understood and implemented, the fact that hardly anyone seems to be able to properly understand and implement them would be a fatal flaw.

patothon 10y ago
Agreed, that's why I specified I don't really like Scrum. Mainly because it's hard to actually implement without all the flaws if you don't try to understand the underlying principles. Unfortunately, Scrum books and coaches rarely go through these.
- dragonwriter 10y ago
  > Mainly because it's hard to actually implement without all the flaws if you don't try to understand the underlying principles. Unfortunately, Scrum books and coaches rarely go through these. If you are implementing Scrum, I don't see how you do it without the Scrum Guide (which defines Scrum), which is both quite short and does, in fact, go through the underlying principles.
abritinthebay 10y ago
> it's never the fault of the idea/process, it's the fault of the manager/team for not understanding it properly or not doing it right. Well, almost every time I see Scrum criticized the described process is not Scrum and merely cribs ideas from it without understand the purpose or how things inter-relate. So it's a fair criticism.

bighi 10y ago

> Suddenly, what does that mean when your team only ships 5 arbitrary points? In my experience, it means some developers failed to game the system that particular time. But you can be sure there were many other problematic moments in previous sprints, but the developer could hack together an ugly mess of a code to avoid the shame of failing in front of everyone in a meeting, and dragging the team's points down. Because the unwritten thing about points is that they are used to shame people. In public. Sometimes not explicitly, but the feeling is there. It's always there.

vibrato 10y ago
Scrum really is shame driven development in my experience
patothon 10y ago
Yes. That's why, if you have to work with and/or manage a scrum team, making velocity not the focus of the sprint is step 1 for a sane process. We count points, but it's not a contract. We try to reach the points, but it's not a contract. In my parent comment: _First of all, you have to remove velocity as a goal for your team. It's easy to game, and it de-incentivizes finding a _predictable_ velocity, which is the goal of that tool._