Whitepaper Medizintechnik 3 GRÜNDE FÜR AGILE PRODUKTENTWICKLUNG IN DER MEDIZINTECHNIK

Transkript

1 Whitepaper Medizintechnik 3 GRÜNDE FÜR AGILE PRODUKTENTWICKLUNG IN DER MEDIZINTECHNIK An geradezu revolutionären Ideen hat es der Medizintechnik im deutschsprachigen Raum noch nie gefehlt. Der Kostendruck im Gesundheitssektor und neue internationale Mitbewerber am Horizont zwingen aber auch diese ohnehin hoch innovative Branche in immer kürzere Entwicklungszyklen. Vielen Unternehmen stellt sich die Frage, wie die Produktentwicklung im Rahmen der geltenden Bestimmungen schneller und günstiger werden, aber trotzdem qualitativ hochwertig bleiben kann. Agile Entwicklungsframeworks wie Scrum sind darauf eine Antwort. Die Medizintechnik ist europaweit die mit Abstand innovativste Wirtschaftsbranche: Von insgesamt im Jahr 2012 beim Europäischen Patentamt angemeldeten Patenten stammten aus dem Bereich der Medizintechnik, die sich im Anmelderanking damit einmal mehr an die Spitze gesetzt hat. 1 Trotz der Konjunkturkrisen der letzten Jahre konnte die stark klein- und mittelständisch strukturierte Medizintechnik kontinuierliche Wachstumsraten verzeichnen, was wohl auch dem Umstand geschuldet ist, dass die Vertreter deutscher medizintechnischer Unternehmen Produktinnovation als wichtigstes Investitionsmotiv betrachten. 2 Rund neun Prozent des Umsatzes fließen wieder in Forschung und Entwicklung zurück, der Umsatzanteil von Produkten, die jünger als drei Jahre sind, liegt bei über 30 Prozent. 3 Dabei stehen nicht Updates oder Weiterentwicklungen im Vordergrund: Fundamentale Innovation ist die Grundhaltung dieses Industriezweigs. Dennoch steht diese Branche vor größeren Herausforderungen denn je: STEIGENDE GESUNDHEITSKOSTEN Das Gesundheitswesen ist einer jener Budgetposten, der die Haushalte europäischer Staaten am meisten belastet. Manche argumentieren, dass auch High-Tech-Medizin ein Kostentreiber ist, allerdings ist das eine einseitige Betrachtung. Schwerer zu belegen ist natürlich, wie viele direkte und indirekte Kosten innovative Medizintechnik einspart zum Beispiel durch schnellere und wirksamere Behandlung der Patienten. Paradoxerweise ist in der Medizintechnik laufende Innovation also auch deshalb notwendig, um Einsparungspotenziale zu schaffen. SPARMASSNAHMEN wirken sich direkt auf das Beschaffungsverhalten im Gesundheitssektor aus. Die Entscheidung, ob ein Gerät beschafft wird und, wenn ja, welches, liegt zunehmend in der Hand von Einkaufsabteilungen, weniger in der Hand der direkten Anwender wie Ärzte, Pflege- und Laborpersonal Wirtschaftlichkeit ist das schlagende Argument, darf aber nicht zu Lasten der Anwenderfreundlichkeit gehen. 1 Europäisches Patentamt 2 Siehe DIHK-Report Gesundheitswirtschaft, Herbst Siehe Medizintechnik in Deutschland, Studie des HWWI im Auftrag der HSH Nordbank AG, März 2013 BORIS GLOGER Whitepaper Medizintechnik 1/10

