5 ms·

The comments on the main article are too long. This isn't a problem with Agile/Scrum. This is a problem with poor management and not setting up teams for succes

The comments on the main article are too long. This isn't a problem with Agile/Scrum. This is a problem with poor management and not setting up teams for success. The entire point of Agile is to enable teams to deliver on their own schedule and by their own rules, with the team made up of all the people who will enable that to happen.

JoeAltmaier 11y ago
The OP makes real points about the failings of Agile. The Engineering team ends up subject to the whim of the Product Owner, or worse yet the PO is absent and things stall. Senior Engineers get marginalized, since they do things that can take longer than a sprint or have to do with internals not directly related to business needs. And Engineering is about a lot more than features. Agile works for some development groups. But it definitely does NOT work for many others.
- mcv 11y ago
  All the points it makes about Agile are utter nonsense. In what way does the engineering team end up subject to the whim of the PO? The PO needs to provide the details of what the business needs (someone needs to do that, after all), and what the priorities are, but he's in no way in charge of the team. If the team has no PO for a significant amount of time, that does mean that a vital part of the team is missing, but I'd like to see any dev team build something without any idea of the business needs. It's the PO's job to communicate those needs, and the great thing about Scrum is that he does so as part of the team, rather from some distant ivory tower. I also don't see in what way Senior engineers get marginalized. If anything, everybody gets treated as senior, because everybody gets ownership, responsibility and decision making power about the project (though in reality, it's of course the seniors with the clearest ideas and tend to end up with most of the control over the team). And there's generally plenty of room to include stories (even very large ones if they can't be cut up, though they usually can) about internals, infrastructure and R&D on the backlog. It's absolutely true that it's not for everybody, but your criticism and that of the article don't hold much water.
  - AnimalMuppet 11y ago
    I think that the PO criticism is this: An incompetent or indecisive PO can cripple an agile process. That's true, but (except possibly in the case of a startup), there's always a non-technical layer of management over you somewhere, and if that layer is incompetent or indecisive, your project is equally in trouble. Labeling that layer "PO" and the process "agile" changes exactly nothing about the problem. I've been in an agile process. It worked, mostly, but it broke down when the PO didn't have the time to do the work. (It was huge for an agile team - 30 people - which put a huge amount of pressure on the PO position). For the next project, the PO "didn't have time" to give us actual requirements - just "improved reporting". In the most amazing display of agile that I've ever seen, the development team lined up a series of customer conference calls to expose their requirements for reporting, and proceeded to run the entire development process without a PO. And that worked amazingly well... ... right up until three weeks before the scheduled end of the project. (We were probably going to miss by a week, on a six-month project.) Then product management showed up and said "We like what you're doing. But we need these additional things as well. Oh, and we can't change the end date." Predictably, that was the end of agile, as well as the end of any management reality for that project. (You think you can add three months of work without changing the end date? The real world will demonstrate to you that you cannot in fact do that.)
    - mcv 11y ago
      30 people in a single team? Yeah, that's way, way too big. I've been in some teams that were technically too big, but those were still less than half that. Still, good job making it work despite utterly dysfunctional management there. Agile does require that management understands what you're doing and what their role in that is. But again, that's true in any other situation too.
      - AnimalMuppet 11y ago
        Well, it worked really well for the release before that. It took a really strong proponent who was willing to hack process as we went along, but it worked - for us, for a while.
- dragonwriter 11y ago
  > The OP makes real points about the failings of Agile. The OP makes some real points about failings of management that predate Agile, and are common even where the word "Agile" isn't used, and occur (among other places) in places that use "Agile" as an empty buzzword the same as the same type of organizations would use the name of any other approach that was popular if Agile wasn't around. But none of it really has anything to do with Agile. Very little of it even has to do with Scrum (which, as an actual defined process rather than an approach to selecting/using processes, is at least subject to process-oriented criticism.) And, perhaps most importantly, no solutions/alternatives are offered.
  - JoeAltmaier 11y ago
    Agile is an engineering process. It is supposed to solve problems. Those problems remain. Ergo, Agile isn't working. We can be apologists all we want for Agile but it remains true, it often fails to improve things at all.
    - dragonwriter 11y ago
      No, Agile is not a process, engineering or otherwise. Agile is a set of principles which can guide the selection of a process and how it is applied, but it is not a process (indeed, it is fairly expressly a response to the fetishization of process.) And I am unconvinced by your claim that Agile isn't working, that is, I am unconvinced that the problems Agile exists to mitigate are not reduced in organizations that actually apply the Agile principles in hour they approach work. OTOH, I do think the "Agile" brand had failed because a while lot of applications of canned process in rote ways -- the thing Agile directly opposed -- is being sold as being Agile methods. Agile isn't an engineering process, its the the idea of applying problem- and resource- (including the staff on the team) specific engineering to the development process.
      - JoeAltmaier 11y ago
        That's pretty weak - its not a process, its an idea of a process. Whatever. Applying this idea of a process often fails, obstructs senior engineers and does nothing to enable the rank and file as advertised.

