"In proof of collaboration sprints, the emphasis is on the 'how'; you deliver pieces of working software directly and you work together as one Scrum team. ."
Mark van der Ploeg, CPO
From Proof of Concept to Proof of Collaboration
Testing in a practical situation
Advantages and implementation of Proof of Collaboration
'Proof of concept' was a phenomenon from the Waterfall model, in which your customer would ask you to demonstrate that you were capable of executing the project. The customer would know exactly what was being delivered, but never how much collaboration would take place. In proof of collaboration sprints, the emphasis is on the 'how'; you deliver pieces of working software directly and you work together as one Scrum team. You test in a practical situation.
Waterfall: Proof of Concept
With the proof of concept, you took a small risk as a customer by only investing a low budget, and this also allowed you to discover the quality delivered by the supplier. You knew whether they had a good understanding of your requirements (scope), you knew whether they delivered on time (deadline) and you got an indication of the quality of the software. You could see exactly what was delivered. However, you never saw how much work was done while the POC was being built. Well, it was an acceptable level of risk. After all, it didn't matter. Or did it?
The world has changed. In Agile software methodology, the proof of concept — and the corresponding terminology (scope and deadline) — no longer exists. The question of how to build is at least as important as what to build. The question between what needs to be built and how it needs to be built has been taken apart and equated. And quite rightly! So, what now?
Replace the POC with a POC: the proof of collaboration.
Agile – Proof of Collaboration
A proof of collaboration is a period of three or four sprints in which the entire Scrum team works together and tries to answer the question: 'Can we work together successfully?' The aim of proof of collaboration is therefore to discover and learn how to work together as one team. The question of what to build is secondary to the question of how to work together.
The goal is to build up a relationship of transparency and trust between the customer (Product Owner) and the supplier (Scrum Master and development team). We do this by clarifying roles, responsibilities, expectations, like-mindedness and a workable process within the team through a practical situation.
According to the Scrum Guide, 'Empiricism means working in a fact-based, experience-based, and evidence-based manner. Scrum implements an empirical process where progress is based on observations of reality, not fictitious plans.'
At the end of each sprint, the Scrum team schedules a retrospective to discuss and implement improvements in the collaboration. At the end of the POC, we discuss more broadly whether there has been sufficient progress to enter into more long-term collaboration. You could say that this is an extra detailed retrospective with and for stakeholders to determine whether there is an interest in establishing a long or longer term process.
There are not enough evidence-based experiences from one sprint, so the POC takes three or four sprints. This period usually serves as a good foundation for successful collaboration. If, after four sprints, a good foundation has not been reached, ending the collaboration is a reasonable step to take.
Delivery of working software
In any case, working software is delivered at the end of each sprint. The difference with an old-fashioned proof of concept is that no agreement is made in advance on exactly how much is delivered (no scope). The Scrum team always takes the items at the top of the backlog and discovers during the proof of collaboration how many can be implemented per sprint.
What comes after the POC period?
There are two options:
- There was not enough of a click for long-term collaboration. This means that the customer can enter another follow-up process using what has been built (still working software).
- Collaboration is going well. Both sides simply continue working using the validated method of collaboration, and as Scrum states, at the end of each sprint they will be optimised by means of a retrospective.
Not quite clear yet?
Compare it like this: in a proof of concept, a supplier is asked to build something that floats and resembles a boat, in the hope that the supplier will eventually be able to build a boat. Crazy, right? How realistic actually is this assumption?
During proof of collaboration sprints, the Scrum team builds a very small piece of boat, which will eventually form part of the actual boat. We mainly focus on the collaboration between the supplier and the customer in order to coordinate an efficient, transparent work process that creates a much more valuable image of the final delivery of the project.