2 INTEGRIERTE ENTWICKLUNG Hard- und Software sind in den meisten Bereichen der Medizintechnik nicht mehr voneinander zu trennen. Innovative Produktentwicklung in der Medizintechnik bedeutet heutzutage vor allem innovative integrierte Produktentwicklung. REGULARIEN Beeindruckend ist die hohe Innovationsenergie der Medizintechnik vor allem unter dem Gesichtspunkt, dass kaum ein anderer Industriebereich derart vielen Regularien und Vorschriften unterliegt. Von der Entwicklung bis zur Zulassung muss ein medizintechnisches Produkt eine Vielzahl nationaler, europäischer und internationaler Regularien und Zulassungsverfahren überleben, deren Ziel natürlich in erster Linie die Sicherheit der Patienten ist. Notwendige klinische Studien sind eine zusätzliche hohe finanzielle Belastung. Unternehmen in der Medizintechnik haben daher umfangreiche Qualitäts- und Risikomanagementsysteme aufgebaut, die den Vorschriften Rechnung tragen sollen. Doch genau hier entsteht ein Konflikt zwischen Prozesskonformität, nötiger Dokumentation und einem schnellen Markteintritt. Schneller, günstiger und dabei ausnahmslos regelkonform so lässt sich die Herausforderung an die Medizintechnik also zusammenfassen. Wie können Unternehmen in der Medizintechnik unter diesen Bedingungen ihre innovativen Produkte dennoch schneller auf den Markt bringen? Wie kann die Produktentwicklung anwenderorientiert und dennoch kosteneffizient gestaltet werden, um den Einsparungsdruck von außen abzufedern? Ein Déjà-vu: Softwareentwicklung vor dem Agilitätssprung Vor rund 20 Jahren stand die Softwareindustrie vor ähnlichen Problemen wie die Medizintechnik heute. Entwickelt wurde meistens nach der schwerfälligen, sequenziellen Wasserfallmethode. Als Prozessverbesserungen gedachte Vorgehensmodelle und Standards wie CMMI und ISO 9001 verlängerten die Entwicklungszyklen zusätzlich und machten sie immer kostspieliger. Trotzdem wurde oft weit an den tatsächlichen Bedürfnissen der Anwender vorbeientwickelt, noch dazu in nicht zwangsläufig besserer Qualität. Schließlich war es die Unzufriedenheit der Softwareentwickler mit dieser Situation, aus der Ende der 1990er-Jahre agile Softwareentwicklungsmethoden entstanden. Eigentlich war es aber die Wiederentdeckung einer Vorgehensweise, die seit den 1940er-Jahren vor allem für die Entwicklung hochkomplexer Hardware wie etwa Kampfjets, das Mercury-Programm der NASA und später auch des Space Shuttle eingesetzt wurde also durchaus ein Modell für Industrien mit straffen Vorgaben und Reglementierungen. 4 Was damals als Iterative and Incremental Development (IID) begonnen hat, erlebt heute unter dem Namen Scrum ein Comeback. Festzuhalten ist also zunächst, dass Scrum nicht primär eine agile Softwareentwicklungsmethode ist, sondern ein Rahmen, der die Komplexität eines Produkts in überschaubare Zyklen zerlegt ob es sich dabei um Hardware, Software oder die Kombination von beidem handelt, ist völlig unerheblich. 4 Siehe dazu Craig Larman & Victor R. Basili: Iterative and Incremental Development: A brief history. In: IEEE Computer, Volume 36, Issue 6, June 2003, S BORIS GLOGER Whitepaper Medizintechnik 2/10

