We always talk about many different methods, practices, roles, and principles that make up for the wonderfully complex world of Agile. But have you ever noticed that none of these elements describe how cross-corporate teams are going to collaborate in the Agile world?
In this article we are going to talk about the Agile contract model and also talk about:
- How Agile contract model is designed to keep everyone involved in the contract safe?
- How does cross-corporate collaboration works in the Agile world?
- The pros and cons of how different roles are distributed among the entities involved in the Agile development process.
What is a Product Owner?
As we know that not every agile team needs to be a scrum team because they are not that dependent on each other. You can just have a group of people that work together using Kanban and the work model would still work.
Another instance can be a team or a collaboration among different professionals that make use of hybrid elements associated with the business and combines all of the traditional and agile procedures to create the perfect product.
In both of the cases, there is normally one person that bears the responsibility of clarifying the requirements to both the high-level management and the development team, documenting all of the project development tasks and processes, and communicating all of the requirements to every stakeholder associated with the project.
Yes, that person is the Product Owner.
This role is specifically not a management role and it can be taken over by the following entities associated with the company.
- Requirements Engineer
- Business Analysts
- Customers of the company
How Agile Teams work?
If you have been a part of the project management paradigm for a while now then you would know that most of the time an agile team is a scrum team that consists of the following members. They are:
- Scrum Master
- Product Owner
- 3 to 9 developers
The Agile team uses a method of iterations for its project development process called sprints. These sprints or high-focussed time durations are used in the development of a new project or are used in the further development of an existing project of the company.
These development cycles or sprints must not be longer than one month, and if they feel like going over that limit then you should break them down into smaller pieces and get the job done.
The scrum master in this whole scenario acts as a process owner and a team coach that helps the development team in their quest to understand the rhythm of the project development process and getting them up to speed.
Agile Contract Model: Who Elects the Product Owner?
As we see in the Agile world, cross-corporate scrum teams are the more common teams that work in the project management paradigm and they are even more common than the single-company teams that operate in the paradigm.
But when it comes to choosing the product owner to lead the whole operation, the first step is to clarify which of the parties involved in the Agile contract model is going to do that.
This selection has to be done very quickly because they have to negotiate the contract with the customer and how they are going to take the project further. That is why this selection has to be done as soon as possible to get the project started.
While selecting the product owner, the following questions have to be answered. They are:
- Who is completely familiar with the development team, how they operate in the project development process, and what are their methods of operations?
- How much are the people involved in the agile contract are knowledgeable about the agile methodologies and the overall agile paradigm?
- Is the person that is going to be selected for the role familiar with the job description of a product owner?
- Does the candidate know how to assess the relationship between the supplier and the client?
- Will the candidate being selected for the job role be available as much as possible to support and facilitate the client and the development team?
- Will the candidate be able to translate all of the requirements of the client into simpler tasks that are going to be completed in the project development process by the development team?
The requirements of having a product owner from the client side are as follows:
- If they are a paying client then the power or authority through their position
- How close are these clients to the end-users, the requirements, and the other stakeholders associated with the project?
And the requirements of having a product owner from the supplier side are as follows:
- Proximity to the implementation team
- Technical skills
- Familiarity with internal development processes
Simple & Secure Team Collaboration
More efficiency, seamless collaboration & faster deliveries
What is a Proxy Product Owner?
There are many times in the Agile world where a single product owner is not acceptable by the other parties or there are some authoritarian issues among the contracting parties. In such a case, they strive to find a hybrid solution for the problem, and that solution is to find a proxy product owner.
In this hybrid case scenario, one product owner comes from the client-side and one comes from the supplier side so that both of the sides can get the representation they so desperately require.
The representation can be counted as a good thing but when it comes to the position strength of the proxy product owner, they are not that strong. This is why they generally have very little decision-making authority among the two PO’s.
Let us take a look at some of the other factors that you should consider when there is an Agile contract model in place involving different agile projects.
- You should make it clear to everyone involved in the Agile contract model about the assumptions and different leadership principles that are going to be used in the project development process
- It should be made clear that the development team members are the technical experts that are going to be in charge of the implementation, and they should be able themselves within the given framework of the project development process
- All of the shared interests and partnership points should be documented in writing so that there are no problems down the road
- Stakeholders and the other development staff should regularly participate in the scrum meetings arranged by the product owner to talk about the project development process
Learn more on agile collaboration between teams:
The Project Management Blueprint for Agile Collaboration
Different Types of Agile Contracts
There are three main categories of contracts in the Agile contract model. Those categories and their subcategories are as follows:
1. Traditional Fixed-Price
- Fixed Price with Agile Elements
- Agile Fixed-Price
- Money for Nothing, Change for Free
- Fixed Price per Sprint
2. Time and Materials
- Pay What You Get
- Design to Cost
- Pay per Productivity
3. Purely Value-Added Contracts
- Benefit-Oriented Award Agreements
- Pay Per Use
| Contract Type | Sub-Type | Characteristics | When is it Suitable? |
|---|---|---|---|
| Traditional Fixed-Price | — | This contract is generally the less flexible option when you are in the product development process | This contract is suitable if you know that the product development process is not going to have a lot of changes involved in it |
| Fixed price with agile elements | This contract is stable but still less flexible than the traditional contract, but the good thing is that it generates an initial awareness of the agile concepts for the troops | It is used when there is a need to introduce different agile principles in a traditional environment | |
| Agile fixed price | In this contract, the rough determination of the features and a product vision is used to estimate an accurately fixed price | It is used where there is a fixed price required for the processes | |
| Money for Nothing, Change for Free | This contract adds a high rate of change to a fixed-price project | This Agile contract model is only applicable when there is a mutual trust between the different contracting parties and the client is closely connected to the project development process | |
| Fixed price per sprint | This contract highlights the changing nature of a scrum team’s work | This contract model is used when there is a mutual trust between the different contractual parties | |
| Time and Materials | — | In this contract, the payment and invoicing are based on the expenses done during the development process and the contractors associated with the project are flexible to work on changing work requirements | It is used if the client agrees on it and the contractor will not abuse the relationship between the contracting parties |
| Pay what you get | In this agile contract model, the service provider performs all of the work needed, in advance of getting paid | This contract demands a high level of trust among the contracting parties and whether or not they are going to abuse the relationship with unpleasant surprises | |
| Design to cost | Flexible scope and fixed budget which is set according to the expenses that incur | It is an application when there is applicable data available | |
| Pay per productivity | Content is flexible and the payment is based on the productivity that the resource projects | It is an application where there is a strong client involvement and there is trust that the contractor will develop something useful for the client | |
| Purely value-added contracts | — | This agile contract model is focused on the needs of the client | It is used when good metrics are used to define, evaluate, and measure the added value |
| Benefits-oriented award agreements | The contractor is paid according to the effort that they put into their work | It is used when good metrics are used to define, evaluate, and measure the added value | |
| Pay per use | In this contract model, the client only pays for the functionality that they use | It is used in a project where there is a license-based software for the client and its regular use in the product development process |
Summing It All Up
Despite highlighting some of the significant areas where cross-corporate collaboration outshines conventional project management areas, there’s still more to talk about.
If you have been a part of such teams as a project manager, we’d love to hear from you. What were the challenges that you faced? How did you overcome cross-corporate adversities – so on and so forth.
Feel free to drop a comment in the comments section below. Alternatively, you can write to us by sending an email through the contact us and we’ll get back to you.
