kollaborativ gegen die silomentalität

geteiltes wissen und know-how ermöglichen innovativere zusammenarbeit

 

über kollaboration

Viele Kooperationen zwischen Unternehmen finden bis heute vornehmlich im Rahmen langjähriger Projektpartnerschaften statt. Innovation wird zumeist als unternehmensspezifischer und interner Prozess verstanden. Fluxdock wurde geschaffen, um diese Silo-Mentalität aufzubrechen und neue innovative Partnerschaften zu ermöglichen. 


Mehr lesen

project workspaces

Im laufenden Betrieb an einem firmenübergreifenden, kollaborativen und agilen Projekt zu arbeiten, stellt eine Herausforderung dar. Wir haben die Project Workspaces entwickelt, um für Teams einen ablenkungsfreien Ort zu schaffen, an dem sie sich auf ihr Innovationsprojekt konzentrieren können. 
 

Mehr erfahren

das physische FLUXDOCK

Das physische Fluxdock befindet sich im Dreispitz-Viertel von Münchenstein / Basel. Auf 1500 Quadratmetern kollaborativer Fläche arbeiten Unternehmen aus verschiedenen Branchen Seite an Seite und profitieren von der Expertise ihrer Nachbarn.


Ihr Arbeitsplatz

arbeitsweise


Fluxdock macht Scrum, Design Thinking und agiles Projektmanagement zugänglich und bietet seinen Kunden einfach zu bedienende Tools und Methoden. Während des gesamten innovativen Prozesses stehen wir mit unserer Erfahrung und Expertise zur Verfügung. Dennoch ist es hilfreich, einige Begriffe zu kennen, wenn es darum geht, in einem agilen Projekt zusammenzuarbeiten. Deshalb hier einige Erklärungen:


ROLLEN

Product Owner (PO)

Der Product Owner spielt eine zentrale Rolle im Projekt. Er ist die Schnittstelle zwischen dem Kunden und dem Team. Er vermittelt Vision, Ziel und Anforderungen des Projekts und ist dafür verantwortlich, dass das Team sie versteht und unterstützt. Er ist verantwortlich für die Formulierung des "Was" und des "Warum" (Ziele, Anforderungen und Gründe dafür). Er priorisiert die Anfragen, oft in Absprache mit dem Team.

Team

Das Team besteht aus allen Fachleuten, die für die Realisierung des Projekts benötigt werden. Es setzt die Anforderungen in der Reihenfolge ihrer Priorisierung schrittweise als Teil von Produkten, Konzepten oder Informationen im Allgemeinen um. Das Team ist verantwortlich für das "Wie" (z. B. technische Lösung, Software-Framework, der Weg) der Umsetzung von Anforderungen.

Scrum Master (SM)

Der Scrum Master ist verantwortlich für den optimalen Ablaufprozess des Projekts unter Berücksichtigung aller Bedingungen und immer in Absprache mit dem Product Owner und dem Team. Er coacht das gesamte Projektteam, beseitigt Hindernisse und optimiert kontinuierlich den Projektablauf.


WORKFLOW

Sprint

Planning

Im Planning einigt sich der Product Owner mit dem Team über die Sprintziele. Diese bilden in der Review am Ende des Sprints die Basis für die Beurteilung der Anforderungen. Diese Auswahl der am höchsten priorisierten und in ihrem Aufwand geschätzten Anforderungen bildet den Sprint Backlog. Die Teammitglieder entscheiden selbst, wie sie die geforderten Anforderungen umsetzen wollen und besprechen im Planning die gegenseitigen Abhängigkeiten und wie sie sich im Sprint organisieren.

Am Ende des Plannings wissen alle Teilnehmenden, zu welchen Sprintzielen sich das Team verpflichtet hat (Commitment), in welcher Form die Ergebnisse präsentiert werden sollen, warum die Sprintziele sinnvoll sind und welche Aufgaben erfüllt werden müssen, um diese Ziele zu erreichen.

