1. Was machen Sie als PO genau?

Als Produktmanager von Mikogo, einer einfach zu bedienenden Desktop Sharing Software, bin ich für die Konzeption, Planung und die Koordination der Produktentwicklung verantwortlich. Um neue  Anforderungen an unsere Web-Kollaborations-Lösungen zu ermitteln, stehe ich im ständigen Dialog mit verschiedenen Stakeholdern und arbeite eng mit dem Development Team zusammen. Bei der Entstehung neuer Features legen wir viel Wert auf das frühe Einbeziehen von Kundenfeedback, um ein hohes Maß an User Experience sicherzustellen.

 2. Wie sind Sie PO geworden und überhaupt auf die Idee gekommen? Seit 10 Jahren bin ich in der Softwarebranche tätig und habe in einigen Projekten als Software Entwickler gearbeitet. Eines Tages bin ich eher durch Zufall auf Scrum gestoßen als mir eine Aufstiegschance ins Produktmanagement angeboten wurde. Seit dem gelungenen Einstieg in die agile Welt bin ich von dieser Herangehensweise überzeugt und auch in den nachfolgenden Unternehmen Scrum treu geblieben.  

3. Warum können Sie es empfehlen unbedingt PO im agilen Umfeld zu werden?

Scrum stellt dem PO geeignete Ansätze zur Verfügung, um die Produktentwicklung mit knappbemessenen Ressourcen auf den höchstmöglichen Kundennutzen auszurichten. Durch die konsequente Priorisierung der Anforderungen innerhalb des Product Backlog und die prägnante Erfassung von Kundenbedürfnissen in Form von User Stories, kann man allen Beteiligten die Zielsetzung und den zu erwartenden Geschäftswert auf anschauliche Weise vermitteln. Dank der engen Zusammenarbeit bei den Estimation Meetings tritt der PO in einen ständigen Dialog und Wissensaustausch mit dem Team, um die Machbarkeitsfrage für die vorbereiteten User Stories beantwortet zu bekommen. Die Resultate aus den Besprechungen bringen neben den eigentlichen Aufwandsschätzungen sehr oft weitere Vereinfachungen, Ergänzungen oder neue Erkenntnisse und Abhängigkeiten mit sich. Die Abstimmungen mit dem Team stellen einen der Dreh- und Angelpunkte für die Arbeit des PO dar – denn genau hier werden die Umsetzungspläne geschmiedet und nötigen Gestaltungsspielräume definiert, die bei der agilen Softwareentwicklung den besonderen Reiz ausmachen. Ein weiterer nicht von der Hand zu weisender Vorteil ist die Geschwindigkeit, mit der man dem Endkunden ein funktionierendes Stück Software zur Verfügung stellen kann. Im gleichen Zuge muss man auch bereit dazu sein, Lob und Tadel einzustecken. Im Gegensatz zu traditionellen Entwicklungsmodellen, bei denen man einen vorgegebenen Umsetzungsplan strikt verfolgt, ermöglicht das regelmäßige Abgreifen von Kundenfeedback es dem PO, das Produkt an den wachsenden Anwenderbedürfnissen auszurichten und auf lange Sicht am Markt erfolgreich zu platzieren.  

4. Welche Kompetenzen sollte ein PO aus Ihrer Sicht unbedingt haben?

Als PO muss man sich sehr stark mit seinem Produkt identifizieren können und eine hohe Eigenmotivation und Leistungsbereitschaft mitbringen. Man sollte ein guter Zuhörer sein, um sich ein klares Bild über die tatsächlichen Bedürfnisse und Anforderungen der Stakeholder verschaffen zu können. Einem PO sollte es auf keinen Fall an sozialen Kompetenzen und an Selbstbewusstsein mangeln. Gerade im Umgang mit seinen Mitarbeitern sollte man ein glückliches Händchen haben und in der Lage sein Andere führen und begeistern zu können. Der PO trägt die alleinige Produkthoheit – denn nicht umsonst wird man als single wringable Neck bezeichnet. Neben einem hohen Organisations- und Kommunikationsgeschick sollte man auch hart im Nehmen sein, da man des Öfteren in die Schusslinie der Beteiligten geraten kann und stets eine klare Linie vertreten können muss. Insbesondere wenn es darum geht die Prinzipien des Selbst- und Zeitmanagements vorzuleben, muss der PO allen ein Vorbild sein. Um sich mit den Teammitgliedern verständigen zu können, muss man nicht unbedingt ein Nerd sein, aber man sollte sich ein solides Fachwissen aneignen und über technisches Grundverständnis verfügen. Als PO muss man Kunden, Partnern und Stakeholdern gegenüber stets aussagefähig sein und darf die wesentlichen Ziele nicht aus den Augen verlieren. Das Profil eines hervorragenden PO wird durch Informiertheit über Trends, Mitbewerberprodukte und aktuelle Marktanforderungen abgerundet.

