4 ms·
The elephant in the room that 17-313 doesn't addresses is team dysfunction. You know, the guy who insists on agile when you're about to automate a nuclear reac
by Spearchucker 6y ago
The elephant in the room that 17-313 doesn't addresses is team dysfunction.
You know, the guy who insists on agile when you're about to automate a nuclear reactor cooling system. Or the one who insists on expensive message queue tech when async/await is more than sufficient. The bro that mansplains directed graphs at a PhD because she comitted the cardinal sin of being a woman. The infrastructure manager that micro-manages a developer because that manager was too lazy to stand up the test environment on time.
We all know someone like that, and after 30+ years in this industry it seems it's worse now than it was in the 90's. Back then all we had to contend with was Windows v. Unix and bastard operators from hell(1). Today it's more insiduous. Often well-dressed, veiled in charm and confidence and hiding behind a big pay check because they're adept at managing upwards. I can deal with it, which has another unfortunate side-effect - other developers want me to manage, I just want to write code.
Amusingly (sadly?) these problems(2) were identified in the 80's if not earlier. Books were written about dealing with it (2 and 3, amongst others). But still we allow the behaviour and often organisational/industry culture encourages it (fintech, anyone?).
(1) http://bofh.bjash.com/ http://bofh.bjash.com/
(2) https://en.wikipedia.org/wiki/Wicked_problem https://en.wikipedia.org/wiki/Wicked_problem and https://www.amazon.com/dp/013590126X https://www.amazon.com/dp/013590126X
(3) https://en.wikipedia.org/wiki/Peopleware%3A_Productive_Projects_and_Teams https://en.wikipedia.org/wiki/Peopleware%3A_Productive_Proje...
- charlysl 6y agoIt 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 agoWhat'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 agoFun 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 agoYou 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 agoI'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 agoIn 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
- 6y ago
- sigwinch28 6y agoIt's literally part of the schedule: https://cmu-313.github.io/#schedule https://cmu-313.github.io/#schedule
- Spearchucker 6y agoNo, it isn't. See my comment addressing this above.
- sigwinch28 6y agoI saw your comment, and it says that the course does not address team dysfunction. It explicitly does. Whether it conforms to what you want to consider to be team dysfunction is another point of discussion entirely.
- Spearchucker 6y agoI do not consider dysfunction something other than the course describes. What I take issue with is that the course offers an outcome but no approach. Read it again.