Daily Scrum

Das Daily Scrum ist eine tägliche Besprechung des Teams mit maximaler Dauer von 15 Minuten. Jedes Teammitglied beantwortet die folgenden Fragen:

1. Was habe ich seit dem letzten Daily Scrum erledigt?

2. Woran arbeite ich bis zum nächsten Daily Scrum?

3. Gibt es Dinge, die mich an der Erledigung meiner Arbeit hindern?

Das Daily Scrum dient der Abstimmung der Teammitglieder untereinander. Nötige Absprachen finden im Anschluss mit den notwendigen Beteiligten statt. Der Scrum Master moderiert das Daily Scrum und kümmert sich im Anschluss um die Beseitigung allfälliger Hindernisse.

Review

Zum Ende jedes Sprints wird das Ergebnis in der Review durch das Team vorgestellt. Die einzelnen Teammitglieder berichten von ihren Erkenntnissen und Erfahrungen und präsentierten ausschliesslich fertige Resultate.

Das Team orientiert sich an den folgenden Fragestellungen:

1. Was haben wir geschafft?

2. Was haben wir nicht geschafft und weshalb nicht? (sachliche Beschreibung der Gründe des Nicht-Erreichens)

3. Was haben wir gelernt? (in Bezug auf das Produkt und dessen Entwicklung)

Der Product Owner prüft (idealerweise mit dem Kunden), ob das Sprint-Ergebnis seinen Anforderungen entspricht. Gemeinsam werden Erkenntnisse diskutiert und eventuelle Änderungen können in Form von Erweiterungen, Umpriorisierungen oder durch das Entfernen von Elementen des Product Backlogs als Grundlage für das nächste Planning im Backlog aufgenommen werden.

Die Review wird durch das Team gestaltet, der Scrum Master moderiert.

Retrospektive

In der Retrospektive wird der zurückliegende Arbeitsprozess mit dem Team betrachtet. In diesem Meeting reflektiert das Team zusammen mit dem Scrum Master den Prozess und die Zusammenarbeit im Team, mit dem Product Owner und anderen Beteiligten. Verbesserungsmassnahmen werden priorisiert und einem Verantwortungsbereich (Person, Team oder Organisation) zur möglichst zeitnahen Umsetzung zugewiesen. Die Erkenntnisse und Verbesserungsmassnahmen, die das Team selbst betreffen, sollen direkt im nächsten Sprint umgesetzt werden.

Ziel ist es, den vergangenen Sprint zu beleuchten und daraus zu lernen, um den bevorstehenden Sprint effizienter zu gestalten.

Die Retrospektive findet im Anschluss an die Sprint Review am Ende jeden Sprints statt.

Der Scrum Master bereitet die Retrospektive vor und moderiert diese.

Die Retrospektive orientiert sich an den folgenden Fragen:

1. What went well?  

2. Was haben wir gelernt?

3. Welche konkreten Verbesserungsmassnahmen gibt es?

4. Wer ist für diese Massnahmen verantwortlich?


ARBEITSMITTEL

Product Backlog

Der Product Backlog ist die Anforderungsliste des Kunden. Diese Liste wird vom Product Owner in enger Zusammenarbeit mit dem Kunden kontinuierlich weitergeführt, überprüft und neu priorisiert. Der Product Backlog ist die Grundlage für die Umsetzung des Projektes und beschreibt, was vom Team umgesetzt werden soll. Er ist kein abgeschlossenes Dokument und verändert sich mit Fortschreiten des Projektes.

Regelmässig werden die Elemente des Product Backlogs neu bewertet und priorisiert. Dabei können bestehende Elemente entfernt sowie neue hinzugefügt werden. Hoch priorisierte Anforderungen werden im Gegensatz zu niedrig priorisierten sehr detailliert beschrieben und dienen damit dem Team als Grundlage für das Erstellen des Sprint Backlogs.

