Dieser Vorschlag bezieht sich auf Projekte, die nach der Scrum-Methode geführt werden.Die wesentlichen Essentials dieser Methode sind hier kurz erläutert, ebenso kritische Einwände gegen die Methode.
Diese Betriebsvereinbarung regelt den Einsatz des Softwaresystems Jira zur Unterstützung der Projektarbeit in Bereichen mit überwiegend projektorientierter Arbeit.
Das System kommt für Projekte zum Einsatz, die sich für die Methode Scrum entschieden haben. Dies betrifft insbesondere Projekte mit hohem innovativem Inhalt
Der Betriebsrat erhält eine Liste der betroffenen Projekte. Auf Wunsch werden ihm die Namen der Projektmitglieder mitgeteilt.
Anmerkung: Nach unseren Erfahrungen spielen bestimmte Rahmenbedingungen für den Erfolg oder Misserfolg der Projekte eine entscheidende Rolle. So ist es wichtig, dass die Teams auch wirkliche Teams sind, die an einem Ort, am besten in einem zusammenhängenden Arbeitsraum arbeiten und nicht den Bedingungen einer Matrixorganisation mit regional und/oder fachlich verteilten Zuständigkeiten arbeiten.
Es muss geklärt werden, ob die Teams nur eine Projektaufgabe verfolgen und nicht in weitere, oft zahlreiche andere Verpflichtungen eingebunden sind.
Die Person des Projekt Owners hat oft nicht die entscheidenden Kompetenzen, um insbesondere sich gegen – auch kurzfristig geäußerte – Auflagen der oberen Führung mit Erfolg zur Wehr zu setzen.
Für die Kolleginnen und Kollegen sollte auf jeden Fall erreicht werden, dass sie besser als früher frei und innovativ entscheiden können, wie sie arbeiten, und dass sie von einer Menge eher bürokratischer Tätigkeiten (v.a. Dokumentationsarbeiten) entlastet sind.
Uns scheint, dass Erfolg oder Misserfolg auch wesentlich davon abhängen, wie die Teams sich zusammensetzen, v.a. wenn die Anforderungen wie z.B. nach der Srum-Lehre ja lauten, dass die Team-Mitglieder in gleicher Weise Spezialisten und Generalisten sein sollen, was in der Praxis schwer umzusetzen ist. Daraus würde folgen, dass man den Teammitgliedern einen Freiraum für von ihnen bestimmtes Lernen zugestehen sollte bzw. müsste.
Das alles hängt wesentlich von der Unternehmenskultur ab. Deshalb müssen wir intern erörtern, welche dieser Argumente eine Rolle spielen, um in eine betriebliche Regelung aufgenommen zu werden.
Ziel dieser Vereinbarung ist es, die Softwareunterstützung der Projektplanung und -organisation mit dem Schutz der Persönlichkeitsrechte für die betroffenen Beschäftigten zu verbinden und insbesondere eine technische Kontrolle ihrer Leistungs- oder Verhaltensüberwachung auszuschließen.
Das System wird als Cloud Computing-Anwendung der [Name des Unternehmens] mit Server-Standorten im Geltungsbereich der EU-Datenschutz-Grundverordnung betrieben. Der Betriebsrat erhält jederzeit auf Wunsch Auskunft, wie diese Regelung vertraglich abgesichert ist.
Anmerkung: Klären, ob die Anwendung auch auf mobilen Geräten zur Verfügung steht. Die hier vorgeschlagene Regelung kann nur gelten, so lange die Überwachungseignung der gespeicherten mitarbeiterbezogenen Daten gemäß den Regelungen der Ziffer 7 gering ist. Anderenfalls ist eine Einschränkung der verfügbaren Funktionalität zumindest auf der Ebene der SmartPhones zu erörtern. Außerdem stellt sich die Frage, ob die Nutzung auf SmartPhones notwendig ist, wenn die Teams ohnehin in einem Raum zusammenarbeiten sollen.
Jedes Projekt im Geltungsbereich dieser Vereinbarung verfügt über einen langfristigen Plan, der mit dem Fortschritt des Projektes detailliert wird. Dieses Verfahren soll dazu dienen, die Projektplanung nicht wie beim traditionellen Vorgehen mit einem Lasten- oder Pflichtenheft im Vorhinein schon in allen einzelnen Schritten festzulegen, sondern sie zunächst auf ihre wesentlichen Punkte zu fokussieren und sie erst im Laufe des Arbeitsfortschrittes genauer zu beschreiben.
In den Scrum-Projekten werden die Produkteigenschaften fachlich und anwenderorientiert als user stories beschrieben. Die Aufgabe, das product backlog zu führen, obliegt dem product owner, der sich mit dem Auftraggeber abstimmt.
Die Entwicklungarbeit wird durch das Entwicklungsteam geleistet. Es soll eine Größe von acht Mitarbeitenden nicht überschreiten und setzt die Anforderungen in kleinere, maximal vier Wochen dauernde Aufgaben um, an deren Ende ein fertiges Teilprojekt steht. Das Team führt darüber eine Dokumentation, in dem die einzelnen Aufgaben als tasks beschrieben und in kurzen täglichen Besprechungen synchronisiert werden. Die Arbeit wird autonom innerhalb des Teams durch Absprachen organisert und ist für alle Teammitglieder transparent.
Unternehmen und Betriebsrat stimmen in der Auffassung überein, dass die Arbeit und die Arbeitsweise mit dem System nicht Gegenstand von Zielvereinbarungen werden dürfen.
Anmerkung: Diese Regelung ist wichtig, weil die Methodik sich deutlich zum weitgehend autonomen Arbeiten der Teams bekennt und für die Projektleitung keine disziplinarischen Kompetenzen vorsieht.
Innerhalb des Projektmanagements werden die folgenden Rollen etabliert:
Der product owner ist für die Konzeption und Beschreibung der Produkteigenschaften in alleiniger Verantwortung zuständig und führt das product backlog zur Dokumentation der Produkteigenschaften. Er hält regelmäßig Rücksprache mit den Auftraggebern und Anwendern oder Kunden und erhält die zur Wahrnehmung dieser Aufgaben erforderlichen Kompetenzen.
Es organisiert sich selbst und entscheidet allein über die Umsetzung der Backlogeinträge. Aufgabenverteilung und Zusammenarbeit werden im Team autonom entschieden.
vgl. auch Regelungen in dem Dokuement Kurzfassung Scrum-Regelung
Die vergebenen Zugriffsrechte orientieren sich an den in Ziffer 5 beschriebenen Rollen. Insbesondere erhalten die Mitglieder des Entwicklungsteams alle die gleichen Rechte.
Den Mitgliedern des Entwicklungsteams steht zur besseren Visualisierung ihrer Sprint Backlogs ein Taskboard zur Verfügung. Es besteht aus den vier Spalten, in denen zunächst die aus dem product backlog für den Sprint abgeleiteten Anforderungen, gefolgt von Möglichkeiten zur Dokumentation des Arbeitsfortschriits (zu Tun, in Arbeit, Erledigt), dargestellt werden.
Anmerkung: Zu klären ist, ob es wichtig ist, auch in der Arbeit aufgetretene Hindernisse (Impediment Backlog) sowie den Umgang damit zu dokumentieren, ebenfalls auch, ob Personen außerhalb des Teams Einblick in diese Dokumentation nehmen können.
Der Fortschritt der Arbeit wird in einer Burndown-Grafik dargestellt. Die einzelnen Aufgaben werden zunächst nur sachlich beschrieben und ohne Zuordnung zu bearbeitenden Personen dokumentiert. Die Aufgaben werden erst später, nach Einigung im Entwicklungsteam – einzelnen Personen zugeordnet.
Auf eine zeitliche oder Aufwand beschreibende Bewertung der Tasks wird verzichtet, so dass im System nicht ersichtlich ist, wer wie lange oder mit welchem Aufwand an welcher Aufgabe gearbeitet hat.
Anmerkung: An dieser Stelle sollte noch der Umgang mit den sog. Story Points beschrieben werden, etwa, dass pro Aufgabe grundsätzlich immer nur ein solcher Punkt vergeben wird und dieser Punkt keinerlei quantifizierende Bedeutung hat. Vielleicht ist es auch möglich, auf die "Bepunktung" ganz zu verzichten. Es kann als ausreichend für die Bewerung des Projektfortschritts betrachtet werden, dass die Tasks vom Entwicklungsteam ja so gestaltet werden sollen, dass sie den Umfang einer Tagesarbeiit nicht überschreiten.
Das im System angebotene Reporting erfolgt ohne Namen von bearbeitenden Personen.
Suchfunktionen werden so gestaltet, dass Vorgänge nicht nach Namen von Projektmitgliedern gesucht werden können.
Die Zugriffsrechte werden für jedes Projekt separat vergeben. Dabei gelten folgende Regelungen:
Anmerkung: Es ist zu überlegen, ob eine Lese-Berechtigung auf die Sprints, nicht jedoch auf die einzelnen Tasks eines Sprints vergeben werden kann.
Anmerkung: Ist es erforderlich, eine Regelung über das Löschen zumindest der Sprint-Daten in die Vereinbarung aufzunehmen?
Der Betriebsrat wird über die Aufnahme neuer Projekte in das Projektmanagement informiert.
Zu klärende Frage: Reicht die Information des Betriebsrats aus, oder sind weiter Formen der Beteiligung des Betriebsrats gewünscht, z.B. Dokumentation in einer Anlage und/oder Bindung an das gegenseitige Einvernehmen
Der Betriebsrat hat das Recht, die Teams zu einem Austausch über die Erfahrungen
einzuladen.
Anmerkung: Eventuell sind an dieser Stelle noch weitere Punkte aufzuzählen.
Nach den Abschluss von fünf durchgeführten Projekten sowie auf Wunsch einer Seite findet ein gemeinsamer Erfahrungsaustausch zwischen Unternehmen und Betriebsrat statt. Bei dieser Gelegenheit werden insbesondere die folgenden Fragen erörtert:
Der Betriebsrat wird über alle Änderungen des Softwaresystems vor deren Freischaltung informiert. Bei dieser Gelegenheit beraten beide Seiten, ob die Regelungen dieser Vereinbarung eingehalten sind.
Macht der Betriebsrat geltend, dass durch eine geänderte Verfahrensweise oder durch Nutzung neuer Leistungsmerkmale der eingesetzten Software die Grundsätze und Regelungen dieser Vereinbarung nicht eingehalten sind, so hat er das Recht,
Kommt über dieses Regelungsbegehren keine Einigung zustande, so entscheidet eine gemäß § 76 Abs. 5 BetrVG zu bildende Einigungsstelle.
Diese Vereinbarung tritt mit Unterzeichnung in Kraft. Sie ist mit einer Frist von ...., frühestens zum .... kündbar. Im Falle einer Kündigung wirkt sie nach bis zum Abschluss einer neuen Regelung.
 |
Karl Schmitz, Januar 2017 |
 tse Hamburg | 538 / 579 |