AgileOrganizations

To validate the team delivery of working code meets expected standards there are several concepts that can be used.
* Engagement Objective – Defines the EXPECTATIONS on the full delivery after the Engagement is done. These Objectives should be measurable.
* Sprint Objective – Defines the EXPECTATIONS on team delivery at the end of each Sprint/Iteration. These Objectives should be measurable.
* Definition of Done – describes WHAT ACTIONS needs to be done before an Item can be considered done, i.e. ready for evaluation.
* Acceptance Criteria – defines the EXPECTED RESULT for each Item/User Story. This must be measurable through the Definition of Done and clearly stated comparable with criteria set.
* Working code – this term is aimed at what is delivered at the end of a Sprint/Iteration. It does not have to be code, but rather that Quality of output does not conflict with what is already delivery in a working format. So, with that definition a document that meets acceptance criteria and does not contradict previous versions of that document (or what it is aimed for) is within the concept of working code.

Internet of things, IoT, automation and robotics are examples of when machines are making decisions that will affect the commercial relationship between two parties.
From a technology perspective this is opening up a number of new possibilities and potential solutions to problems we do not necessarily know we have.

The backside though, is the legal perspective and how this can be used both on a private level and on an organizational level. From a speed perspective there will not be time to actively approve decisions made and accepting potential outcomes of these implicite contracts.

I do not think our society is ready for this even if the technology already exist!

Most of our contracts today focus on a specific transaction and tries to identify risks and the owner of those risks. It also stipulates what happens if those risks are realized and potential penalties. So, such transactional contracts manages a predefined delivery and the following potential blame game of not following the initial plan.

In Agile software development you are not making big upfront specifications, instead you are defining objectives, work together towards those objectives and where you end up delivering is the result of the collaboration. Hence there is no specification to write a contract around. This is a common situation using Agile development practices and especially when using external services providers. Innovation is a similar thing where you can not know what the end-result would be and therefore can not write a contract managing the transaction in detail. Both these scenarios challenge the way the commercial relationships are managed and how contracts are written.

One way to be better equipped to manage Agile development and innovation is to focus on how people are working together. Work out how the cultural landscape should look like to promote creativity and collaboration. Considering social norms and how culture affects communication and trying to put it into writing. Contracts would then be used to manage how iteraction and collaboration is happening to drive trust between stakeholders. This approach is often called relation contracts and one example is the open source initiative vested.