5. Mit welchen Herausforderungen haben Sie als PO jeden Tag zu kämpfen?  

Eine der großen Herausforderungen ist es, den alltäglichen Spagat zwischen der Steuerung der laufenden Entwicklungsaktivitäten und der Verfolgung der großen Visionen zu meistern. Man muss eben das Prinzip verinnerlicht haben, der Informationsflut Herr zu sein und auch zu bleiben. Mithilfe einer geeigneten Strategie muss der PO neue Kundenwünsche, Anmerkungen der Stakeholder und Fragen aus dem Team ordnen, um diese dann überlegt und mit der angemessenen Relevanz anzugehen.   Bei der Definition der Umsetzungsreihenfolge sollte der PO besonders Acht darauf geben, dass er ein ausgewogenes Urteil trifft und hinter diesem steht. Sinnbildlich gesprochen, fallen und steigen Wichtigkeit und Dringlichkeit von Anfragen in der Wahrnehmung der Stakeholder in manchen Fällen so sprunghaft wie sich die Aktienkurse an der Börse entwickeln. Der PO muss sich stets im Klaren darüber sein, dass alle Fäden bei ihm zusammenlaufen und er sich aufgrund der umfassenden Kenntnis der Produktanforderungen auf objektive Bewertungsmaßstäbe berufen muss, um darüber entscheiden zu können, welche Features als nächstes umgesetzt werden.

21 schlaue Fragen für Produktentwickler

Käufer und Nutzer differenziert betrachten

• Welche Kunden verwenden oder kaufen unser Produkt auf besonders ungewöhnliche Art und Weise?
• Gibt es Kunden, die deutlich mehr oder weniger Aufmerksamkeit von Vertriebs- und Servicemitarbeitern erfordern als der Durchschnitt?
• Welche Kunden verursachen besonders hohe oder besonders niedrige Kosten (Auftragseingang, Nachverfolgung, kundenspezifische Lösungen)?
• Gibt es eine Kundengruppe, deren Bedürfnisse wir auch dann noch erfüllen könnten, wenn wir unsere harten oder weichen Kosten um 25 Prozent senken würden?
• Welche Kunden investieren mindestens 50 Prozent des Produktpreises, um es ihren Bedürfnissen anzupassen?

Unerwartete Erfolge aufdecken

• Wer verwendet unser Produkt auf eine Weise, die wir gar nicht erwartet oder beabsichtigt hatten?
• Wer verwendet unser Produkt in überraschend großen Mengen?

Andere Unternehmen und Branchen beobachten

• Wer kämpft mit demselben Problem wie wir, aber aus einem anderen Grund? Wie gehen diese Unternehmen das Problem an?
• Welche radikalen Erfolge bei Effizienz oder Wirtschaftlichkeit haben wir erzielt, die auch in anderen Branchen nützen?
• Welche Informationen über Kunden und Produktverwendung fallen als Nebenprodukte unseres Geschäftes an, das wir nutzen können, um ein anderes Geschäft radikal zu verbessern?

Hindernisse für die Kundenbindung analysieren

• Was ist das größte Ärgernis beim Kauf oder Gebrauch unserer Produkte?
• Welche spontanen Verbesserungen haben Kunden an unserem Produkt vorgenommen?
• Für welche unserer Kunden eignet sich das Produkt am wenigsten?
• Für welche Anwendungsbereiche eignet sich unser Produkt am wenigsten?
• Welche Kunden bedient die Branche bewusst nicht und warum?
• Welche Kundengruppen wäre richtig groß, wenn wir ein ganz bestimmtes Hindernis aus dem Weg räumen könnten, an das wir bisher noch nicht gedacht haben?

Sich eine perfekte Welt vorstellen

• Was würden wir anders machen, wenn wir vollständige Informationen über Käufer, Anwendungsbereiche, Vertriebskanäle und so weiter hätten?
• Wie würde sich unser Produkt ändern, wenn es auf die Bedürfnisse aller Kunden zugeschnitten würde?