3 Agile Ansätze wie Scrum sind also besonders dort stark, wo es um echte Produktentwicklung geht wo neue Lösungen für alte Probleme gefunden werden müssen. Scrum in der Medizintechnik einzusetzen, ist daher beinahe eine logische Schlussfolgerung, denn Neuentwicklungen stehen im Mittelpunkt. Besonders in frühen Phasen eines Produktentwicklungsprojekts gibt es viele Unbekannte. Die Informationslage über Machbarkeit und Risiken verändert sich von Tag zu Tag und erst im Entwicklungsprozess selbst erweisen sich Wege als weiterführend oder als Sackgassen. Scrum schafft mit seiner transparenten und hoch adaptiven Natur den kontinuierlichen Abgleich zwischen Soll und Ist, zwischen Plan und Lieferung. Was Unternehmen in der Medizintechnik aber oft von Scrum abhält, sind zwei Fragen: Ist Agilität ein unternehmerischer Laissez-faire-Stil, bei dem jeder einfach macht, was er will? Ist agile Produktentwicklung mit den Regularien der Medizintechnik vereinbar? Agilität missverstanden Die meisten Bedenken bei der Einführung von Scrum in einem medizintechnischen Umfeld entstehen durch die falsche Interpretation des Agilen Manifests, das die Essenz agiler Entwicklungspraktiken auch von Scrum zusammenfasst. Was bedeuten die folgenden Sätze aber tatsächlich? Durch unsere Arbeit haben wir folgende Werte zu schätzen gelernt: Individuen und Interaktionen mehr als Prozesse und Werkzeuge Funktionierende Software mehr als umfassende Dokumentation Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlungen Reagieren auf Veränderung mehr als das Befolgen eines Plans Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, messen wir den Dingen auf der linken Seite größeren Wert bei. (Englische Originalversion auf Der springende Punkt ist: Hier wird keine Unterscheidung zwischen gut und böse getroffen. Es ist eine Gewichtung, um Entwicklungsprozesse zu beschleunigen. Übersetzt ließen sich die zentralen Sätze auch so formulieren: EIGENVERANTWORTUNG Der Nutzen von Prozessen und Werkzeugen hängt von den Fähigkeiten der Menschen ab, die sie einsetzen. Menschen können gemeinsam nur ein erfolgreiches Produkt erschaffen, wenn sie miteinander reden und in einem vorgegebenen Rahmen selbst Entscheidungen treffen dürfen, um ein Produkt besser zu machen. Das bedeutet nicht, dass Mitarbeiter den Rahmen von Scrum als Legitimation dafür nutzen können, plötzlich nur mehr das zu tun, wozu sie Lust haben. DOKUMENTATION Wird in Scrum nicht mehr dokumentiert? Dieser Satz des Agilen Manifests wird gerne bewusst falsch ausgelegt, weil niemand gerne dokumentiert. Fakt ist aber: Auch in Scrum ist zu dokumentieren, was dokumentiert werden muss und sinnvoll ist (aber keine Dokumentation nur um der Dokumentation willen) entweder durch das Scrum-Team selbst oder durch einen entsprechenden Support. Sei es wegen rechtlicher BORIS GLOGER Whitepaper Medizintechnik 3/10

4 Vorschriften, für die Vorlage bei Behörden oder um die Arbeit von anderen einfacher zu machen. Primär sollte sich ein Scrum-Team auf die Produktentwicklung konzentrieren, daher geht es um effiziente Dokumentation. ZUSAMMENARBEIT Scrum bezieht den Kunden bzw. Anwender von Anfang an in die Produktentwicklung ein zum Beispiel in Form der Reviews am Ende jedes Sprints. Im Mittelpunkt agiler Produktentwicklung steht der Nutzen für den Anwender und diesen kann man nur im ständigen engen Kontakt mit dem Kunden und dem Anwender schaffen. Die Regeln der Zusammenarbeit in einem Vertrag festzuhalten, ist sinnvoll. Verträge sollen aber kein Instrument sein, um sich gegenseitig über den Tisch zu ziehen. STÄNDIGE PLANUNG Ein Vorwurf an agile Methoden lautet oft, es werde nicht geplant. Das ist falsch: Tatsächlich wird ständig geplant. Richtig ist, dass zu Anfang eines Projekts weil gerade bei der Neuentwicklung eines Produkts faktisch unmöglich (auch im klassischen Projektmanagement) nicht jedes potenzielle Detail spezifiziert wird. Es wird ein grober Plan erstellt, um starten zu können. Dann wird regelmäßig nach jedem Sprint auf Basis der bisherigen Erkenntnisse die weitere Vorgehensweise für den nächsten Sprint geplant und die entsprechenden Planungsdokumente werden angepasst. Das heißt also: Neue Erkenntnisse (z. B. wenn sich eine Anforderung ändert) werden umgehend berücksichtigt. Damit wird auf Veränderungen sofort reagiert man schiebt diese Nacharbeiten also nicht an das Ende des Projekts, wo sie sich zu einem nicht zu bewältigenden Berg auftürmen. SCRUM Scrum ist ein Rahmenwerk für die iterative und inkrementelle agile Entwicklung, bei der ein Produkt in Zyklen von der Vision weg schrittweise verfeinert wird. Es wird also nicht versucht, das Produkt zu Beginn eines Projekts bis ins letzte Detail zu spezifizieren, da nicht alle Eventualitäten vorhersehbar sind. Um Komplexität zu reduzieren, arbeitet ein Scrum-Team in je maximal vierwöchigen Einzelschritten, Sprints genannt. Zu Beginn werden die wesentlichen Funktionalitäten festgelegt und dann in jedem Sprint auf Basis eines Feedbacks des Kunden bzw. Anwenders weiterentwickelt oder aber auch verworfen, wenn sie mehr sinnvoll sind. Anders als im klassischen Projektmanagement sieht der Kunde das Ergebnis also nicht erst am Ende der gesamten Entwicklung, sondern ist in jeden Entwicklungsschritt eingebunden. Die Organisationsprinzipien von Scrum: Kleine, selbstorganisierte und -verantwortliche, cross-funktionale Teams bestehend aus Scrum Master, Product Owner und Entwicklungsteam Arbeiten nach dem Pull-Prinzip: Das Entwicklungsteam entscheidet über die Menge der Funktionalitäten (die vom Product Owner nach dem Business Value priorisiert wurden), die es in einem Sprint entwickelt, und es entscheidet auch, wie es diese Aufgaben erledigt. Klar begrenzte zeitliche Intervalle (Timebox): Ziel ist es, die gewählten Funktionalitäten tatsächlich innerhalb des Sprints abzuarbeiten. Nutzbare Business-Funktionalität: Am Ende jedes Sprints muss das Team eine Lieferung erbringen, die den Standards, Richtlinien und Vorgaben des Projekts entspricht. BORIS GLOGER Whitepaper Medizintechnik 4/10

5 Diese Prinzipien allein machen aber nicht den Erfolg von Scrum aus. Wesentlicher Faktor ist die intensive Kommunikation: Die Teammitglieder stimmen sich in täglichen Kurzmeetings (Daily Scrum) über den aktuellen Stand der Arbeit ab. In Estimation Meetings arbeiten sie an einem gemeinsamen Verständnis über die zu entwickelnden Funktionalitäten und in den Sprint Plannings 1+2 wird konkretisiert, was wann und wie entwickelt wird. In den Reviews am Ende eines Sprints spricht das Team mit dem Kunden über die entwickelten Produktinkremente und in der Retrospektive hinterfragt das Team selbst seine Vorgehensweise, um sie ggf. zu verbessern. MEDIZINTECHNISCHE REGULARIEN UND DIE AGILE PRODUKTENTWICKLUNG Bedeutet Regulierung per se, dass die Produktentwicklung unter agilen Vorzeichen nicht möglich oder vielleicht gar nicht erlaubt ist? Die Antwort ist ein eindeutiges Nein. Weder die FDA noch die europäischen Richtlinien und Normen für die Herstellung von Medizinprodukten schreiben vor, welche Entwicklungsmethoden eingesetzt werden müssen. Die Association for the Advancement of Medical Instrumentation stellt in ihrem Technical Information Report TIR 45: dezidiert fest, dass neben anderen Lebenszyklusmodellen auf jeden Fall auch agile Methoden dafür geeignet sind, medizintechnische Software zu entwickeln. Natürlich stellen die Regularien Ansprüche an die Qualitätssicherung während des gesamten Entwicklungsprozesses, denn es geht schlussendlich um das Wohl der Patienten. Es wird aber dem einzelnen Unternehmen überlassen, mit welchen Verfahren es die Ansprüche der Validierung erfüllt, je nachdem, womit die Produktentwicklung am besten bewältigt werden kann. Laut des AAMI TIR 45:2012 legt sich die FDA in dieser Hinsicht nicht fest. Einzige Voraussetzung ist, dass alle nötigen Qualitätssicherungsmaßnahmen erfüllt und eingehalten werden. In puncto Dokumentation geht es der FDA also in erster Linie um das Festhalten dessen, was man tut und wie man es tut. Sie schreibt aber nicht vor, was wie zu tun ist: Based on the intended use of the safety risk associated with the software to be developed, the software developer should determine the specific approach, the combination of techniques to be used, and the level of effort to be applied. While this guidance does not recommend any specific life cycle model or any specific technique or method, it does recommend that software validation and verification activities be conducted throughout the entire software lifecycle. (General Principles of Software Validation; Final guidance for industry and FDA staff) The quality system requirements do not dictate the types of design process that a manufacturer must use. Manufacturer s should use processes best suited to their needs. However, whatever the processes may be, it is important that the design controls are applied in an appropriate manner. (Design Control Guidance for Medical Device Manufacturers) Die gleichen Freiheiten lässt auch die Prozess-Norm IEC Sie nennt unterschiedliche Lebenszyklusmodelle wie Wasserfall, inkrementell (für Produktweiterentwicklungen) und evolutionär (entspricht agilen Modellen) und weist auf ihre Vor- und Nachteile hin, schreibt aber kein Modell vor. Es heißt: 5 AAMI TIR45:2012: Guidance on the use of AGILE practices in the development of medical device software BORIS GLOGER Whitepaper Medizintechnik 5/10

6 Diese Norm schreibt dem Hersteller keine Organisationsstruktur vor oder welcher Teil der Organisation welchen Prozess, welche Aktivität oder welche Aufgabe durchführen soll. Diese Norm fordert nur, dass der Prozess, die Aktivität oder die Aufgabe durchgeführt wird, um die Einhaltung dieser Norm nachzuweisen. Diese Norm macht keine Vorgaben für die Bezeichnung, das Format oder den expliziten Inhalt der Dokumentation, die zu erstellen ist. Diese Norm erfordert eine Dokumentation der Aufgaben, aber die Entscheidung, wie diese Dokumentation gestaltet wird, wird dem Benutzer der Norm überlassen. Diese Norm schreibt kein spezifisches Lebenszyklus-Modell vor. Die Anwender dieser Norm sind verantwortlich für die Auswahl eines Lebenszyklus-Modells für das Software-Projekt und für das Abbilden der Prozesse, Aktivitäten und Aufgaben dieser Norm auf dieses Modell. Die wichtigste Feststellung lautet also: Aus Sicht der Regulatorien darf agil entwickelt werden. Wie kann das in der Praxis aussehen? Und was heißt das praktisch für die medizintechnische Produktentwicklung? Auch in der Medizintechnik bedeutet Scrum als Management-Framework für die Produktentwicklung zunächst: Zusammenarbeit in cross-funktionalen Teams. Diese Teams bekommen die vollständige Lösungsverantwortung. Voraussetzung dafür ist, dass sich diese Teams mit allen Constraints auskennen, in denen sich die Lösung bewegen muss sie müssen also die fachlichen Anforderungen verstehen, die Technologie beherrschen und die Vorgaben des Qualitätsmanagements kennen. Dieses Team sollte möglichst gemeinsam in einem Raum sitzen und eine klare Vorgabe bekommen, was in einer Iteration zu erreichen ist. Ausgehend von einer Produktvision und klaren Rahmenbedingungen (zum Beispiel die Regularien der FDA, Technologie und Sicherheitsaspekte) erarbeitet das Entwicklungsteam gemeinsam mit dem Produktmanagement die ersten funktionalen Anforderungen an das Produkt, die in einem Product-Backlog gesammelt werden. Sind genügend funktionale Anforderungen gesammelt, startet die Arbeit am ersten Feature. Während das Entwicklungsteam daran arbeitet, arbeitet ein weiterer Teil des Teams bereits an funktionalen Prototypen, die zeigen, wie die nächsten funktionalen Anforderungen in den weiteren Iterationen eingepasst werden könnten. Die Ergebnisse werden nach ein bis vier Wochen dem Kunden/Anwender präsentiert und die notwendigen Anpassungen vorgenommen. Die neu gewonnenen Erkenntnisse werden also wieder in die Entwicklung zurückgeführt. BORIS GLOGER Whitepaper Medizintechnik 6/10

7 Beispiel: Risikomanagement mit FMEA Vor der Auslieferung medizintechnischer Produkte ist eine Reihe von Planungen und Analysen durchzuführen, die der Zuverlässigkeit und Sicherheit des Produktes dienen sollen. In diese Kategorie fällt die FMEA (Failure Mode and Effect Analysis), in der potenzielle Fehlfunktionen des Systems sowie Maßnahmen zur Risikoreduktion identifiziert und bewertet werden. Wer die gängigen Scrum-Handbücher durchliest, wird die klassischen Instrumente des Risikomanagements darin nicht finden. Trotzdem gibt es keinen Ansatz, mit dem das Aufspüren von Hindernissen und Risiken sowohl in der Entwicklung als auch in der Projektsteuerung so konsequent verfolgt werden kann wie mit Scrum. Nur done ist done. Nehmen wir als Beispiel die Definition of Done (DoD): Dieses Artefakt legt verbindlich die Qualitätsanforderungen und den Fertigstellungsgrad entwickelter Funktionalitäten fest. Die Definition of Done ist ein K.-o.-Kriterium am Ende jedes Sprints: Nur die Storys, die die Vorgaben erfüllen, können als fertig gekennzeichnet und abgenommen werden. Das Einhalten der DoD verhindert zum Beispiel den Aufbau von technischer Schuld: Wer erst zum Schluss die ersten Integrationstests durchführt, wird nach der Entwicklung noch jede Menge zu tun haben. Eine FMEA lässt sich hervorragend in den Rahmen der Definition of Done integrieren. In einem aktuellen Projekt von Boris Gloger Consulting werden Geräte für die Laborautomatisierung entwickelt. Das Entwicklungsteam hat in seiner DoD festgelegt, dass jede konstruktive Änderung erst mit einer Dokumentation der potenziellen Risiken sowie der zu ergreifenden Gegenmaßnahmen abgeschlossen ist. Da das Team in zweiwöchigen Iterationen arbeitet, in denen Konstruktionsänderungen in kleinen Schritten abgeschlossen werden, ist es für die Mitglieder dieses Scrum-Teams zur Routine geworden, jede signifikante Entwicklungsstufe mit einer Risikobewertung und -steuerung abzuschließen. In herkömmlichen Projekten wurde das Risikomanagement erst angegangen, als die Entwicklung bereits abgeschlossen war. Dadurch konnten Risiken nur noch marginal eingedämmt werden. Jetzt ist es möglich, die Risikobrille von Beginn des Projekts mitten in der Entwicklung zu tragen. Mit Abschluss der Entwicklung ist das Risikomanagement bereits erledigt: Das Scrum-Team hat sich schließlich die ganze Zeit damit befasst. Und die Qualitätskontrolle? Wenn sich das Team selbst eine Definition of Done gibt und sich selbst kontrolliert: Wo ist in diesem Szenario Platz für die Qualitätsmanagement-Abteilungen? Ganz einfach: Ein/-e Mitarbeiter/-in der Qualitätssicherung wird in das Scrum-Team integriert. Er oder sie sorgt dafür, dass die gesetzlichen Anforderungen als Teil des Entwicklungsprozesses implementiert werden. Allerdings nicht mit dem erhobenen Zeigefinger links und der Checkliste rechts, sondern durch aktives Mitmachen, Anpacken und Vorzeigen, wie Risikomanagement funktioniert. Das ist eine Umstellung, aber mit der Zeit werden Kontrollinstanzen und ständiges Nacharbeiten überflüssig. Das Aufspüren der Risiken passiert in Echtzeit, von Sprint zu Sprint. BORIS GLOGER Whitepaper Medizintechnik 7/10

8 3 GUTE GRÜNDE FÜR SCRUM IN DER MEDIZINTECHNISCHEN PRODUKTENTWICKLUNG 1. Ständige Überprüfung der Regelkonformität Scrum ist also im Grunde ein Validierungsinstrument (Diagnosetool). Es fördert durch das Review nicht nur laufend Erkenntnisse über das Produkt selbst zutage, sondern stellt dabei gleichzeitig laufend die Frage, ob die Qualitätsvorschriften eingehalten wurden. Als Produkt- und Ergebnisverantwortlicher erkennen Sie sofort, ob Ihr Projektteam in die falsche Richtung gelaufen ist, und können gegensteuern. Sie erkennen umgehend, ob Anforderungen geklärt sind, ob das Entwicklungsteam diese Anforderungen umsetzt, ob die notwendige Dokumentation geschrieben wurde und ob das Gerät erfüllt, was es laut den Anforderungen tun soll. Scrum erzeugt für Sie die Sicherheit, ständig zu wissen, wo Sie stehen. 2. Schnelle Lieferung Nur mit agilen Entwicklungsmethoden sind die Forderungen nach schneller Lieferung bei gleichzeitiger Einhaltung von Normen und Standards heute erfüllbar. Das Projekt wird für alle Beteiligten, das Entwicklungsteam, aber auch für das Management vollkommen transparent in seinen Lieferungen. Änderungen können während der Laufzeit des Projektes leicht eingefügt werden. 3. Motivierte Mitarbeiter Cross-funktionale Teams alle an der Produktentwicklung beteiligten Mitarbeiter arbeiten Hand in Hand. Elektronik und Elektrik, Mechanik und Konstruktion, Softwareentwicklung und Mediziner. Sie alle sind in einem Team und wollen gemeinsam erfolgreich sein. Das gemeinsame Ziel eint das Team und fördert die Zusammenarbeit, Handovers werden reduziert und viel Zeit gespart. Mit Scrum starten: Was Sie bei der Auswahl eines Beraters beachten sollten Der Markt für die Organisations- und Produktentwicklung mit Scrum ist noch sehr jung, aber auch sehr attraktiv, weil sich die Vorteile weit über die Softwareentwicklung hinaus herumgesprochen haben. Im deutschsprachigen Raum gibt es derzeit noch selten wirklich spezialisierte Anbieter, die nicht nur auf Teamebene, sondern auch in skalierten Umgebungen mehr als fünf Jahre profunde Erfahrung mit Scrum vorweisen können. Noch weniger Erfahrung gibt es naturgemäß in der Medizintechnik, da diese Branche die agile Entwicklung erst vor kurzem für sich entdeckt hat. Viele Anbieter konzentrieren sich auf die bloße Implementierung des Scrum- Handwerks. Tatsächlich ist eine dauerhaft erfolgreiche Scrum-Implementierung die Aufgabe eines vorausschauenden Change-Managements. Scrum wirkt sich nicht nur auf die Zusammenarbeit in einzelnen Teams aus, auch an den Schnittstellen muss sie neu definiert werden. Genauso gehen Fragen der Führung und Selbstführung mit Scrum einher, die Wissen und Erfahrung im Umgang mit sozialer Dynamik brauchen. BORIS GLOGER Whitepaper Medizintechnik 8/10

9 Scrum ist also kein bloßes Add-on zum klassischen Projekt- oder Anforderungsmanagement, sondern eine eigenständige Disziplin. Agile Entwicklung denkt anders und handelt anders. Ihr Berater sollte sich nicht nur in Scrum und den notwendigen Entwicklungspraktiken auskennen und Erfahrungen aus anderen Projekten mitbringen, sondern vor allem in seiner eigenen Herangehensweise an ein Problem innovativ und agil sein. Hier unsere Checkliste für die Auswahl Ihres Beratungsteams: 1. Hat der Anbieter Kunden in verschiedenen Industrien beraten? 2. Wie viel Erfahrung haben die einzelnen Scrum Consultants? 3. Welche Rolle spielt der Anbieter in der agilen Community? 4. Haben die einzelnen Berater Erfahrung in der unternehmensübergreifenden Zusammenarbeit in einem agilen Kontext, zum Beispiel mit Zulieferern? 5. Kann Ihr Berater erfolgreiche Skalierungs-Projekte mit mehr als 60 möglicherweise sogar international verteilten Mitarbeitern vorweisen? 6. Ist Einheitlichkeit gewährleistet, weil alle Berater des Anbieters nach den gleichen Prinzipien arbeiten? 7. Wird Ihnen gesagt, was Sie hören wollen, oder schmerzen die Diagnosen manchmal? 8. Finden Sie den Anbieter zusammen mit seinen Kunden auf Konferenzen? 9. Können Sie sich bei anderen Kunden des Anbieters ansehen, wie Scrum in der Praxis funktioniert? 10. Sind die einzelnen Berater individuelle Persönlichkeiten, die sich für den Erfolg Ihres Unternehmens verantwortlich fühlen, sich in das Projekt einbringen wollen und können? Wie arbeitet Boris Gloger Consulting? Ihre Organisation ist heute schon einzigartig. Agile Produktentwicklung bewahrt diese Einzigartigkeit und rüstet Sie gleichzeitig für die zunehmende Dynamik des medizintechnischen Marktes. Unser Ziel ist es daher, uns überflüssig machen: Sie selbst und Ihre Mitarbeiter sind es, die Agilität leben müssen das können wir Ihnen nicht abnehmen. Aber wir bauen dafür das nötige Fundament: Von Anfang an schaffen wir unter allen Beteiligten von den Entwicklungsteams bis zum Management mit einfachen Bildern, Methoden und Verfahren Klarheit und ein gemeinsames Verständnis dafür, was Scrum für die Organisation bedeutet. Auf diesem gemeinsamen Verständnis etablieren wir Pilotteams mit Mitgliedern aus allen involvierten Bereichen und Abteilungen, die selbst entscheiden, wie sie mit den für die Implementierung von Scrum notwendigen Aufgaben beginnen und wie sie diese lösen wollen. Dazu gehört auch das Bilden eines ersten Scrum-Teams: Dieses Team durchläuft einige Sprints und sammelt dabei Informationen darüber, was wir gemeinsam noch verbessern können. Das Management ist von Anfang an dabei und wirkt aktiv mit. Es trifft notwendige Entscheidungen und lernt selbst, was es bedeutet, mit Scrum zu arbeiten. Diese Einbindung ist uns besonders wichtig, da sich das Vertrauen in die neuen Methoden auf allen Ebenen bilden muss. Bei einer Scrum-Implementierung werden Sie bemerken, dass sich im Laufe der Zeit die Tätigkeitsbilder der Mitarbeiter verändern aber nicht nach vorgeschriebenen Definitionen. Die Mitarbeiter erschaffen ihre neuen Rollen selbst. Schrittweise binden wir während der Arbeit mit Scrum passende Entwicklungspraktiken wie zum Beispiel Continuous Delivery ein, wir integrieren die Lieferanten und die gesamte Organisation beginnt, sich mit dem neuen Arbeiten zu beschäftigen. BORIS GLOGER Whitepaper Medizintechnik 9/10

10 Das ist ein möglicher Weg den genau für Ihr Unternehmen passenden Weg entwerfen wir gemeinsam entsprechend Ihrer Ausgangssituation und Ihren Zielen. Während des gesamten Umstellungsprozesses sind wir für Sie da. REDEN WIR ÜBER IHRE HERAUSFORDERUNG! Gegenseitiges Vertrauen ist die unbedingte Voraussetzung für einen so wichtigen Schritt wie den Wandel zu einem agilen Unternehmen. Wir kommen gerne zu einem unverbindlichen Beratungsgespräch bei Ihnen vorbei, zeigen Ihnen, wer wir sind, wie wir arbeiten und was wir für Sie tun können. Wir freuen uns darauf! Boris Gloger Consulting GmbH Lichtentaler Straße 7 D Baden-Baden T +49 (0) M +49 (0) F +49 (0) office@borisgloger.com Über die Boris Gloger Consulting GmbH Die Boris Gloger Consulting GmbH mit Sitz in Baden-Baden und Wien gehört in der DACH-Region zu den führenden Managementberatungen im Bereich des agilen Change-Managements und der agilen Produktentwicklung. Der Schwerpunkt liegt auf dem Management-Framework Scrum. Unternehmensgründer und Geschäftsführer Boris Gloger ist der weltweit erste Certified Scrum Trainer und hat über 5000 Manager bzw. Projektteams in diesem iterativen Vorgehensmodell geschult. Boris Gloger Consulting bietet darüber hinaus Training und Consulting für Fach- und Führungskräfte im Bereich des agilen Managements an. Die im Jahr 2008 gegründete Boris Gloger Consulting GmbH beschäftigt derzeit 20 Mitarbeiter und zählt unter anderem die Scout-Gruppe, Roche PVT, otto.de, Deutsche Post und die Ergo Direkt Versicherung zu ihren Kunden. Mehr Informationen unter BORIS GLOGER Whitepaper Medizintechnik 10/10