Der Product Backlog ist somit keine To Do Liste, die in jedem Falle abgearbeitet wird, sondern stellt einen Pool an Anforderungen dar, die der Priorität nach abgearbeitet werden, solange die zeitlichen oder finanziellen Ressourcen vorhanden sind.

Zusammengefasst heisst dies:

  • Das Product Backlog enthält alle Anforderungen des Kunden an das Projektziel.
  • Die Anforderungen sind priorisiert gemäss Kriterien wie ROI, Risiko und genereller Wichtigkeit.
  • Die Anforderungen geben idealerweise Auskunft über das WAS, den Zweck der Anforderung und deren Zielpersonen. 
  • Das Product Backlog wird durch den Product Owner in digitaler Form geführt und angepasst. 

Sprint Backlog

Der Sprint Backlog wird vom Product Owner in einer ersten Version vorbereitet und innerhalb des Plannings mit dem Team besprochen. Das Team ergänzt die einzelnen Anforderungen mit Teilaufgaben, die zur Erfüllung der Anforderung führen. Der Sprint Backlog ist damit eine Verfeinerung des Product Backlogs und enthält alle Aufgaben, die notwendig sind, um die vom Product Owner vorgesehenen Sprintziele zu erfüllen. Bei der Planung des Sprints werden nur so viele Aufgaben eingeplant, wie das Team an Kapazität aufbringen kann, denn das Team verpflichtet sich im Planning zur Abarbeitung dieser Anforderungen (Commitment).

Zusammengefasst heisst dies:

  • Der Sprint Backlog ist die Verfeinerung des Product Backlogs. 
  • Der Product Owner erstellt eine erste Version des Sprint Backlogs für das Planning vor. 
  • Das Team verteilt die Aufgaben aus dem Sprint Backlog untereinander und arbeitet diese während des Sprints ab. 

Zur Gliederung und Weiterverfolgung der Tasks aus dem Sprint Backlog nutzt das Team ein Task Board (digital oder physisch).

 
 

valentin spiess | das interview

In diesem 23-minütigen Interview spricht der Initiator der kollaborativen Plattform Fluxdock über agile Methoden, Fluxdock und seine Arbeitsphilosophie.

 

das team

Jonas Gschwind, office management at Fluxdock AG

Jonas Gschwind | Studio Management

Jonas ist verantwortlich für das Studio- und Projektmanagement. Als gelernter Zimmermann studierte er Prozessdesign in Basel und Kulturmanagement in Luzern. Mitbegründer und Co-Leiter des Raums für Kultur Parzelle403.


Christian Hansen, concept and communication at Fluxdock AG

Joël Pregger | Assistant Studio Manager

Joël Pregger ist Community-Entwickler, Organisator und Unternehmer. Er ist Innovationsleiter bei INCH Partners und unterstützt Jonas beim Studio- und Office Management. 

Elias H. Schaefer, CEO of Fluxdock AG

Elias H. Schäfer | Verwaltungsrat

Elias studierte Internationale Beziehungen in St.Gallen und Genf. Von 2012 bis 2014 saß er im Grossen Rat der Stadt Basel. Seine Erfahrung als Repräsentant und sein breites Netzwerk machen ihn zum idealen kollaborativen Unternehmer. Elias ist Geschäftsführer der Fluxdock AG und von

 Basel.

besuchen sie uns 


Der Dreispitz ist Basels größtes Handels- und Dienstleistungsgebiet. Und mit rund 50 ha und mehreren hundert etablierten Firmen wohl auch eines der unübersichtlichsten, wenn man zum ersten Mal da ist.

Um sicherzustellen, dass Sie uns finden, haben wir ein kleines Reise-Tutorial erstellt. Wir freuen uns darauf, Ihnen einen Kaffee zu servieren und Ihnen das Fluxdock zu zeigen.


Auf Google Maps finden        oder        Anfahrtsplan Dreispitz