3 ms·

Agile (Scrum rather, but this article appears to be about implementing agile through scrum) trades one set of problems of software development, for another set

Agile (Scrum rather, but this article appears to be about implementing agile through scrum) trades one set of problems of software development, for another set of problems. That needs to be understood I think. Some times when agile is treated like dogma and religion this somehow gets lost. It's a tradeoff. It's popular because this new set of problems is deemed to be a better set of problems to have than almost all other sets of problems you'll end up with. Switch to waterfall, and you'll have problems with that. Try whatever process, and there will be a set of problems that comes from it. Scrum is a flawed process, but there are many flawed processes. A lot of scrum-haters (understandably) argue against scrum, but what I'm missing is the presentation of the alternatives. We are going to be miserable and stuck doing scrum for the coming century unless we can formulate and demonstrate good alternatives. And if we don't want the processes to be upper-management centric, we better formulate the alternative as developers. The places where I have seen scrum function well (teams delivering features without burnout, without losing grip of the big picture because of constant micro-development etc.) are in teams that are high performing and highly functioning. But of course those teams would have been well functioning and productive with any process. The allure of scrum (in my opinion) is that it makes teams that would likely have delivered nothing, deliver something, or at least not waste time building the wrong thing. It's a way for management to increase the transparency and lower the risk of software development with poor software developers and/or bad teams. And that, to be honest, isn't something to be scoffed at. Throwing a poor process onto a bad team means you'll get miserable developers and risk having nothing produced. Agile means miserable developers and hopefully some transparency too. Not great, not terrible.

Juliate 5y ago
> It's a way for management to increase the transparency and lower the risk of software development with poor software developers and/or bad teams. So, it's kind of an "observability tool for teams' production process management"? (to reframe it in a more contemporary fashion) Edit: I guess we're headed to having pulse, blood pressure, VOmax, weight, daily exercise and so... metrics also displayed along mood and burndown charts. :p
- alkonaut 5y ago
  > So, it's kind of an "observability tool for teams' production process management"? Absolutely, I think thats literally on the label and not in the fine print of the Scrum tin.
azangru 5y ago
> Agile means miserable developers and hopefully some transparency too. Why are developers who work in an agile environment miserable? If you take scrum, doesn't it include retrospectives, with the express purpose of allowing developers to reflect on their misery and to gradually improve their condition?
- BlargMcLarg 5y ago
  Retrospectives open the ability to provide feedback. That doesn't mean anything will happen with that feedback. That's before considering social theory and tact, where it becomes obvious being rebellious is generally a bad move socially unless you're already willing to leave, are in a position of power over others or the crowd is willing to take your side. Meanwhile these "agile" environments tend to push maximum social participation from developers at the benefit of management. "No true Scrum/agile" aside, this is the reality of many. The fundamental problem still lays in the power difference between ICs and upper management. Even if it is "inefficient", so are many things done by modern corporates. Showing something can be done more efficiently isn't a guarantee the company will become leaner.
- Juliate 5y ago
  You may only improve what you can influence, within your agility bubble: does it stop at your team, or does it embrace the whole company structure.
- alkonaut 5y ago
  > Why are developers who work in an agile environment miserable? Yes. And yet that often doesn't happen. And that's where one might argue "well then you aren't doing it right", but that's precisely the No True Scotsman argument. I see teams be miserable, have all the power to do something about it, including buy-in from management, yet they remain miserable. A key feature of any alternative methodology and organization should contain this: It's the role of management to ensure teams aren't miserable. Merely giving teams the tools to do so doesn't make it happen.
  - jdlshore 5y ago

Juliate 5y ago

> It's a way for management to increase the transparency and lower the risk of software development with poor software developers and/or bad teams. So, it's kind of an "observability tool for teams' production process management"? (to reframe it in a more contemporary fashion) Edit: I guess we're headed to having pulse, blood pressure, VOmax, weight, daily exercise and so... metrics also displayed along mood and burndown charts. :p

alkonaut 5y ago
> So, it's kind of an "observability tool for teams' production process management"? Absolutely, I think thats literally on the label and not in the fine print of the Scrum tin.

azangru 5y ago

> Agile means miserable developers and hopefully some transparency too. Why are developers who work in an agile environment miserable? If you take scrum, doesn't it include retrospectives, with the express purpose of allowing developers to reflect on their misery and to gradually improve their condition?

BlargMcLarg 5y ago
Retrospectives open the ability to provide feedback. That doesn't mean anything will happen with that feedback. That's before considering social theory and tact, where it becomes obvious being rebellious is generally a bad move socially unless you're already willing to leave, are in a position of power over others or the crowd is willing to take your side. Meanwhile these "agile" environments tend to push maximum social participation from developers at the benefit of management. "No true Scrum/agile" aside, this is the reality of many. The fundamental problem still lays in the power difference between ICs and upper management. Even if it is "inefficient", so are many things done by modern corporates. Showing something can be done more efficiently isn't a guarantee the company will become leaner.
Juliate 5y ago
You may only improve what you can influence, within your agility bubble: does it stop at your team, or does it embrace the whole company structure.
alkonaut 5y ago
> Why are developers who work in an agile environment miserable? Yes. And yet that often doesn't happen. And that's where one might argue "well then you aren't doing it right", but that's precisely the No True Scotsman argument. I see teams be miserable, have all the power to do something about it, including buy-in from management, yet they remain miserable. A key feature of any alternative methodology and organization should contain this: It's the role of management to ensure teams aren't miserable. Merely giving teams the tools to do so doesn't make it happen.
- jdlshore 5y ago