Group items tagged

The dates and themes for the next release are fixed. The features are prioritized and variable.

The teams can commit only to the features in the next upcoming release. Releases beyond the next, represent only a best estimate.

The Roadmap, then, is a “plan of intent” and is subject to change as development facts, business context and customer needs change. With respect to the upcoming release, perhaps the most important guidance is this:

Even though the team has committed to the objectives and we have agreed that the feature set cannot be guaranteed, it is a reasonable expectation that the agile teams will: 1) meet the date 2) accomplish the theme 3) deliver most of the features, and certainly the highest priority ones, with the requisite quality.

Anything less would be unprofessional and belie the power, discipline and accountability of our agile enterprise model. Moreover, it will eventually threaten our own empowerment, as failure to deliver will inevitably cause the implementation of various controls to “help us”!

Independent Software Vendors (ISV) -teams of teams who develop software for sale, including products like network management, supply chain management, mobile applications, etc. This segment now also includes the rapidly emerging Software as a Service (SaaS) vendors. Customers are external to the enterprise.

So far, former developers/tech leads with business sense and good project management skills seem to be the best fit.

ultimate user (mobile device user) is fairly far removed from the major technologies

Ryan went on to note that the title of "Program Manager" also performed a similar role in some larger scale contexts:

Embedded Systems Example - Symbian Software Limited

Clearly, the development of a mobile phone operating system is a highly technical endeavor

mention this because I suspect that the Technical Marketing Specialist role, where it exists in the ISV today, could make a good role model for the Agile Product Owner in today's larger ISV

the development process does not lend itself quite so easily to the traditional, customer/user facing, agile Product Manager/Product Owner roles. However, the Product Owner role must still be successfully addressed in this highly technical context.

All our POs come from engineering teams and are senior engineers with product or customer experience.

one PO to two team mapping typically, rarely 3 teams, sometimes 1

IS/IT Examples

role/title of the Business Systems Analyst

is often a reasonably good fit for the Product Owner role.

In the larger IT shop, I have also seen the role filled by Project Managers

In many cases, the self-managing and team-based planning lightens the workload for the project manager in the agile enterprise, and they often have the domain knowledge, inclination and insights necessary to fulfill the Product Owner role. Therefore, many have the time, skills and inclination to fill this role.

In our case, our product owners are in IT. They are the liaison to the business and in many cases speak for the business

Our Business Systems Analysts in IT are filling the role of Product Owner. Their previous responsibility of documenting detailed business requirements and rules now falls to the entire team in the form of user stories and acceptance tests