JoeAltmaier 11y ago

The OP makes real points about the failings of Agile. The Engineering team ends up subject to the whim of the Product Owner, or worse yet the PO is absent and things stall. Senior Engineers get marginalized, since they do things that can take longer than a sprint or have to do with internals not directly related to business needs. And Engineering is about a lot more than features. Agile works for some development groups. But it definitely does NOT work for many others.

mcv 11y ago
All the points it makes about Agile are utter nonsense. In what way does the engineering team end up subject to the whim of the PO? The PO needs to provide the details of what the business needs (someone needs to do that, after all), and what the priorities are, but he's in no way in charge of the team. If the team has no PO for a significant amount of time, that does mean that a vital part of the team is missing, but I'd like to see any dev team build something without any idea of the business needs. It's the PO's job to communicate those needs, and the great thing about Scrum is that he does so as part of the team, rather from some distant ivory tower. I also don't see in what way Senior engineers get marginalized. If anything, everybody gets treated as senior, because everybody gets ownership, responsibility and decision making power about the project (though in reality, it's of course the seniors with the clearest ideas and tend to end up with most of the control over the team). And there's generally plenty of room to include stories (even very large ones if they can't be cut up, though they usually can) about internals, infrastructure and R&D on the backlog. It's absolutely true that it's not for everybody, but your criticism and that of the article don't hold much water.
- AnimalMuppet 11y ago
  I think that the PO criticism is this: An incompetent or indecisive PO can cripple an agile process. That's true, but (except possibly in the case of a startup), there's always a non-technical layer of management over you somewhere, and if that layer is incompetent or indecisive, your project is equally in trouble. Labeling that layer "PO" and the process "agile" changes exactly nothing about the problem. I've been in an agile process. It worked, mostly, but it broke down when the PO didn't have the time to do the work. (It was huge for an agile team - 30 people - which put a huge amount of pressure on the PO position). For the next project, the PO "didn't have time" to give us actual requirements - just "improved reporting". In the most amazing display of agile that I've ever seen, the development team lined up a series of customer conference calls to expose their requirements for reporting, and proceeded to run the entire development process without a PO. And that worked amazingly well... ... right up until three weeks before the scheduled end of the project. (We were probably going to miss by a week, on a six-month project.) Then product management showed up and said "We like what you're doing. But we need these additional things as well. Oh, and we can't change the end date." Predictably, that was the end of agile, as well as the end of any management reality for that project. (You think you can add three months of work without changing the end date? The real world will demonstrate to you that you cannot in fact do that.)
  - mcv 11y ago
    30 people in a single team? Yeah, that's way, way too big. I've been in some teams that were technically too big, but those were still less than half that. Still, good job making it work despite utterly dysfunctional management there. Agile does require that management understands what you're doing and what their role in that is. But again, that's true in any other situation too.
    - AnimalMuppet 11y ago
      Well, it worked really well for the release before that. It took a really strong proponent who was willing to hack process as we went along, but it worked - for us, for a while.
dragonwriter 11y ago
> The OP makes real points about the failings of Agile. The OP makes some real points about failings of management that predate Agile, and are common even where the word "Agile" isn't used, and occur (among other places) in places that use "Agile" as an empty buzzword the same as the same type of organizations would use the name of any other approach that was popular if Agile wasn't around. But none of it really has anything to do with Agile. Very little of it even has to do with Scrum (which, as an actual defined process rather than an approach to selecting/using processes, is at least subject to process-oriented criticism.) And, perhaps most importantly, no solutions/alternatives are offered.
- JoeAltmaier 11y ago
  Agile is an engineering process. It is supposed to solve problems. Those problems remain. Ergo, Agile isn't working. We can be apologists all we want for Agile but it remains true, it often fails to improve things at all.
  - dragonwriter 11y ago
    No, Agile is not a process, engineering or otherwise. Agile is a set of principles which can guide the selection of a process and how it is applied, but it is not a process (indeed, it is fairly expressly a response to the fetishization of process.) And I am unconvinced by your claim that Agile isn't working, that is, I am unconvinced that the problems Agile exists to mitigate are not reduced in organizations that actually apply the Agile principles in hour they approach work. OTOH, I do think the "Agile" brand had failed because a while lot of applications of canned process in rote ways -- the thing Agile directly opposed -- is being sold as being Agile methods. Agile isn't an engineering process, its the the idea of applying problem- and resource- (including the staff on the team) specific engineering to the development process.
    - JoeAltmaier 11y ago
      That's pretty weak - its not a process, its an idea of a process. Whatever. Applying this idea of a process often fails, obstructs senior engineers and does nothing to enable the rank and file as advertised.