Hybrid PMO: Managing the Hybrid Portfolio
Hybrid PMO: Managing the Hybrid Portfolio
- The Problem: As Agile crosses the mainstream, enterprise-wide adoption of hybrid methodologies like Agile Development and traditional Waterfall create conflicting processes.
- The Solution: Better Predictability with Metrics that balance the merge and clash.
- The challenges of this become much more complex as you start to deal with the program level consisting of various projects and methodologies.
Hybrid Projects: Agile Development and Waterfall, Together
The Scrum process focuses on the tactical execution of requirements generation and implementation, for environments where scope is fluid and schedule cannot be predicted reliably. It does not attempt to define how the enterprise or business unit operates, and it will not usually be the only type of development process present in a large organization.
How to Manage Hybrid Projects
The first step to managing a hybrid project is to recognize that it decomposes well into (say) waterfall and Scrum sub-projects, and to plan each sub-project with the appropriate process.The second step is to identify the dependencies between these component projects. For hybrid projects, the predictive projects typically generate milestones that act as constraints for the adaptive projects. The Constraint-Based Planning method for hybrid projects starts by identifying the critical milestones in one project on which the other project depends, and planning the latter around the former. For example, production deployment cannot occur before the production environment is ready, even if the software is ready for release well in advance. In this case, the development team would continue to develop new features (e.g., reports) until the production environment is ready, and then deploy the new capabilities to production.
While the project as a whole is hybrid in nature, from the “top” or containing framework it would most likely be viewed as a waterfall or SDLC project. This is because the waterfall nature of some of the sub-projects will be reflected in the organization of the overall project. In contrast, the Scrum sub-projects, which are designed to be more adaptive than predictive, will then adapt to the constraints and predicted schedules that define the rest of the project.
How to Manage Complex Hybrid Projects
Large, complex projects, which contain multiple communicating subsystems that have strong dependencies on each other, present more challenges than the example above, but the challenges are of the same kind. While a pure-Scrum project developed by one team has great freedom to develop features when desired, development in complex multiple-subsystem environments is strongly constrained by dependencies. In these cases, planning often crosses subsystem boundaries, and requires defining a careful choreography of development steps to be performed by different teams at specific times. This kind of work is a common exercise in Program Management, and the basic concepts are not much affected by the use of Scrum in some subset of the projects. Scrum enters the picture when scheduling work to be done in a coordinated fashion across projects, as this work is assigned to specific Sprints in the Scrum projects.
Organizing Cross-Team and Cross-Project Implementation
A Program in a large enterprise or business unit will contain many projects, and each project may contain many teams. The hierarchy of teams and projects is shown in Figure 3.
Figure 3 Project and Team Hierarchy
Teams within a project usually work in close coordination with each other. Teams in separate projects may be closely coordinated or completely independent, but most often work together on an occasional basis, as needs dictate. We will look at how different teams collaborate below, and summarize the most general case for requirements management in Figure 4.
Collaboration within One Team
In Scrum projects, requirements for each team are defined by the team’s Product Owner, and work to implement the requirements is managed by the ScrumMaster. This type of collaboration is clearly defined by Scrum.
The Daily Scrum meeting provides the opportunity to produce a common awareness of progress, and to identify any issues encountered by anyone on the team that require help from someone else to resolve. The resolution of issues occurs after the meeting, when the relevant people work together on them. The team also views the current Burndown chart to see how team progress as a whole is tracking against the plan.
Cross-Team Collaboration within a Project
Scrum does not specify how teams within a project collaborate, but there are common practices. The practices focus on requirements definition, scheduling, and execution. Collaboration between teams is necessary when a product specification requires synchronized work across the teams. This collaboration is described below, and the requirements-management portion is illustrated in Figure 4.
Cross-Team Collaboration across Projects
Collaboration across Projects is very similar to collaboration between different teams in the same project. The difference is mostly one of scale. If the number of Projects is large enough, one Lead Product Owner may not be able to manage cross-Project requirements, in which case it is necessary to create a cross-project Product Owner hierarchy that contains a number of Lead Product Owners. Scrum does not have a title for the person who leads this group, but “Program Manager” is often used, and we’ll adopt the term here.
The Program Manager is responsible for working with the Lead Product Owner group to identify cross-project requirements, and ensure that they are broken down into team-level Stories, and the process described in Section 11.2.1 is followed successfully.
The Program Manager may also be the person to conduct “Cross-Project Scrum” meetings, attended by one representative from each SoS meeting, and whose purpose is the same as the SoS meeting.
The tracking metric for cross-project work is the Enterprise-level Burndown chart.
