Interview with Kristian Borkert

Hi Kristian, you are a lawyer and you have a lot of expertise regarding agility. What is the reason for that?

Yes, this sounds unusual at first. I am probably one of the very few lawyers who are also qualified as a Scrum Master. I am always concerned to find practical solutions that actually work. I came across agile methods over 10 years ago. At that time, I was doing a lot of contracting in IT sourcing. When a project leader, whom I have supported in the first phase of his project, came to me with the information: “Kristian, we need the contract for Phase 2 soon. Now we are working completely agile”, it quickly became clear to me that we cannot rely on standard patterns, but have to go new ways that better support the agile processes and do not create a parallel world in the contract.

One of the guiding values of the Agile Manifesto is: “Customer collaboration over contract negotiation”. Does agility prioritize wrong here? What is your opinion as a lawyer on this?

When you see the sentence in isolation, it would scare most lawyers and purchasers. Really, they may want to work together without a contract? What is about privacy, compliance and a regulatory framework? When you take a deep breath and read the entire Agile Manifesto, you learn that contract negotiation is important, but in direct comparison with customer collaboration it is considered as secondary. This is because the contract itself does not guarantee the success of the project, but a successful cooperation with the customer is almost half the battle. It is about understanding both levels. A contract that successfully implements the agile principles and supports the project is, in my experience, a strong catalyst for the project's success.

Agility across organizational boundaries is still in its infancy. To what extent do the participants, who are in charge of contract drafting, have to suddenly rethink those new projects?

In my opinion, agility in many companies is first and foremost a hip label, a buzzword. It often says agility, but there's no agility. This is something I notice especially when agile project are implemented across organizational boundaries. Especially cross-discipline functions such as quality assurance, purchasing, legal and the like are often lacking expertise in this area. Of course, you can download and read the Scrum Guide, but based on my experience this is not enough to understand agility. In particular, change management, backlog management and prioritization relating to project vision and added value do not match with the traditional thinking, that the final product is completely known at the beginning of the project. In the past, of course, this was seldom actually the case for longer projects.

If you work agile across organizational boundaries, it might be the case that it is not quite clear whose intellectual property the product contains at the end, right? How do you handle this problem? 

Innovations and products like self-driving cars or a blockchain-based ecosystem for mobility are often created by building on the ideas of others. In mixed teams with multiple suppliers and the client, multiple parties (e.g., development engineers, product managers, software developers) are commonly co-creators or are entitled to file a patent application. When a patentable invention or the next WhatsApp is born, everyone would like to be a father of the invention and it will be difficult to reach an agreement given the economic potential. For agile collaborations, I recommend to define clear rules for intellectual property in advance, depending on the business model being discussed.

To what extent does an OEM risk an unintended contract conclusion with a supplier’s developer in a joint agile project? Is the automotive industry facing a bigger problem with agility across organizational boundaries?

When working closely with suppliers, e.g. with a development engineer or software developer, the question always is whether you are actually working together as if you are actually in an employment relationship. To put it differently: has the service contract only been concluded in appearance but in fact an employment relationship is the basis for cooperation? A central criterion is whether the service provider is instructed by the client according to labor law, e.g. what tasks he has to do this morning. However, these issues are quite manageable through a good design of the collaboration model and the establishment of a compliance system, especially in the agile environment, which builds on autonomous and self-organizing team members.

Thank you for the interview! Last question: What can the conference participants of the Agile Automotive 2019 look forward to during your session? 

You are welcome. Thanks for inviting me. I designed the workshop very openly. As an introduction, there are some basics of agile contracting. Then it is very much up to the participants what we will do. I have prepared a number of topics for selection such as temporary employment (“Arbeitnehmerüberlassung”) and agility, robust change mechanisms, and quality and acceptance of deliverables. Alternatively, I am also happy to discuss practical examples of the participants and to jointly develop solutions. I am really looking forward to what the participants will decide and the exchange of ideas.