In the glory days when giants still walked the earth and the Agile Founding Fathers created "the team," they decreed that there would be three "team roles:"

• The Product Owner
• The Scrum Master
• The Team

I've been having many conversations recently about how to set up the agile teams I'm coaching with the right Product Owner.  As we all know, the PO must be empowered to make decisions, yet must also be knowledgeable enough about what the software should do that she can make constant small decisions for the team so they don't have to wait.  The PO understands the big picture, understands the small picture, and can set priorities.

I blogged a few months back about how the "Team Room" must be considered a metaphor, not a literal prerequisite to trying agile for the first time.  I know I am treading on equally sacred ground (stepping into equally sacred cow pies), but I am going to posit along the same lines that in a complex corporate environment, the "Product Owner" should be considered as a small village, not a literal person.  (I hear the sounds of distant drums, or maybe bagpipes, preparing for war).  I believe if the village can reach consensus and speak with one voice in a timely way on a consistent basis, the whole agile development team will be in fine shape.  The trick is building the right village.

<more>

Product Ownership is very difficult.  Take a big step away from the Agile Manifesto and think for a moment about project stakeholders, user stories, and how they don't fit together as neatly in real life as they do in Mike Cohn's User Stories Applied, as awesome as that book is.  How in the world is it possible for there to be a single person standing in for all project stakeholders in negotiating with the team?

<more>

Jim Highsmith recently posited that "velocity is killing agility!" which is kind of a fun hypothesis.  Jim observes that company leaders he talks with around the world these days are a little too quick to measure the effectiveness of their agile software development teams by keeping track of the teams' velocity (the average amount of estimated software effort the team delivers per software delivery iteration).

<more>

Let's say you are in charge of the "services" operation within the IT department of a large enterprise.  You're a government entity, a telecommunications giant, or some other titan of industry.  Other IT organizations have grown up around you in the enterprise over time, and they're writing cute little front-ends that get information from customers to your services, and pass the results back.  They're doing iPods and tablets, and you're still dealing with Cobol.  Your colleagues are all concerned with "cascading style sheets" and "user experience" and color schemes and the like, but you're doing all the grungy, large-scale back-end work that actually causes the money to pour into your organization and keep you all paid.

<more>