In part one of this article series, I described how Scrum is only a part of a larger Agile transformation program, why product centricity is vital and how it requires us to set up outcome-oriented teams. In this concluding part, we'll explore how to deal with streams of work that cut across several outcome-oriented teams, and what product-centric IT means for the roles of project and program managers.

Programs, Projects, Products and Portfolios

A program is generally understood to be something larger and more complex than a project. Programs (and products) have roadmaps, while projects have plans (though often unrealistic). Programs tend to get executed by multiple teams, projects by single teams. Program and project teams are temporary organizations as compared to product teams. Programs of work tend to be headed by a steering committee, governance team or “management office”.

Someone once quipped that the ‘P’ in PMO is polymorphic. Depending on one’s stage in their IT career, it stood for ‘project’, ‘program’ or ‘portfolio’. Cynical as it may sound, many big programs in enterprise IT are born (in part) out of a need for prestige and progression, rather than necessity. However, the success rate of big IT programs is much worse than that of small projects. Yet, big programs continue to get funded. The funding process is also partly to blame for this.

In most organizations, IT, being treated as a cost-center, has no power to initiate (self-fund) a piece of work. Someone has to draw up a project initiation proposal or something like that and put it in front of a funding committee for consideration. The whole process is usually so arduous (even though well-intentioned) that IT managers prefer to draw up big (but risky) proposals to get a big chunk of money, than go through the process multiple times for small (but safer) pieces for work.

The Rise of Product Owners

Product-centric IT works differently. Product teams in enterprise IT are formed in alignment with business capabilities (e.g. catalog, order entry, fulfillment) and are headed by product owners. Product owners are empowered to manage their own roadmap and self-fund items on their roadmap (note that many Scrum product owners don’t have these powers and therefore aren’t what we are talking about here). They don’t have to draw up a project initiation proposal every time they decide to prioritize an item on their backlog. They are accountable for business outcomes, hence they are given some rope (autonomy) in deciding how to use their budget. The budget is sanctioned based on the relative importance of outcomes for a given budgeting cycle.

Thus, the centre of gravity shifts from project managers to product owners as we shift from project-centric execution to product-centric execution. Can erstwhile project managers simply assume a new role of product owner? Not always. Product ownership is a different skill. A product owner focuses on providing greatest business value within the constraints of the operating environment. This is significantly different from the 'on-time, on-budget, on-plan' focus of the conventional project manager. A product team may have a manager with a delivery focus, but this person is subordinate to the product owner in product-centric IT.

Cross-Cutting Streams

Sometimes, new streams of work may cut across multiple product teams. For example, a new regulation might require extra recordkeeping and small changes to business logic across systems owned by different product teams. Or a new feature may require enhancements to the capabilities of systems owned by different product teams. In these situations, it is useful to designate a new person as a temporary stream owner or coordinator (as the case may be) and have them work across product teams to manage dependencies and influence prioritization, in order to deliver the new stream of work. This is as close as it gets to a program manager in product-centric IT. Of course, a typical program consists of several, temporary streams of work and that is something we try to avoid in product-centric IT.