Prämissen für Prozesse und Produkte überdenken

• Welche Technologien, die in unseren Produkten eingesetzt werden, haben sich seit der letzten Produktionsüberarbeitung am stärksten verändert?
• Welche Technologien, auf denen unsere Produktionsprozesse beruhen, haben sich seit der letzten Überarbeitung unseres Produktions- und Vertriebssystems am stärksten verändert?
• Welche Kundenbedürfnisse verändern sich am schnellsten? Wie werden sie in fünf Jahren aussehen?

Da es meine ersten XP Days waren, habe ich mich vorab gründlich über die Veranstaltung und das Programm informiert und mich auf spannende Vorträge, aktuelle Themen der agilen Softwareentwicklung sowie auf interessante Gesprächspartner gefreut. Mein Ziel war es, einen tieferen Einblick in die agile Welt zu erhalten und mit neuen Ideen und Erkenntnissen zurückzukommen. Das ist mir dank der guten Veranstaltungsgliederung gelungen. Neben Präsentationen, interaktiven Vorträgen und Fishbowls boten mir die Pausen und das gemeinsame Abendessen in gemütlicher Atmosphäre eine gute Gelegenheit, mich in spannende Gespräche mit anderen Teilnehmern zu vertiefen.

In den Gesprächen und Vorträgen rückte das Thema Aufbau, Entwicklung und Coaching von agilen Teams stark in den Vordergrund. Dabei war deutlich zu erkennen, dass der Faktor Mensch einen großen Aspekt in der Softwareentwicklung einnimmt und auch limitierend wirkt, wenn Rollen- und Machtkonflikte innerhalb von Teams ausgetragen werden. Auch auf dem Weg zu einer agilen Organisation müssen viele Impediments aus dem Weg geräumt werden. Dazu war vor allem die Präsentation von Winald Kasch (FORTIS IT-Services GmbH „Wenn nur die Chefs nicht wären – Der Blueprint ein agiles Unternehmen“) sehr informativ, da in diesem Vortrag beispielhaft verdeutlicht wurde, wie wichtig es ist, dass die Führung ihren Teams Entscheidungsfähigkeiten gibt.

Bezogen auf zukünftige agile Vorgehensweisen und die neue Generation agiler Mitarbeiter, hat mir die Diskussionsrunde „Agil: Die nächste Generation“ von Holger Koschek (Holisticon AG) sehr gut gefallen.

Am zweiten Tag hat André Häusling eine Präsentation über das Thema „Erfolgreich mit Scrum – Einflussfaktoren im Personalmanagement“ gehalten und mit vielen Beispielen erläutert, wie Personalauswahl, -entwicklung, Performance Management, Vergütung und Führung in agilen Organisationen aussehen können. Anhand der Nachfragen wurde deutlich, wie wichtig es ist, dass sich der Human Resources Bereich auf agile Teams einstellt. Angefangen bei der Suche nach agilen Mitarbeitern bis hin zur Vergütung der Teams, sollte auf ein agiles Mindset zurückgegriffen werden, um dieses erfolgreich im Unternehmen zu etablieren.

Insgesamt war es eine gelungene Veranstaltung und ich bin sehr gespannt, was uns in den nächsten Jahren im agilen Umfeld erwarten wird.

Was machen Sie als PO bei Xing genau?

Als Product Owner Mobile verantworte ich den mobilen Auftritt von XING. Konkret entwickeln wir die XING-Apps für iPhone und Android sowie die mobile Website unter http://touch.xing.com inhouse. Darüber hinaus betreue ich noch die Entwicklung der BlackBerry-App und begleite die Entwicklung der XING-App für Windows Phone 7, die von einer externen Agentur bzw. einem Partner entwickelt wird. Insgesamt machen die mobilen Plattformen schon ungefähr 20% des gesamten XING-Traffics aus, mobiles Netzwerken ist auch im geschäftlichen Kontext immer relevanter.

Wie sind Sie PO geworden und überhaupt auf die Idee gekommen?

Ich bin seit über 10 Jahren als Produktmanager tätig. Vor zwei Jahren entschied sich mein damaliger Arbeitgeber glücklicherweise für agile Softwareentwicklung. Seither arbeite ich in der Rolle als Product Owner.

Warum können Sie es empfehlen unbedingt PO im agilen Umfeld zu werden?

