Agile Contract Models While Working With Cross-Corporate Teams
How cross-corporate cooperation works, the pros and cons of how the roles are distributed, and how to write an effective Agile contract.
Join the DZone community and get the full member experience.Join For Free
Agile Methodology is one of the best practices to keep your team and company in tip-top shape. The companies that use Agile methodology have to focus heavily on the Agile methods, roles, principles and work practices that are incorporated in it.
You may also like: We Really Need to Talk About Agile Contracts
But even with all of these Agile resources at your disposal, they won’t address the cooperation of cross-corporate teams. In this article, you will get to know the following things:
- How cross-corporate cooperation works.
- The pros and cons of how the roles are distributed.
- How to write an effective Agile contract that will help secure the position of everyone involved in this collaboration.
How Do Teams Based on the Agile Methodology Work?
Let us start from the very beginning. An Agile team and even a scrum team consists of a product owner, a team of developers and a scrum master. This team of developers uses sprints to properly focus on their developmental goals for new or even existing projects.
The general principle of developmental cycles is that they should not last more than a month. There are two major bandleaders in this process. The stakeholder expectations and requirements are defined by the product owner. The scrum master is sort of a team coach that helps the developmental teams to become familiar with this type of development.
Who Is a Product Owner?
Many people confuse the terms Product owner (PO) and Scrum master as the same individual but that’s not the case. Let us clear up the confusion.
An Agile team does not have to be a scrum team. It can be a normal group of people that collaborate together using Kanban (Kanban is a procedure where developmental goals are achieved without a time restraint on the developers, unlike sprints).
It can even be a collaboration that uses hybrid elements or custom contracts that are a combination of Agile and traditional procedures to achieve their goals.
Well, in any case, there’s generally one person that is responsible for clarifying the requirements, documenting the process and communicating all of the material to the team. This individual is known as the product owner, even in teams that are not based on scrum.
There is no specific individual that can take on the role. Even requirement engineers, customers or even business analysts can assume the role. To make things easier, this role will be referred to as the product owner.
Who Selects the Product Owner?
Nowadays cross-corporate teams based on the scrum model are the way to go and even more so than the single-company teams because no project is a simple straight forward one and you have to be creative with your approach. That’s why many Agile teams are faced with a dilemma of incorporating the rules and regulations of the scrum teams without having the consequent guidelines.
The firsts step is to pick the individual that will select the product owner by asking the following questions:
- What level of warmth is present between the client and the supplier?
- Is there any specific guarantee that the product owner representing the customer will be able to effectively work with the development team in close proximity and they will be available for counsel at any time?
- Does the team trust the product owner and its principles? Or are there any problems with them?
- Who has suitable knowledge about the stakeholders and can properly understand their needs?
- Who has proper knowledge about the market?
- Meanwhile, who has suitable knowledge about the development team and understands their methods?
- Who can translate and prioritize the requirements of the client at the execution or implementation level?
- Is there someone in the group who has previous experience of being a product owner?
If the product owner is to be selected on the supplier side, the individual needs to have the following skills:
- Familiarity with internal development processes.
- Technical skills.
- Proximity to the implementation team.
If the product owner is going to be chosen from the client-side, that individual needs to have the following skills:
- Power or authority through their position as a paying client.
- Proximity to the market, the end customers/stakeholders, the requirements.
The best approach to decide the distribution of roles with the client and the contractor is to discuss the issue during the negotiations of the contract and then properly document the conversation in the contract. It becomes even more important to clearly state the role distribution if you decide to divide the product owner responsibilities among the contracting parties.
This should always be your top priority because most of the conflicts occurring in the projects are due to the roles not being properly defined, often resulting in legal battles.
What Is a Proxy Product Owner?
There is always an option available in the shape of a hybrid solution while choosing a product owner from one of the contracting parties. This hybrid solution will be the Proxy Product Owner (PPO). When this hybrid scenario is in play, there is a product owner from both the contractor company and the client company. The PO form the client company acts as a liaison to the client.
The PPO is generally a weak designation because they have very little decision making powers. They basically are a filter with regard to the requirements.
The best practice in the PPO scenario is to grant the proxy owner the authority to resolve the solution. They are facing problems just like a “True Product Owner” and they should be equipped accordingly to deal with them.
They should be given permission to make product-related judgments and to set different priorities to tackle any obstacles or the job should be given to an individual with such powers.
At the very least, the roles should be clearly defined, and more emphasis should be put on communications and alignments between them. If the roles are not properly defined, then the conflicts will endanger any efforts to facilitate product development.
What Other Factors Should Be Kept in Mind If You Are Considering a Contract That Involves Agile Projects?
If you followed the upper mentioned steps, then hopefully you have solved the puzzle of who is the product owner and who gets to choose them. There are still a few things to be considered in Agile contract management:
- The development team are the technical gurus of implementation and they should be able to organize itself according to the given framework
- The assumptions and leadership principles governing the project should be clear to everyone involved in the whole process
- All of the shared interests and partnership agreements should be documented in writing and not just let to the imagination
- All of the stakeholders involved in the client’s company should be regularly present in the meetings to discuss all of the details.
Agile Contract Models
Given below is the detail of all of the contract models that are used in the Agile paradigm. The billing practices of every type of Agile contract are also discussed below.
This model is very useful for all of the people that want to minimize the risk of the costs exceeding the budget. But it’s not that bullet-proof. Here are some of the reasons why many clients feel that fixed-price contracts are not very suitable for Agile projects.
- Fixed-price Agile contracts only define the time frame for the initial stages of product development. Further development, support, and maintenance, that come after that initial stage are initially ignored.
- This model also lacks the ability to alleviate the risk of missed deadlines or a product that has rendered useless for the client.
- Another drawback of this model is that it doesn’t give the ability to reshape the budget according to the needs of the clients. And because Agile methods generally revolve around the needs of the client whose price hasn’t even been defined yet, using a fixed-price model is not feasible.
Other elements that are important in this scenario are specifications that contain very vital information for the client and are a big part of the call for bids that are available to the bidders. This collaborative interaction has to be agreed upon initially so that the bidders can develop a thorough description of the content and scope.
Sometimes this description is produced using a template provided by the client. In Agile projects, where the requirements are not properly defined, these descriptions can actually innovation because of the interconnected nature between the two entities.
If this is the case, then a more lightweight document is cemented called a product backlog.
Fixed-Price Model With Infused Agile Elements
If you want to still add a fixed-price model in your Agile model and make it more suitable for it, you will have to infuse some Agile principles in it. The following factors can really help with that.
- Functions are undefined at the start of the process. Every contracting party is supposed to confirm this fact to the others.
- Project goals, on the other hand, are mutually agreed upon with the help of a clear vision of the product development roadmap. The contracting parties are obligated to share information with the help of frequent discussions and not just memo sharing back and forth.
- Cooperative approaches are put in place to solve any and every problem and an Agile mindset is pushed to find common ground and reduce any differences.
- The end goal or the completion criteria should be mutually agreed upon by the product owner and the stakeholders. These criteria should also be included in the contract. This being an Agile project, these criteria might change during the project’s lifetime.
- Other documents that can be included in a fixed-price model infused with Agile elements are Team charters and Role clarifications.
Prioritizing Agile Projects
There are a lot of issues in Agile projects and estimates can be quite wrong which causes a lot of problems to occur. If this happens you need to react accordingly. In the very worst of conditions, the project is scrapped entirely before even development starts.
If the contractual parties are not ready to do that, then the service provider must reevaluate the portfolio’s priorities which will make room for compensations for the problems that affect the project. This will safeguard the project’s own liquidity.
In order to make the Fixed-price model even more Agile, you have an option called the Agile Fixed-Price model. With this model, you explain the agreed-upon project scope first that is properly based on the product vision and then provide a rough but relevant description of all of the features incorporated in the project.
All of the contractual parties then estimate the effort needed for the project using story points and then clearly translate the data into person-days. This estimation is achieved by gaining a reference point from simulating a sprint planning meeting.
There is still a contingency plan in place where the project can still be scrapped if the estimation for the manhours comes out to be too extreme.
Mutual agreements are also reached based on the risk distribution among the contractual parties associated with the project. Contractors can make themselves in-charge of developing any additional features if the budget allows it.
A very distinct type of contract for the agile projects in this paradigm is the Money for Nothing, Change for Free model. This was introduced by the co-inventor of the scrum itself named Jeff Sutherland.
In this scenario, the client will initially pursue the traditional route by clearly enunciating the requirements. This will prompt the bidder to respond by making a bid at the fixed price.
When the implementation initiates, the client will automatically assume the role of the PO and manage the product backlog accordingly.
Another exclusive concept is the Money-for-Nothing principle. This concept is used when the service provider and the bidder agree to end any further product development that will obviously end their collaboration on the topic.
The basic contract can also be made more Agile regarding the payment cycle. This payment cycle can be aligned with each sprint sequence. Basically, it will be a fixed-price per sprint. According to this contract model, all of the stakeholders have many fixed-price projects while each change represents a mini-product.
Every newsprint plan will lead to a new contract and each review report will represent some sort of an acceptance meetup. When the stakes are connected to the sprints, the time frame of every sprint sequence is clearly defined. Some other models that are very familiar to this one are Blanket Purchase Agreements.
Time and Materials
In a T and M contract, the client will make sure to pay the contractor according to the timesheet hours spent on product development and the price of all of the materials that were used. This is a very effective type of model for an Agile project that doesn’t produce very precise information in the initial stages and has room for change.
It’s very important that the contractor assigned to the project is not morally corrupt that takes advantage of the situation. They should remain true to their team and also in documenting the expenses.
If there is any conflict between the stakeholders in this model and that goes to court, another problem can arise in the form of employee leasing.
Time and Material (Payment-per-Sprint)
This model is very similar to the fixed-price per sprint model that we studied earlier. There is a proper agreement on the fact that the client will only pay for the features and product deliverables that were accepted by the team in the sprint review. This model will only be acceptable by both of the contractual parties if there is a solid trust foundation between them.
Otherwise, you really can’t make it work because the supplier is liable to provide all of the services and provisions in advance for the whole duration of the development sprint even before they get paid.
Some Other Customized Contracts for Agile Projects
There are a lot of customized contracts that can be used in the Agile paradigm in addition to all of the common ones like the Fixed-price and Time and Materials. According to studies about Agile projects, the following ideas will be very feasible:
Contract Models Based on Benefit
One of the key development objectives expected from an Agile approach is to develop a value-adding product. None of the contracts that have been discussed above ensure that the objective is achieved.
That’s why most legal experts are quite unfamiliar with these contract principles.
Award Agreements Based on Benefit
This concept is based on the concept that the client will pay a daily rate that is intended to cover the cost of the contractor. In order to help the contractor make a profit on this, a special award is paid when that specific goal is reached.
You can also use impact maps that help all of the stakeholders to be properly knowledgeable about what the client considers the value and how you can actually achieve it.
This model is very suitable for Agile projects as it is a value-based payment and until the product is not completed, you won’t have to pay anything. You can also change the requirements which are perfect for Agile Projects.
Which Contract Is Suitable For You?
|Contract type||Sub-type / variation||Characteristics||When suitable?|
|Traditional fixed-price||Inflexible: If there is any flexibility need in the product development then this contract is less suitable.||This contract is very Suitable if the contractual parties all agree on the effort needed to finish the project, beforehand.|
|Fixed-Price with Agile elements.||Still very inflexible, but it can actually generate some initial awareness about the agile concepts that are being used in the project.||This is a hybrid project approach that introduces new agile principles in a very traditional environment.|
|Agile fixed-price||The fixed price for the project is determined through a product vision and a very rough determination. This method can actually work but on the off-chance it doesn’t, there is a real risk of issues occurring.||It is very suitable for all of the projects that require a fixed price set in the beginning but they also require proper use of the Agile methodology in the product development.|
|Money for Nothing, Change for Free.||This contract includes a high probability of change and the responsibility of the budget to a fixed-price project.||This only works if there is a solid foundation of trust between the contractual parties. It also depends on collaboration among the parties that are based on total equality and the client’s close involvement in the actual product development.|
|Fixed price per sprint.||This model properly enunciates the iterative nature of a team’s work that is based on scrum.||This is suitable for projects that have a strong foundation of mutual trust between all of the stakeholders. Also, the necessary data should be available or quickly acquirable.|
|Time and Materials||Payment and invoicing based on the expenses that incur and the contractor is very flexible about the work that is needed to be performed||This is suitable for projects where the contractor will not abuse the trust put on them by the client and with complete confidence that the contract model will not be legally thrashed to its disadvantage.|
|Pay what you get.||The contractor will work in advance and complete the development phase, but they will get paid only when the client approves of the results after the sprint completes.||This contract demands a very high level of trust among the contractual parties and is really not for the weak-hearted. There should be constant communication among them so that there are no unpleasant surprises in the end.|
|Design to cost.||
||This contract is only suitable if appropriate empirical data is available to all of the contractual parties.|
|Pay per productivity.||
||It is only suitable if there is enough trust in the contractor that they will actually produce something useful for the client and also there is a strong client involvement needed.|
|Purely value-added contracts||In this contract, more focus is given to the needs of the clients which is one of the core principles of the Agile paradigm.||This contract is only applicable if there are proper metrics available and understood for defining, measuring and evaluating the added value.|
|Benefit-oriented award agreements.||The team that works on the product development is paid based on the effort they put in and they will receive an additional bonus for the added value they have produced.||This will only work when there are Good metrics available for evaluating and defining the added value produced by the contractor.|
|Pay-per-use.||SAAS licensing model.||This will only work for projects that introduce license-based software and their regular use.|
Every project is unique and nowadays, thanks to modern project management techniques, we are better able to identify and work on the projects with the raw material they bring along with them.
Obviously, when there are so many techniques available, no single contract model is the ONE for every project. Well, this is true for all Agile projects.
Hopefully, this article has helped you understand a lot of precise contract models that will definitely help your product development antics according to the Agile paradigm.
Published at DZone with permission of Fred Wilson, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.