Das Herzstück des "Agile Cooperation Modells" ist der "Agile Code of Conduct", welcher die verbindlichen "Spielregeln" für die Zusammenarbeit in den gemischten Teams vorgibt und auf dessen Einhaltung die "Spielteilnehmer" gesondert zu verpflichten sind.
5.1.1 "Spielteilnehmer"
Zunächst legt der "Agile Code of Conduct" dabei die "Spielteilnehmer" fest, d. h. welche Art von Personal in welchen Rollen mit welcher Häufigkeit in gemischten Teams zum Einsatz kommen darf. Je höher das Risikopotential (v. a. bei Freelancern), desto größere Restriktionen müssen für die "Spielteilnahme" gelten.
5.1.2 Regeln zur Vermeidung von schädlichen Weisungen
Ein weiteres wesentliches Element des "Agile Code of Conduct" sind Regelungen, die sicherstellen bzw. vermeiden, dass in den gemischten Teams untereinander schädliche Weisungen, d. h. solche in Bezug auf Inhalt, Durchführung, Zeit, Dauer und Ort der Tätigkeit, erteilt werden.
Dazu definiert der Code als eine seiner Kernaussagen, dass bei der Arbeit in gemischten Teams ausschließlich ein fachlicher Austausch zulässig ist.
Der "Agile Code of Conduct" legt dazu u. a. fest, dass
- keine Weisungen gegenüber anderen Mitarbeitern anderer Arbeitgeber oder gegenüber Freelancern ergehen dürfen (= keine "mixed instructions"),
- zwar zu erzielende Arbeitsergebnisse umschrieben werden dürfen, den Spielteilnehmern aber maximale Eigenverantwortung in Bezug auf die Arbeitsorganisation und Arbeitsdurchführung gewährt wird,
- eine Projektleitung nicht "durchregieren" darf, jedenfalls nicht in Bezug auf fremdes Personal,
- die Teammitglieder auf Augenhöhe – also selbstbestimmt – arbeiten,
- keine festen Hierarchien in Form starrer Organigramme (mit Ober-/Unterverhältnissen) bestehen,
- Beginn und Ende der täglichen Arbeitszeiten möglichst flexibel gehandhabt werden,
- die Teammitglieder frei in ihrer täglichen und wöchentlichen Arbeitszeitaufteilung sind (v. a. frei darin, an welchen Tagen sie sich auf den Gemeinschaftsflächen aufhalten oder an anderen Rückzugsorten arbeiten),
- keine festen eng durchgetakteten Terminpläne bestehen und
- den Teammitgliedern der Zugang zu den Gemeinschaftsflächen bzw. den jeweiligen für sie bestimmten Rückzugsflächen nicht verwehrt werden darf (s. dazu).
Disziplinarische Maßnahmen gegenüber den Teammitgliedern müssen schließlich zwingend den jeweiligen Arbeitgebern vorbehalten bleiben. Auch dies bedarf der Klarstellung im "Agile Code of Conduct".
5.1.3 Regeln zur Vermeidung der Eingliederung
Ferner beinhaltet der "Agile Code of Conduct" Regelungen, die vermeiden, dass eingesetztes Personal in den Betrieb eines anderen eingegliedert wird. Demzufolge legt der "Agile Code of Conduct" Folgendes fest:
- Es muss jederzeit eindeutig erkennbar sein, welcher Vertragspartei das jeweilige Teammitglied angehört. Bei der physischen Zusammenarbeit auf der Gemeinschaftsfläche (s. dazu) sind insoweit gut sichtbare Erkennungszeichen zu tragen, wie z. B. farbige Bändchen, Namensschilder etc.
- Es darf kein gemeinschaftliches Corporate Branding o. Ä. geben, sondern im Team müssen die jeweiligen Teammitglieder unter der Identität ihres Arbeitgebers bzw. Freelancer unter ihrer eigenen Identität handeln.
- Es bedarf der Klarstellung, dass die Zusammenarbeit im Team allein einem Zweck dient, nämlich der Erfüllung des Projektzweckes. Soweit nicht-projektbezogene administrative Randarbeiten zu erledigen sind, müssen diese jeweils allein durch das eigene Personal des jeweiligen Unternehmens erbracht werden.
- Es darf bzw. sollte keinen einheitlichen "Provider" für die Arbeitsmittel geben. Vielmehr muss jedes Teammitglied mit eigenen Arbeitsmitteln bzw. denen des eigenen Arbeitgebers arbeiten.
- Es darf keine einheitlichen Benefits für die Spielteilnehmer geben, insbesondere bleiben typische Mitarbeiter-Benefits, wie z. B. vergünstigtes Kantinenessen, absolut tabu für Mitarbeiter anderer Unternehmen oder Freelancer.
- Schließlich legt der "Agile Code of Conduct" fest, dass die Vorgaben zum Raumkonzept strikt zu befolgen sind.
Als "Eskalationsinstanz" ist zudem aufseiten jeder Vertragspartei ein Ansprechpartner vorzusehen. Dieser Ansprechpartner fungiert – aufgrund der Zusammenarbeit im Übrigen (s. o.) – nicht als klassischer "Brückenkopf" bzw. klassischer "Single Point of Contact", über den etwa sämtliche Kommunikation zwischen den Vertragsparteien zu erfolgen hätte. Über ihn können und müssen aber kritische Themen eskaliert werden, sollte es im Rahmen der Projektarbeit aufgrund des dort nur fachlichen Austausches und Miteinanders einmal "haken".