Im agilen Umfeld werden Kompetenzen und Verantwortung in schlanken Teams zusammen gebracht. Die Teams organisieren sich selbst mithilfe weniger Regeln und geringem bürokratischen Aufwand.  In einem agilen Team hat man die Möglichkeit, den Software-Entwicklungsprozess flexibler und schlanker zu gestalten. Man arbeitet idealerweise enger am Kunden und auch enger innerhalb des Teams zusammen. Am Ende des Tages ist man in der Lage, schneller bessere Software von engagierteren Mitarbeitern zu entwickeln.

In meiner Rolle als PO im agilen Umfeld gefällt mir insbesondere der ständige und enge Kontakt mit den Entwicklern und den weiteren Teammitgliedern. Missverständnisse und Detailfragen können schnell beseitigt oder geklärt werden.

Welche Kompetenzen sollte ein PO aus Ihrer Sicht unbedingt haben?

Ein Product Owner sollte Leidenschaft und Begeisterung für sein Produkt mitbringen. Darüber hinaus  sollte man als Product Owner  in der Lage sein, Menschen zu begeistern und zu führen. Kommunikation ist das A und O. Zum Einen das Kommunizieren mit dem Team, was auch ein grundlegendes technisches, fachliches oder inhaltliches Verständnis voraussetzt, um wirklich ernst genommen zu werden. Zum Anderen das Kommunizieren mit diversen Stakeholdern insbesondere dem Management.

Außerdem ist Entrepreneurship, unternehmerisches Denken, sehr wichtig: immer die Strategie im Auge zu behalten, ein gutes Zahlenverständnis zur Analyse der Produktperformance gehören genauso dazu, wie Kenntnisse über Marketing- und Verkaufsmöglichkeiten. Außerdem gehört zum Know-how eines guten Product Owners, dass er sein Produkt in- und auswendig kennt, ein klares Verständnis von den Kundenbedürfnissen hat und den Markt und Wettbewerb sowie die Ziele nicht aus dem Auge verliert.

Mit welchen Herausforderungen haben Sie als PO jeden Tag zu kämpfen?

Jeden Tag gilt es herauszufinden, was sich die Nutzer des Produkts wünschen. Die eigenen Ideen sowie der Input der Kunden und der Stakeholder müssen täglich bewertet, verworfen oder berücksichtigt werden. Am Ende muss man selber entscheiden, was als nächstes umgesetzt wird und das dann auch vertreten. Für mich ist dies oftmals die größte Herausforderung. Man kann selten allen Leuten gerecht werden und es wird oftmals verlangt, dass man Entscheidungen ausgiebig rechtfertigt, noch bevor der Erfolg abgewartet wird.

Ich arbeite nun seit 4 Jahren als ScrumMaster in einem internationalen HealthCare IT Unternehmen und habe mich dabei die vergangenen 2 Jahre mehr und mehr zu einem Agile Coach entwickelt. Während die Rolle des ScrumMasters an sich relativ leicht in Worte zu fassen ist, nimmt man zumindest die Aufgaben welche er laut ‚Drehbuch’ übernimmt, so wird es mit dem Agile Coach schon etwas aufwändiger. Wobei ich eigentlich der Meinung bin, dass sich der natürliche evolutionäre Prozess eines ScrumMasters nahezu ‚zwangsläufig’ in die Richtung eines Agile Coaches fortsetzt. Wohlgemerkt als evolutionären Prozess gesehen. Dies muss jedoch nicht wirklich ‚zwangsläufig’ der Fall sein! Bei mir war es so. Neben den Aufgaben als ScrumMaster habe ich mich mehr und mehr mit weiteren Themen des Agilen Umfeldes beschäftigt, angefangen mit Kanban, TDD oder XP sowie Coaching an sich. Bewusst entschieden Agile Coach zu werden habe ich mich eigentlich nicht. Vielmehr hat mich meine eigene Einstellung, Interesse sowie meine Aufgaben in diese Richtung gelenkt.

Die Rolle des Agile Coach besteht eigentlich aus der Verbindung mehrerer unterschiedlicher Rollen und genau dieses Konstrukt lässt bereits einen Rückschluß auf einige Anforderungen an diesen zu. Neben hoher Flexibilität und einem breiten Fachwissen im Themenbereich ‚Agile’ kommt es auf Kommunikationsstärke, Authentizität, Offenheit, Empathie und Teamfähigkeit an. Um die wichtigsten Eigenschaften eines Agile Coaches kurz zu beschreiben.

