3 ms·

It does, in the last lectures, see Nov in the schedule: https://raw.githubusercontent.com/CMU-313/CMU-313.github.io/master/lectures/22-Teams.pdf https://raw.gi

It does, in the last lectures, see Nov in the schedule: https://raw.githubusercontent.com/CMU-313/CMU-313.github.io/master/lectures/22-Teams.pdf https://raw.githubusercontent.com/CMU-313/CMU-313.github.io/...

Spearchucker 6y ago
What's there is valuable for sure. It pushes agile though. A lot. Another approach may be to provide a way for a team to choose a methodology that's appropriate for what's being built (1). It describes effective teams, but doesn't provide guidance on identifying dysfunctional teams/team members, and transforming those to productive teams/team members. (1) https://www.wittenburg.co.uk/Work/Choosing.aspx https://www.wittenburg.co.uk/Work/Choosing.aspx
- froh 6y ago
  Fun thing is: agile are principles. Scrum is a method, or safe or less, or kanban. And: The complete V belongs to the "definition of done" for safety projects, like the example above, control software for a nuclear reactor. Whiche gets me to an intuition that you can have dysfunctional teams in any software engineering approach. The challenge of dysfunctional teams is not addressed by a discussion about agile, lean, "waterfall".
  - Spearchucker 6y ago
    You are absolutely correct. Defining agile as principles, or scrum as a method is correct, but doesn't change how the terms are used. Turning dysfunctional teams around is something I'm reasearching (as identifying them is easy).
    - chrisweekly 6y ago
      I've been thinking recently about tradeoffs between (agility / resilience / adaptability) and (efficiency). It seems to me that so many orgs' attempts to adopt "Agile" practices are motivated by a desire for increased efficiency per se. Which seems paradoxical. I'm not trying to get into a "one true Scotsman" debate about what Agile really means, but what I keep seeing is an overemphasis on process that runs counter to the heart of the manifesto. IMHO that's the crux of a lot of dysfunction. V. interested in others' thoughts here.
      - qznc 6y ago
        In my opinion [0] Agile improves time to market (latency) at the cost of process efficiency (throughput). If you adopt Scrum to improve efficiency (maybe calling it velocity), then you are using the wrong approach. It will certainly not improve efficiency. Worse, by pushing Scrum to improve efficiency, Scrum loses all its advantages. This leads to the common result nothing changes. [0] http://beza1e1.tuxen.de/cost_of_agile.html http://beza1e1.tuxen.de/cost_of_agile.html
        Spearchucker 6y ago
        Why value efficiency and not quality? Remeber Deming (1)? Result of work effort quality = ----------------------- Total cost When focus is on quality, quality rises and costs fall. When focus is cost, costs rise and quality falls. (1) https://en.wikipedia.org/wiki/W._Edwards_Deming https://en.wikipedia.org/wiki/W._Edwards_Deming
    - qznc 6y ago
      Psychological safety seems to be a big part of the puzzle. For example: > If there's one thing I feel that is absent from the Agile Manifesto, it's psychological safety. We have learned in the past 20 years how important this to a teams success. https://old.reddit.com/r/agile/comments/jd29lf/the_elephant_in_the_room/ https://old.reddit.com/r/agile/comments/jd29lf/the_elephant_... Just today, I started reading The Culture Code by Daniel Coyle. The first two chapters are great and it addresses exactly this question.

Spearchucker 6y ago

What's there is valuable for sure. It pushes agile though. A lot. Another approach may be to provide a way for a team to choose a methodology that's appropriate for what's being built (1). It describes effective teams, but doesn't provide guidance on identifying dysfunctional teams/team members, and transforming those to productive teams/team members. (1) https://www.wittenburg.co.uk/Work/Choosing.aspx https://www.wittenburg.co.uk/Work/Choosing.aspx

froh 6y ago
Fun thing is: agile are principles. Scrum is a method, or safe or less, or kanban. And: The complete V belongs to the "definition of done" for safety projects, like the example above, control software for a nuclear reactor. Whiche gets me to an intuition that you can have dysfunctional teams in any software engineering approach. The challenge of dysfunctional teams is not addressed by a discussion about agile, lean, "waterfall".
- Spearchucker 6y ago
  You are absolutely correct. Defining agile as principles, or scrum as a method is correct, but doesn't change how the terms are used. Turning dysfunctional teams around is something I'm reasearching (as identifying them is easy).
  - chrisweekly 6y ago
    I've been thinking recently about tradeoffs between (agility / resilience / adaptability) and (efficiency). It seems to me that so many orgs' attempts to adopt "Agile" practices are motivated by a desire for increased efficiency per se. Which seems paradoxical. I'm not trying to get into a "one true Scotsman" debate about what Agile really means, but what I keep seeing is an overemphasis on process that runs counter to the heart of the manifesto. IMHO that's the crux of a lot of dysfunction. V. interested in others' thoughts here.
    - qznc 6y ago
      In my opinion [0] Agile improves time to market (latency) at the cost of process efficiency (throughput). If you adopt Scrum to improve efficiency (maybe calling it velocity), then you are using the wrong approach. It will certainly not improve efficiency. Worse, by pushing Scrum to improve efficiency, Scrum loses all its advantages. This leads to the common result nothing changes. [0] http://beza1e1.tuxen.de/cost_of_agile.html http://beza1e1.tuxen.de/cost_of_agile.html
      - Spearchucker 6y ago
        Why value efficiency and not quality? Remeber Deming (1)? Result of work effort quality = ----------------------- Total cost When focus is on quality, quality rises and costs fall. When focus is cost, costs rise and quality falls. (1) https://en.wikipedia.org/wiki/W._Edwards_Deming https://en.wikipedia.org/wiki/W._Edwards_Deming
  - qznc 6y ago
    Psychological safety seems to be a big part of the puzzle. For example: > If there's one thing I feel that is absent from the Agile Manifesto, it's psychological safety. We have learned in the past 20 years how important this to a teams success. https://old.reddit.com/r/agile/comments/jd29lf/the_elephant_in_the_room/ https://old.reddit.com/r/agile/comments/jd29lf/the_elephant_... Just today, I started reading The Culture Code by Daniel Coyle. The first two chapters are great and it addresses exactly this question.