A Drop In The Stream

In further response to the Cranky Product Manager’s Agile Heresy:

I find your cranky style amusing and agree with your logic about the limits of the benefits for Product Management in the current way businesses typically implement agile development methodologies. As another commenter noted, agile processes were worked out to improve developer/engineering IT pain but the squeeze on the toothpaste moved the pressure to Product Management. Since agile does solve important software engineering problems well, it seems wrong-headed to throw the baby out with the bath water. Rather let’s identify the mismatch between traditional Product Management and agile IT methodologies and then figure out what is required to effectively interface with an agile engineering group.

In my view there are two aspects or roles of Product Management: Strategic Product Management and Tactical or Operational Product Management. The strategic folks interact with customers and think the “big picture” and long term thoughts about product direction. In my experience, these product managers aren’t the right people to work with IT. There needs to be another layer of Product Management that I refer to as tactical or operational Product Management.

A Tactical Product Manager (TPM) is something akin to what used to be called a systems analyst. The key difference between the traditional systems analyst and the TPM is that the latter is schooled in how to decompose product requirements into agile user stories. The TPM, unlike the strategic Product Managers, has skin in the game – ie, is a participant in the weekly iterations and accountable with the dev team for completing the committed to work package of stories for the iteration.

As part of an agile development team the TPM ensures that there are appropriately sized user stories prepared for each iteration that are aligned with the organization’s strategic product direction. The TPM is also a real-time clarifier of requirement issues and tries to stay a step ahead of the coders by analyzing work in progress for possible requirement gaps or conflicts. As part of the Product Management team the TPM is able to see how selected user stories build into releasable feature sets and serves as the interface between development and Product Management to determine the releasable stories or groups of stories for a release.

My sense of your crankiness is that you’ll mellow some if a staffing strategy such as I propose above were implemented in your organization. The challenge is finding or training TPMs because traditional systems analysts (aka requirements analysts) aren’t always a good fit for agile shops – they often love big, up front analysis and thick MS Word documentation. Finding good people is a challenge on the IT side as well though so it should make you happy, in some cranky way, that the IT manager is struggling with the same issue you are.