Zu den Basis Aufgaben, welche mit unterschiedlichem Schwerpunkt belegt sein können gehören in erster Linie die Bereiche Coaching, Facilitating, Teaching, Mentorig, Transformation Mastery, Business Mastery, Technical Mastery sowie Agile- Lean Practitioning. Zu jedem einzelnen Punkt genau zu beschreiben was diesen Umfasst würde wohl eher ein Buch als einen BlogArtikel in Anspruch nehmen. Und es gibt viele Kollegen aus dem agilen Umfeld welche dies auch tun. Wie man jedoch bereits an diesen Schwerpunkten sehr gut erkennen kann sind die täglichen Aufgaben so vielfältig und different, dass einem eigentlich nie langweilig wird.

Als ScrumMaster betreue ich direkt zwei Teams was an sich schon eine Vollzeitbeschäftigung ist. Angefangen vom Facilitieren der ScrumMeetings bis über den Kontaktaufbau und dessen -haltung zu verwandten Teams mit denen man häufiger Zusammenarbeitet. Darüber hinaus ein Coaching der ProductOwner, des Managements, das Abstimmen und Organisieren mit anderen ScrumMastern und ‚Agilos’ bis hin zur Lobbyarbeit, EinzelCoaching oder auch als Vertrauensperson ergibt sich ein breites Spektrum an täglichem Doing. Natürlich fällt dies nicht alles auf einen einzigen Tag an dem man alle diese Tätigkeiten durchführt.

Neben all diesen Bereichen ist jedoch ebenfalls eine ständige Bereitschaft erforderlich sich weiterbilden zu wollen, neugierig zu sein, Agile Communitys außerhalb desArbeitgebers zu besuchen, sich austauschen oder auf Konferenzen auch mal einen eigenen Vortrag zu halten.

Bei all diesen Tätigkeiten muss ein Agile Coach schon sehr aufpassen dass er sich selbst nicht ‚über-committed’. Die Gefahr hierzu ist groß weshalb es Sinn macht, dass man als Coach auch selbst Coaching von anderen Coaches in Anspruch nimmt. Nicht zuletzt um seine eigene Arbeit zu reflektieren sondern auch um nicht die Balance zu verlieren welche man selbst in der gesamten Organisation versucht seinen Kollegen nahe zu bringen.

Zunächst einmal sollte ein Anschreiben kurz und knackig sein – ein Umfang von einer Seite reicht allemal. Die Kunst hierbei ist es, den Arbeitgeber mit wenigen Sätzen zu überzeugen und deine Motivation, Begeisterung und ggf. Erfahrung mit Scrum rüberzubringen.

Ein gelungenes Anschreiben sollte die folgenden Aspekte enthalten:

• Empfängeradresse mit Name des Ansprechpartners
• Eigene Kontaktdaten
• Ort- und Datumsangabe
• Betreffzeile ohne das ausgeschriebene Wort „Betreff“
• Anrede mit Nennung des Ansprechpartners
• Brieftext
• Grußformel
• Unterschrift

Im Folgenden möchte ich näher auf einige oben genannte Aspekte eingehen.

Das Anschreiben sollte möglichst an einen konkreten Ansprechpartner gerichtet sein. Ist kein Name eines Ansprechpartners bekannt, so lässt sich dieser häufig problemlos durch ein kurzes Telefonat herausfinden. Auf diese Weise zeigst du dem Personalverantwortlichen des Unternehmens auch, dass du dich wirklich für den Job interessiert.

Bei den Angaben der eigenen Kontaktdaten empfiehlt es sich natürlich eine Telefonnummer anzugeben unter der du erreichbar bist. Es macht also Sinn neben der Festnetznummer auch eine Handynummer anzugeben.

Der Betreff sollte präzise formuliert sein und Bezug auf die Position nehmen, auf die du dich bewirbst. Wenn möglich sollte herausgestellt werden, wo du die Stellenausschreibung gefunden hast bzw, wie der Kontakt zustande gekommen ist.

Wichtig ist, dass das Anschreiben auch für Fachfremde verständlich ist, da Mitarbeiter der Personalabteilung häufig kein fachliches Know-how im Scrum Bereich haben. Dennoch sollte es sich von anderen Anschreiben abheben – Also nicht die üblichen Floskeln verwenden, die der Personalverantwortliche bereits in und auswendig kennt. Das Anschreiben sollte nicht nur auf die individuelle persönliche Situation, sondern auch auf die Stelle, auf die du dich bewirbst, abgestimmt sein.

