space here for a longer term or strategic business view. Simply being the user of a system is not enough to meet business needs.
The Product Owner role in Scrum is an improvement on XP. But Scrum says nothing about how the role is to be performed beyond the Scrum process. There is nothing wrong with this, neither does Scrum say anything about developers using continuous integration or refactoring.
Scrum, rightly, has a well defined limit on practices. It so happens that ensuring business alignment falls outside this limit. Were Scrum to include the necessary practices the method would balloon in size.
Not all Agile methods are Scrum and XP. Evo, for example, does consider requirements in more depth but few teams use Evo. On the whole the requirements side of the equation is absent from the popular Agile practices.
There is work, good work, on the requirements discovery process from people like Chris Matts, Luke Hohmann , Mike Cohn and even a little from myself. Several comments on the February's piece pointed to this work.
The important thing here is that this work falls outside the mainstream Agile methods; too many teams that have adopted Agile have deficient requirements processes.
Requirements more important than ever
The truth, as usual, is more complicated than it first appears. Some people have interpreted "Requirements Come Second" as a call to ignore requirements. In fact the opposite is the case: business alignment is more important than ever.
Consider a company that is initially stuck in the maintenance zone with falling sales. They adopt Agile and their sales improve by 13% on Bain's figures. Agile has done a great job!
Now if they can stay effective and get aligned sales will improve by 24% more. Being aligned with good requirements has real benefit. Ultimately it generates more value than simply becoming effective alone.
While many companies will continue to struggle with IT some will, by adopting Agile and other techniques, succeed in creating effective IT groups. Of these some will take the next challenge and improve the alignment with business need and strategy.
Managers need to lay the foundations of improved alignment even as they start the Agile transition while taking care to avoid the alignment trap. Its as if the first runner in the relay race has started and the second must be ready to pick up the baton. This means building a corps of skilled Product Owners.
We need to move beyond talking about the Product Owner in terms of the Agile cycle. Backlog management, user stories and such is all-necessary but does not go far enough, there is much more to being a Product Owner than is commonly recognised.
Product Owners need to look deeper into the application domain, understand users and the business, then have the vision to create roadmaps. However the skills needed differ depending on nature of the organization.
In companies that create software products - ISVs and others who generate revenue from the sale of software to multiple customers - the Product Owner roles need to be staffed by Product Managers.
Conversely, in corporate IT departments and service providers - companies which create software for their own use or for the use by a single client - the same role needs to be staffed by Business Analysts.
The Product Owner role is actually two different roles that present the same interface to an Agile process. Correctly staffing the Product Owner role to match corporate need is the first step in aligning Agile teams with business needs.