Junilu Lacar wrote:
Andrew Stellman wrote:
And as it turns out, when waterfall projects are run effectively, it’s because their teams take to heart many of the same values, principles, and practices that agile projects follow. Projects that are run using some agile techniques and practices—but that don’t really follow the agile values and principles—often end up running into the same kinds of problems that plague waterfall projects.
This is why I keep getting back to mindset, attitude, values, and principles. Those things have a huge impact on how well an agile (or waterfall!) team builds software.]Learning
Absolutely agree. But that makes me question the labels "waterfall" and "agile" in these cases. Is a so-called waterfall project really waterfall if the teams follow agile principles and values? Is a so-called agile project really agile if the teams don't really follow agile values and principles? Who is more righteous, the man who says "Yes" but doesn't do what he says he'll do or the man who says "No" but ends up doing the right thing anyway?
Junilu Lacar wrote:
Matt Kidd wrote:I had every intention of instituting some form of agile but the current Director of PMO is against it without providing reason.
And the director's objection to Agile is stopping you because... ? At the very least, did you press the director to have a discussion about his objections? Is there anything stopping you from using agile technical practices? I would do things like continuous integration, automated testing, and other agile technical practices anyway. After all, these practices contribute to the quality of the software, regardless of whether the project is Agile or not. I find it's not hard to justify using agile technical practices even when there are objections to using agile process practices.
William Brogden wrote:
Design patterns in general are worth browsing through when you are hunting for inspiration but don't feel you have to cram every problem into a named pattern.