Hereditary conditions

Many product managers who work with or within Agile teams have told me how they've felt left in the dust during the early phases of the Agile implementation. "We've sighted our target persona!"the development team exclaims. "Champagne for everyone!"

Unfortunately, they forget to invite to these festivities the very person who will, beyond this sighting, provide ongoing intelligence about that role--and the use cases, and whether that's the right role for the product, and what the competition is doing to serve that person, and whether there's a market for all this technology in the first place. A good product manager also has mad skillz in collecting and analyzing this information, something that even the most wunderbar of Wunderkinder doesn't necessarily have right out of the womb.

Shane Hastie at InfoIQ describes the same problem facing business analysts, the cousins of product managers in IT organizations.

There is a gap in much of the literature about Agile software development practices, and on many Agile teams. This gap is the role of Analysis in Agile projects - who does it, what is the use and value, and how does it change? The implied (and I have heard stated at least once) attitude is "we don't need no stinkin' analysts" - needless to say I feel this is WRONG!

Hastie's advice for the business analyst echoes suggestions I've heard for product managers. The analyst is a pro at business requirements. You can get economies of scale in tasks like user story development if you have one person do it full-time, instead of lots of people trying to squeeze in the necessary time. Business analysts are often good parents, model citizens, and loving pet owners, too, so why not extend the hand of eternal chumship to them? And so on.

As well-intentioned as this argument may be, perhaps it's the wrong approach to make. Perhaps the burden of proof should fall on the shoulders who think that they can do the business analyst's job and their own without committing grievous errors.

I'm a pretty smart person. Over the years, I've read a fair number of mystery novels, and enjoyed a sizeable number of detective shows (Columbo, the many-headed Law and Order hydra, the excellent BBC Sherlock Holmes series with Jeremy Brett, etc.). However, I don't feel obliged to take over the task of investigating crimes from my local police department--especially given the risks.

We see police detection as a profession--just as we might see business analyst, or product manager, in the same way. We just don't see the harm in doing a bad job of requirements collection and analysis. Perhaps in an economic downturn, the higher cost, for technology vendors, of making bad product decisions might change that perception.


re: Hereditary conditions

Tom,Good perspective on the role of and value of business analysts and product managers.Their focus has to start with understanding BUSINESS needs (whether internal IT or external market) and communicating that clearly within the development organization.Saeed

re: Hereditary conditions

My Agile knowledge is only book/presentation level, never having the opportunity to be fully versed in the methodology. I did have one group doing "Agile light" but won't let that cloud my opinions.Agile appears to be a development methodology even though it is promoted as a business approach. When pressed most SCRUM Masters admit that there is value in the product manager/business analyst role, but that value shouldn't slow down their dev cycles.The PM/Business Analyst has to do all of that work upfront in order to properly drive use cases and build the backlog. It almost appears like it has to be tag-teamed; one person embedded with the dev team and another looking at the overall business impacts; focusing on future releases/backlog.