I was delighted to share some insights on the Scrum.Org webinar, with Mirko Kleiner and Eric Naiburg. The topic of the webcast was “Procurement and Supply Chain in Agile Transformations: Emerging Trends 2024”. During the webcast there was the opportunity to ask questions. Due to the time limit we did not have the opportunity to answer all the questions. This blog is to address those questions.
Question: “And as Enterprise Agile coaches, who may work as consultants, how do we create Agile contracts for ourselves with other coaches, startups or larger firms?”
The short answer is “It Depends” – and that is not useful.
In my experience it is based upon trust, risk management and effective governance.
I would encourage a more relational contract, as they are best structured to reflect the complexity of the work we do.
When I have worked with associates that I have great trust with, it is usually an email, or even a whatsapp message. Would you do X for client Y? If we are at a client together, then I use a ways of working canvas, and regular check ins to ensure we are aligned. I further model the work that we do on a visual work board of some description.
I find that when engaging with a client, structuring the engagement is key.
My experience since discovering Lean Agile Procurement is to use the LAP canvas as the tool for establishing the engagement.
It will create the structured conversation necessary to establish clarity between yourself and the other parties.
The LAP canvas can be used between coaches, as well as between businesses. I have used it to build better collaboration between departments as a tool to help realign them on the common purpose.
There are some engagements that will follow a more traditional contracting model, where there will be an Non-Disclosure Agreement (NDA), Master Services Agreement (MSA), and then a series of Statements of Work (SoW). The key with these is to ensure that the documents are not biased towards one party. I think it is critical that we model the agile ways of working and call out imbalanced legal documents.
Question: “When asked about “collective contract” in the study, is it “agile collective contract” ? if no haven’t non agile collective contract existed before for work needing consortium for specialty or size of work to be done“
There is a range of responses depending upon the specific circumstances and context that you are in.
There is often some framing documentation before coming together and forming a collaborative contract. There may be a need to complete some agreements – such as a Non-Disclosure Agreement (NDA) – to create a space where different parties will be comfortable entering a negotiation. It is often the case that the different organisations are aware of each other – it is a question of creating a space of trust so that they are comfortable coming together to negotiate a common solution.
When more traditional contracts and agreements are in place, this is an opportunity to review, and perhaps re-negotiate these documents. This is a key difference in this approach where the supporting documents around the business relationship are reviewed and updated as needed. This is the reason that people from the Legal, Procurement, Risk and Compliance perspectives need to be included in the conversation.
It can be helpful to consider that contracts will range from the traditional to the relational, and that the parties could and should discuss the structure that will help build trust, collaboration and mutual success.
The key with these is to ensure that the documents are not biased towards one party. I think it is critical that we model the agile ways of working and call out imbalanced legal documents.
Question: “If there are two different companies working together, will there be one product owner? If so, they will be “elected” by the management of these two companies? What is the best practice?”
There will usually be one company that is the catalyst or initiator, they typically are the leader of the group. To start the process there needs to be some envisioning and definition of direction. The person that does that and remains doing that is called the Product Owner. They may choose to delegate some activity, however there will be one person accountable for the value delivered. In Scrum, that is the Product Owner.
It is very powerful to have clarity of that accountability, it enables faster communication and decision making.
Useful Resources
The Lean Agile Procurement Alliance
Download the Lean Agile Procurement Canvas