Gerne schauen wir auch über Dein Anschreiben drüber, um Dir ein individuelles Feedback zu geben

 2. Wie bist Du Scrum Master geworden und überhaupt auf die Idee gekommen?

Nach meinem  Studium begann ich als  Softwareentwickler zu arbeiten, von Agilität, Scrum, Kanban und dergleichen hatte ich noch nie etwas gehört.  Ich interessierte mich aber schon länger dafür, welche Prozesse bei der Softwareentwicklung ablaufen, und welche Werte dahinterstecken.  Nachdem ich dann  eine Zeit lang als „Wasserfall“-Projektmanager gearbeitet hatte, wurde mir die Ineffizienz meiner  Rolle am eigenen Leibe bewusst.  Als ich mich über Agilität und Scrum  informierte, konnte ich mich direkt mit der Rolle als ScrumMaster identifizieren.  Glücklicherweise stellte meine damalige Firma daraufhin den Entwicklungsprozess auf Scrum um, und ich beschloss,  mich als ScrumMaster  zur Verfügung zu stellen. Ich bin froh, diese Entscheidung getroffen zu haben, und jeder neue Tag bestätigt mich darin, dass diese Rolle das richtige für mich ist.

3. Warum kannst Du es empfehlen unbedingt Scrum Master im agilen Umfeld zu werden?

Der wichtigste Grund: Wenn man  in einem komplett agilen Unternehmen wie der iDev GmbH arbeitet, in dem alle die gleichen Ziele verfolgen und den gleichen Werten verbunden sind, dann macht das einfach Spaß. Durch die Rolle des ScrumMasters hat man dann die Möglichkeit, erkannte Impediments schnell zu lösen sowie die verschiedenen Prozesse in den Teams und im Unternehmen ständig hinterfragen und optimieren zu können. Wenn man dabei die richtigen Moderations- und Change Management-Werkzeuge zur Hand hat,  dann  ist es möglich,  kleine wie große Änderungen in einer Art und Weise durchzuführen, dass alle im Unternehmen effizienter und zufriedener arbeiten können.

 4. Welche Kompetenzen sollte ein ScrumMaster aus Deiner Sicht unbedingt haben?

Am wichtigsten finde ich die sozialen Kompetenzen, so sollte ein guter ScrumMaster  eine ausgeprägte Organisations- und Kommunikationsfähigkeit haben.  Außerdem sollte er die Prinzipien des „Servant Leadership“ verinnerlicht haben,  um  in der täglichen Arbeit immer einen Weg zu finden, zu führen, ohne zu bestimmen. Gerade wenn man in Teams arbeitet, die schon Erfahrung mit Scrum haben und die Grundlagen gut beherrschen, wird diese Fähigkeit immer wichtiger.

Im Gegensatz zu einigen anderen Scrummern  finde ich es aber auch wichtig, einen gewissen technischen Hintergrund zu haben.  Das gibt dem ScrumMaster einerseits die Erfahrung und Sicherheit, dass agile Techniken wie  XP, CI und TDD tatsächlich sinnvoll sind. Andererseits hat man ein besseres Standing dem Entwicklungsteam gegenüber, wenn es z.B. darum geht, Fragen zur Softwarequalität oder der Definition of Done zu klären. Das bedeutet natürlich nicht, dass der ScrumMaster  mit in den Entwicklungsprozess an sich involviert sein sollte. Mit dieser unheilvollen Doppelrolle hatte ich selbst  jahrelang zu kämpfen, bevor ich die Möglichkeit bei der  iDev GmbH bekommen habe, meine volle Aufmerksamkeit auf die Rolle des ScrumMasters zu richten.

Nicht zuletzt  sollte jeder ScrumMaster in der Lage zu sein „über den Tellerrand“ zu gucken.  Das Scrum-Framework liefert oftmals nur einen (wenn auch guten)  Einstiegspunkt,  um im Laufe der Zeit  immer mehr in die Welt der agile+ lean Softwareentwicklung abzutauchen. Hierbei sind es oftmals auch Einflüsse aus ganz anderen Bereichen wie Psychologie oder Soziologie, die sich in sinnvolle Prozesse umsetzen lassen.

 5. Mit welchen Herausforderungen als Scrum Master hast Du jeden Tag zu kämpfen?

