Sounds like quantum physics; you can measure an object’s movement or identify it’s location, but not both.

IMO one of the reasons why Agile methods have worked is that they’ve been tried first by early adopters who tend to have pretty good people at all levels.

Now they’re starting to get (mis)-applied by the early majority, who are going to run into trouble because they don’t know where the load-bearing walls are.

http://www.ufunctional.com/2009/01/30/load-bearing-walls/

You can succeed with waterfall, and you can succeed with agile. But to the extent that your initial requirements are volatile and your estimation accuracy is limited, you’re better off with a less brittle, adaptive process (agile). But you still can’t shut your brains off.

It was the ability of the agile methods to consistently deliver value, on a schedule and budget, that won me over. They do this by providing feedback that lets the business manage for value, rather than just hoping the initial requirements and estimate were good enough (and piling on the overtime and generating a bunch of scrap and technical debt if they weren’t).

http://wistechnology.com/articles/5190/

http://wistechnology.com/articles/5514/

As for “creed” or “ethos,” I’m a pragmatist, and land in the middle. There’s a lot about agile methods that you can tinker with, but there are also load-bearing walls. Cut into them at your peril.

http://www.ufunctional.com/2009/01/30/load-bearing-walls/

If they’re consistently pretty good, you’re probably in a stable environment (same dev team, same code base, same product management) and you really don’t need agile.

If they’re not, when and how are the estimation and planning errors manifesting themselves, and how were you compensating?

Thanks for coming by. Look forward to future comments.

In a nutshell, smart people will figure out how to work effectively with or without any kind of methodology. All the religiosity pitting Agile vs. non-Agile methodologies ignores the fact that it’s the people and not the methodology that make things happen.

Just like every diet boils down to: “eat less, exercise more”, every methodology can be summarized as: “hire talented people, use common sense.” This is especially true for software development.

Saeed

Thanks for the detailed comment. A couple of points.

1. There is a distinction to be made between internal IT product/project management, where there THE (singular) customer may actually exist, and ISV software development where the “customer” is really a market or market segment. My writing is focused on the latter. In the internal IT scenario, the customer may simply be the internal project sponsor or some similar entity and have the Product Owner and Product Manager be the same may work.

2. Even for ISVs , it CAN work, but that doesn’t mean it is ideal or recommended. From an ISV Product Manager perspective, putting more time into the development cycle means less time in other places. There are a few options.

a) Load it all onto the existing Product Management (i.e Product Owner responsibilities) and decide what you don’t want them to do that they are currently doing

b) Add headcount (Technical Product Managers) to the PM team and give them the PO responsibility along with other things

c) Find or assign headcount on the Dev side of the org (there’s likely a lot more dev headcount than PM headcount) who can take on this role, and have them work close with the PM team to ensure tight communication and coordination.

There may be other ways to deal with it, but anyone who picks option a) better not assume that the PM team can simply absorb the new duties with impact to other aspects of their job.

3. I completely agree with your point on continuing to produce MRDs, PRDs etc. They have a lot of value to the business as a whole.

Saeed