4 ms·

Although I haven't been in the industry for what others may call a long time, I feel that after working at a few large enterprises, this is something that upper

Although I haven't been in the industry for what others may call a long time, I feel that after working at a few large enterprises, this is something that upper management should read and understand in order to better relate to those actually performing the development of projects. Agile is the newest and most widespread buzzword in my current role and its practices are being shoved down every team's throat. Those who adopt look like better performing teams to management and become the favorite and most flaunted teams so much to be idolized by others. Meanwhile some of the smartest and proven teams are clearly producing immense value, and ignore a lot of new methodology mumbo jumbo to continue operating the way they have been for years. It's an interesting dynamic, and I believe this paper captured a lot of what I've been experiencing, but was unable to convey into words.

blatherard 9y ago
Are you saying that the high-performing teams are continuing to work as they were, and the other, presumably lower-performing, teams being made to act differently? That doesn't sound too bad, at least on its face.
- LoSboccacc 9y ago
  Flashy != Productive working on stories instead of layers you push out finished ux and features early on, and that's what both manager loves but ultimately kills the speed after six month to a year, because those need to be maintained forever but it's very rare to actually squeeze teme to refactor and even if you do, speed slows down as you refactor The team spending less on the ui and more on making sure they get the datamodel right and the abstraction thight can quickly built an ui over the stable platform and overall will have better speed past a year/year and an half depending on the project
Pica_soO 9y ago
Agile is not about improving performance - its about removing the burden of efficiency proof from management. Pre-agile every manager had to be constantly on the prowl to get "numbers" and dates from teams, to gain a metric, to show progress, to demonstrate them actually having a place and job in the whole cooperate process. Now they can point at realized features and make a funny progress bar from ice-box to Tested. That this progress bar might hide tech-debt, that some realized modules might have to be silently rewritten to accommodate follow up stories- and thus that one last feature might be as expensive as all that have gone before. Well that is treacherous developers, slacking off.
- marcosdumay 9y ago
  It also trades strong global deadlines of the "your project must be done by X" type for weak local deadlines of the "this feature should be done by X" type. That is custom-made for projects that face scope creep. But, yes, it's impossible for developers to create an overall plan, or for the developers to decide to pay back technical debit. But can still be done by the client, but those normally don't.

blatherard 9y ago

Are you saying that the high-performing teams are continuing to work as they were, and the other, presumably lower-performing, teams being made to act differently? That doesn't sound too bad, at least on its face.

LoSboccacc 9y ago
Flashy != Productive working on stories instead of layers you push out finished ux and features early on, and that's what both manager loves but ultimately kills the speed after six month to a year, because those need to be maintained forever but it's very rare to actually squeeze teme to refactor and even if you do, speed slows down as you refactor The team spending less on the ui and more on making sure they get the datamodel right and the abstraction thight can quickly built an ui over the stable platform and overall will have better speed past a year/year and an half depending on the project

Pica_soO 9y ago

Agile is not about improving performance - its about removing the burden of efficiency proof from management. Pre-agile every manager had to be constantly on the prowl to get "numbers" and dates from teams, to gain a metric, to show progress, to demonstrate them actually having a place and job in the whole cooperate process. Now they can point at realized features and make a funny progress bar from ice-box to Tested. That this progress bar might hide tech-debt, that some realized modules might have to be silently rewritten to accommodate follow up stories- and thus that one last feature might be as expensive as all that have gone before. Well that is treacherous developers, slacking off.

marcosdumay 9y ago
It also trades strong global deadlines of the "your project must be done by X" type for weak local deadlines of the "this feature should be done by X" type. That is custom-made for projects that face scope creep. But, yes, it's impossible for developers to create an overall plan, or for the developers to decide to pay back technical debit. But can still be done by the client, but those normally don't.