Why Use Polychor® Project Management for Managing Multiple Scrum Teams?

I hear people often talk about Scrum projects, but what does Scrum have to do with project management? In this article, I want to explain the relationship between product management and project management, why I think Polychor®  is the best project management platform to use when you are dealing with managing multiple Scrum teams.

Product Versus Project Management Lifecycle

Organizations can be organized in many ways. Most traditional organizations are managed using departments where every department is responsible for a typical function within the organization and the department heads report to the board of directors. These are called functional, top-down driven organizations where every department has its own delegated decision power. These are process driven organizations.

More modern organizations are managed differently. They operate in an iterative and incremental way and are more adaptive to change, and besides being process driven, they are also product focused. Instead of the department making decisions, senior management appoints one person to act as the sole decision authority for the complete lifecycle of that product, from the initial idea to the scrapping of the product from the portfolio. When that Product Owner is responsible for a complete portfolio of products, he or she might be called the Product Manager.

Every organization, no matter how it is organized has a portfolio of products. Some products are still in their early stages (problem child), some can potentially bring a lot of value in the future (stars), some are mature and are selling very well already (cash cows), and some are almost at the end of their lifecycle (dogs). An organization is constantly looking at the current portfolio and how it can improve the portfolio to become more effective and efficient. Managing the portfolio of products and any changes being made to the portfolio is a responsibility of the Product Manager. The Product Manager can assign an individual to act as Product Owner for one or more products on behalf of the Product Manager. The Product Owner is product lifecycle focused. Any changes that need to be made to one or more products can be done using a project environment.

Scrum is an agile driven framework and has its origins in software development, but about ten years ago, other departments in organizations started looking at becoming more agile and analyzing whether the Scrum approach could also be used in their departments— and in projects. In this article, I am not looking at Scrum from a software development perspective but rather from an organization-wide and project management perspective.

In Scrum, we have three roles. The Product Owner, the Scrum Master and Developers. The Product Owner is product focused; the Scrum Master is process focused, and the Developers are a group of maximum nine people who are responsible for creating the products. Scrum uses a prioritized wish list with features, called the Product Backlog. Anyone can go to the Product Owner with ideas, and the Product Owner will decide if the feature is added to the Product Backlog. This has nothing to do with project management. The Product Backlog is about the product lifecycle and not the project lifecycle. The Scrum Master is responsible for creating an environment in which the features can be created in the most effective and efficient way and is, therefore, process focused.

The Product Owner takes items from the Product Backlog and bundles them into items that he or she would like to have created in the next version or release of the product. So, items are copied from the Product Backlog to the Release Backlog. This still has nothing to do with project management. Next, the Product Owner needs to make the decision who to present the Product Backlog item to. This could be a single person in the form of a task, or a self-driven agile group of people, for instance, using Scrum themselves to develop the Product Backlog item, or a larger, multi-functional group of people. The latter is called a project and the group of people use a project management method to create Product Backlog items presented to them by the Product Owner. In Scrum terms, everyone in the project is a Developer, and this group of developers get tolerances to create the Product Backlog item(s) in an iterative, incremental, and thus adaptive way.

In Polychor, the project has an owner. This owner is called the Project Owner. This Project Owner is product focused and responsible for achieving the project benefits set out in the Project Backlog. Once the Project Owner has decided to create these features presented to him by the Product Owner, the Project Owner will copy the features onto the Project Backlog.

What happens next in Polychor is that the Project Backlog items are divided into features and products that need to be created in the project. In Polychor, these deliverable products are called specialist products and are mentioned in the Project Release Plan and the Project Increment Plan. In Polychor the role of Project Manager is called the Project Scrum Master. This role is responsible for creating and managing a project environment in which the products and features can be created in the most efficient and effective way. So, what the Scrum Master does in the whole organization, is what the Project Scrum Master does in the project environment. The organizational Scrum Master uses Scrum Artifacts to manage the environment, whereas the Project Scrum Master uses management products. Traditional project management methods have many roles like Senior UserSenior SupplierProject AssuranceChange AuthorityProject Support and Team Manager. They are all collectively responsible for the development of the project’s products, so we could just call them the Project Developers. Besides the role of Project Scrum Master, Polychor has defined roles like Project Owner, User Representative, Supplier Representative, Project Support Office and Delivery Team. 

Polychor® and PMP® are fundamentally different, although both are called a project management method. PMP is about creating specialist products in a project environment. Polychor is about creating a controlled environment where we do not get surprised all the time and is focused on managing and delivering management and specialist product in an agile project environment.

Polychor is a generic project management platform on which any kind of project management method can be used. Delivery Teams can use any kind of method or framework to create specialist products, including Scrum and PMP. In short, Polychor is focused on the management and specialist products, whereas PMP is focused on specialist products only. Both methods can be used in agile and non-agile environments. 

In traditional project management methods, the Project Manager gives assignments to one or more Team Managers in the form of assignments or Work Packages. In Polychor the Project Owner takes items from the The Increment Plan and present these items to the Delivery Teams. Once accepted, the Delivery Teams place the items on their Sprint Backlog

Scrum only has a few artifacts but Polychor has a complete set of management products consisting of backlogs, strategies, registers, reports, boards, and so on.

Every management product has its own owner and its own set of developers and someone who sees to it that the management product is created and maintained in the most efficient and effective way. So, that means that every management product has a Product Owner, a Scrum Master and a Developer. Any Polychor role can have a Product Owner, Scrum Master and/or Developer responsibility for any kind of management product. In summary, the Scrum framework can be used to feed a project, to create and maintain management products and to create and maintain specialist products.

You can have an unlimited number of Delivery Teams in Polychor. Every Delivery Team can use its own approach. From a Polychor perspective, the Delivery Team just accepts an assignment from the Project Owner.

PMP is very different. PMP is product focused, whereas Polychor is product and process focused. You can use Scrum to tailor the PMP project environment.

Scrum.org has developed a framework that allows up to nine Scrum teams to work together on one Product Backlog. This is called the Nexus framework. Every Scrum team has a Developer represent the Developers on the Nexus team. The idea is pretty good but limited in two ways. You can only use Scrum teams (whereas in Polychor you can use any kind of framework), and you can have a maximum of nine Scrum teams working together (whereas in Polychor there is no limit).

I have been teaching traditional and agile project management methods and frameworks since 2001 to over ten thousand people on all continents. In the US, the PMP method is used a lot more than Polychor, and in the US, it is not understood that Polychor is the ideal platform for managing an unlimited number of Scrum teams. Polychor and PMP are complementary to each other and should not be seen has competing with each other.

Why did Scrum.org create the Nexus framework? Why not just use Polychor?

Polychor did not exist yet when Scrum came to the market. 

Why should an agile Product Owner, Scrum Master and Developer learn about Polychor?

Scrum teams do not operate in isolation anymore. They must work together to create Product Backlog items. There are multiple frameworks that help you do this. Nexus is one of them. It is likely that sooner or later you will need to understand how projects work using Polychor.

Why should Polychor project managers learn about Scrum?

More and more development teams use the Scrum approach. As a Project Manager you need to understand how to handle these teams using a coaching style of management rather than a top-down command-and-conquer style. Scrum can also be used very effectively to manage the Polychor project environment. Management products can be tailored very effectively using Scrum

1 thought on “Why Use Polychor® Project Management for Managing Multiple Scrum Teams?

Leave a Reply

Your email address will not be published. Required fields are marked *