-
Published on
December 15, 2020
-
Updated on
December 15, 2020
-
Read time
7 minutes
- Category
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:
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.
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:
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.
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:
The requirements of having a product owner from the client side are as follows:
And the requirements of having a product owner from the supplier side are as follows:
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.
There are three main categories of contracts in the Agile contract model. Those categories and their subcategories are as follows:
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 |
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.
Manage your team, tasks, projects and more on a single platform. Sign up today, it's free.