4 ms·

One if the issues I see with Agile in practice is that it draws clear lines around individual tasks. Developers become responsible for their own individual task

One if the issues I see with Agile in practice is that it draws clear lines around individual tasks. Developers become responsible for their own individual tasks but don't take responsibility for the project as a whole or how that task might fit into it. For a small already effective team the adoption of Agile really just resulted in more meetings and less cohesive end results.

wavefunction 12y ago
You need better developers and managers then. What you're describing is a personality trait, not a side-effect of adopting AGILE practices. The developers have to care about the project as a whole and the managers need to communicate upwards, downwards, and horizontally: that's how a team maintains a high-level view while implementing in the weeds.
dragonwriter 12y ago
> One if the issues I see with Agile in practice is that it draws clear lines around individual tasks. There are no doubt methodologies that do that, and some of them are probably sold as being "agile", but there is nothing particularly agile about doing that and most writing son Agile (and its close relative, Lean) actually recommend doing the exact opposite and eliminating most role distinctions within development teams and finding ways to establish broader collective ownership of the product as a whole (different authors differ in the specific approaches they recommend trying in order to achieve this.) > For a small already effective team the adoption of Agile really just resulted in more meetings and less cohesive end results. That sounds like you didn't adopt Agile -- the orientation toward software development encompassed in the Agile Manifesto -- but some externally-defined canned process that some consultant slapped an "agile" sticker on to sell to people who don't know what Agile is. If your existing pattern of interactions is working effectively, "adopting Agile" shouldn't mean much change besides something like periodic discussions of how it is working, and what any pain points are in it, and how to tweak it to resolve those pain points. In fact, even if your current processes aren't working, that's what adopting Agile should look like at first -- any bigger changes should come out of what the team discovers in those discussions (which may then lead to adopting, on a trial basis, particular practices that have been defined externally that appear to be designed to address the issues that the team is having to evaluate if they work for the team, but adopting a set of canned externally-defined processes without reference to the specific needs of the team isn't adopting Agile -- its something opposed to Agile that puts process over people and interactions.)

wavefunction 12y ago

You need better developers and managers then. What you're describing is a personality trait, not a side-effect of adopting AGILE practices. The developers have to care about the project as a whole and the managers need to communicate upwards, downwards, and horizontally: that's how a team maintains a high-level view while implementing in the weeds.

dragonwriter 12y ago

> One if the issues I see with Agile in practice is that it draws clear lines around individual tasks. There are no doubt methodologies that do that, and some of them are probably sold as being "agile", but there is nothing particularly agile about doing that and most writing son Agile (and its close relative, Lean) actually recommend doing the exact opposite and eliminating most role distinctions within development teams and finding ways to establish broader collective ownership of the product as a whole (different authors differ in the specific approaches they recommend trying in order to achieve this.) > For a small already effective team the adoption of Agile really just resulted in more meetings and less cohesive end results. That sounds like you didn't adopt Agile -- the orientation toward software development encompassed in the Agile Manifesto -- but some externally-defined canned process that some consultant slapped an "agile" sticker on to sell to people who don't know what Agile is. If your existing pattern of interactions is working effectively, "adopting Agile" shouldn't mean much change besides something like periodic discussions of how it is working, and what any pain points are in it, and how to tweak it to resolve those pain points. In fact, even if your current processes aren't working, that's what adopting Agile should look like at first -- any bigger changes should come out of what the team discovers in those discussions (which may then lead to adopting, on a trial basis, particular practices that have been defined externally that appear to be designed to address the issues that the team is having to evaluate if they work for the team, but adopting a set of canned externally-defined processes without reference to the specific needs of the team isn't adopting Agile -- its something opposed to Agile that puts process over people and interactions.)