• user warning: Unknown column 'captcha_type' in 'field list' query: SELECT module, captcha_type FROM drup_captcha_points WHERE form_id = 'comment_form' in /home1/geminsig/public_html/sites/all/modules/captcha/captcha.inc on line 65.
  • user warning: Unknown column 'captcha_type' in 'field list' query: SELECT module, captcha_type FROM drup_captcha_points WHERE form_id = 'user_login_block' in /home1/geminsig/public_html/sites/all/modules/captcha/captcha.inc on line 65.

Why Agile Is a Step in the Wrong Direction

One of the most crucial decisions in Agile software development is who will be the Product Owner. In an IT project done within a company or by a systems integrator this is not too difficult as someone from the line of business or an analyst representing them can typically be found. In an ISV environment, however, this becomes much tougher.

The natural Product Owner would be a product manager. But mostly I’ve seen engineering managers serve as Product Owners, especially if there are multiple Agile teams working in parallel. Typically, product managers still maintain responsibility for backlog prioritization, but engineering managers often write the user stories and they handle most of the ongoing user story discussions, clarifying with the product manager only as needed.

No one likes this arrangement – product managers feel they are not involved enough in defining the product and engineering managers feel they are not adequately equipped to perform this task (plus it takes them away from other tasks). The reasons this is so common are very practical, though – product managers just do not have the bandwidth and availability to be the Product Owners, and there are always more engineers than product managers …

One could argue that this is not too different from the past, when product managers wrote higher-level PRD’s and engineering would detail them out in functional specs and design documents. However, the nature of Agile user stories and the fast pace of releasing new functionality mean that product decisions are being made more quickly and frequently, and in many cases not by the product manager. Identifying the right items in the backlog is important, but how each one is implemented in the product is as, or even more important. As Thomas A. Edison said: “Genius is 1 percent inspiration and 99 percent perspiration.” A great idea is not worth much without the right execution.

And so, in many companies the side effect of Agile development is that many product decisions are made further away from the actual users and buyers. This is a step in the wrong direction – we need to get more tuned-in to the needs of our users, not less so. Now, obviously, Agile has many advantages that we all want to leverage, and I have not yet run into anyone who wants to go back to a waterfall process. What’s the solution?

If more product decisions are done on-the-fly while interpreting and clarifying user stories then we need to find ways to bring customers and other stakeholders as close as possible to those decision points. As I wrote in "Will Co-Creation Save Product Management?", product management must undergo a paradigm shift towards a co-creation model. A model that involves customers, partners, and other product value stakeholders directly in the product management process. And we need to develop the methodologies, processes, and tools to enable this model to succeed in real life.

Easy? No. Necessary? Absolutely.

What is your experience with Agile product management? How have you coped with its new challenges? Have you tried co-creation? Looking forward to hear your comments!



Post new comment

  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

More information about formatting options