Die größte Herausforderung ist es wohl, mit ständigen wechselnden Herausforderungen umgehen zu können. Als ScrumMaster ist man mit vielen verschiedenen Aspekten der täglichen Arbeit in einem Unternehmen konfrontiert. Dementsprechend gibt es immer wieder andere Punkte, bei denen Probleme auftauchen oder die es zu verbessern gilt. So kann es in dem einen Sprint meine  höchste Priorität sein, ständig auftretende  Störungen des Entwicklerteams von  außen zu verhindern. Im nächsten Sprint kann dies aber schon wieder ein völlig anderes Thema wie z.B.  die Organisation einer Scrum-UserGroup  oder das Implementieren eines firmenweiten Veränderungsprozesses sein. Es ist eine Notwendigkeit, jeden Tag immer wieder in verschiedene Richtung zu denken und sich in andere Perspektiven zu versetzen,  um Sachverhalte und Probleme ganzheitlich erfassen und verstehen zu können.

Nach meiner Zeit als Prozessbegleiterin habe ich eine neue Herausforderung gesucht. Ich war auf der Suche nach einem Job, bei dem kein Tag wie der andere ist, bei dem mir auf keinen Fall langweilig wird. Es sollte ein Job sein, bei dem ich mein Wissen einbringen darf, mit ganz vielen neuen und völlig unterschiedlichen Menschen zu tun habe, viel lernen kann und vor allem Verantwortung tragen darf.  Und als Sahnehäubchen, wenn ich als „ add on“ noch etwas hätte wünschen können: einen Job, bei  dem ich ganz viel reisen darf.

Und diesen Job habe ich gefunden. Den darf ich leben!

Ich bin Consultant bei bor!sgloger consulting.  Meine Kollegen und ich schulen Mitarbeiter, Führungskräfte und Interessierte im Framework Scrum und helfen damit unseren Kunden, Scrum selbständig einzusetzen.  Unsere Arbeit findet vor Ort, bei unseren Kunden statt. Heute Hamburg, morgen München und am Ende der Woche Frankfurt. Für uns der Alltag. Wir schauen uns die Situation genau an, coachen, beraten und zeigen vor allem das auf, was „weh tut“. Wir  reden niemandem nach dem Mund, sondern sagen offen unsere Meinung und legen den „Finger in die Wunde“.  Und das bei mittelständischen Unternehmen genauso wie bei Großkonzernen. Wir beraten individuell, ohne Standardkonzept, und orientieren uns an den Bedürfnissen des Unternehmens, seiner Kultur, an den beteiligten Menschen und den Bedingungen, die wir vorfinden. Somit stellen wir uns täglich der Herausforderung völlig neuer Situationen und finden dafür  (auch mal außergewöhnliche) Lösungen.

Unsere Arbeit findet somit sowohl strategisch als auch taktisch statt. Das kann einerseits  das Coaching der ScrumMaster sein, ein Daily einzuführen und nachzujustieren oder die Arbeit mit dem Management. Da Scrum nicht nur die „einfache“ Einführung eines Frameworks ist, sondern ein Change Prozess, der bis in die Organisation hinein Veränderungen mit sich bringt, gehört es selbstverständlich auch zu unseren Aufgaben diesen zu begleiten, zu steuern und alle betroffenen Mitarbeiter „abzuholen“. Aber auch über den Horizont zu schauen und intensiv mit Schnittstellen zu arbeiten.

Ein Consultant im agilen Umfeld zu sein bedeutet für mich, etwas zu bewegen, mit zu gestalten und Teil einer aktiven Community zu sein, die etwas voranbringt. Außerdem sehe ich mich als Ansprechpartner und Wissensvermittler für Kunden und solche, die es werden möchten.

Um diesen Job machen zu  können, muss man sowohl örtlich als auch geistig flexibel sein. Außerdem ist es es sehr wichtig, sich in unbekannten Umgebungen sicher bewegen zu können und auch mal einen „Sturm“ aushalten zu können. Die Kompetenzen werden durch ein Studium, Moderations- und Trainingsfähigkeiten abgerundet und wer viel Engagement und Fähigkeit zur Selbstmotivation mitbringt, wird es als Consultant leichter haben. Wenn man bereit ist viel zu geben, bekommt man auch sehr viel zurück.