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.
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 does 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 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. And 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
What is a Proxy Product Owner?
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.
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 from 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.
What other factors should be kept in mind if you are considering a contract that involves Agile projects?
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.
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:
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.
- 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.
Fixed-Price Models
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. However, 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.
Agile Fixed-Price
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.
Fixed-Price (Payment-per-Sprint)
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 this 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 & Materials
In a T&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 & Material (Payment-per-Sprint)
This model is very similar to the fixed-price per sprint model that we studied earlier. However, 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 & 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?
- Flexible scope
- Fixed budget
- Invoices should be in proper accordance with the expenses incurred.
This contract is only suitable if appropriate empirical data is available to all of the contractual parties.
- Flexible content
- Pay per productivity.
- The payment structure is based on the agreed-upon productivity rate.
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.
Conclusion
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. Happy Managing.
Also Read:
Originally published at https://www.ntaskmanager.com on December 13, 2019.
