Willkommen in einer neuen Woche, liebe Community!
Es geht weiter mit einer neuen Frage der Woche:
Wieviel technisches Know-how braucht man in der Rolle eines agilen Wegbegleiters (Berater, Coaches, Scrum Master, …)? Was sind hier deine Erfahrungen und wie stehst du dazu?
Ich freue mich auf den Austausch mit euch!
Liebe Grüße, Dani
Ich denke es kommt immer auf den Context drauf an.
In meinem aktuellen Projekt bin ich als PO in einem sehr technischen Context unterwegs. Ohne dass ich die technischen Zusammenhänge verstehe, wäre es für mich teilweise sehr schwer vernünftig zu priorisieren.
Allgemein hilft ein gewisses technisches Verständnis um zu verstehen worüber die Devs so reden. Selber Code schreiben, ist aber aus meiner Erfahrung heraus nicht notwendig. Code schreiben zu können hilft aber manchmal, wenn man ein kleines Skript baut, welches einen für eine bestimmte Aufgabe hilft, aber jetzt nichts mit dem Produkt selber zu tun hat.
Hallo,
es ist auf jeden Fall von Vorteil, wenn man ein technisches Hintergrundwissen hat. Das ist hilfreich, um den Diskussionen im Team folgen zu können und sich selbst eine Übersicht zu verschaffen.
Es muss aber kein spezielles Know-How der eingesetzten Tools oder Programmiersprachen sein. Die Umsetzung kann das Team besser 
Liebe Grüße
Manfred
Hi,
also programmieren muss man nicht können. Aber man sollte schon die grundlegenden Konzepte einer Programmiersprache kennen. Also ist es eine Interpretersprache, wird der Code kompiliert, wie nah ist der Code an der Maschine dran usw. Ist es eine Desktop-Programmiersprache, ist es eine Web-Programmiersprache oder vielleicht beides?
Das macht es einfacher, die Stories zu erstellen und auch die Aufwände richtig einzuschätzen.
Viele Grüße
Peter
Hallo zusammen,
Interessante Frage und Danke dafür! Ich bin als Berufswechslerin gerade daran gescheitert, einen Job als Junior/Proxy Scrum Master zu erobern und zwar mehrfach auch mit der Begründung, ich hätte kein IT-Knowhow , würde die Devs nicht verstehen (die andere Begründung für Absagen war mangelnde Berufserfahrung in this role…).
Lehne ich mich zu weit aus dem Fenster wenn ich behaupte, es ist ein Unterschied, in welcher Rolle ich mich befinde, PO versus SM?
Und sind die genannten Kompetenzen nur durch Studium und jahrelange harte Arbeit zu erlangen oder vielleicht doch auch on-the-job mit Lektüre und der einen oder anderen Situation des kollegialen Austauschs zu erreichen?
Hey ho, guten Morgen!
Danke schonmal für eure Antworten. Ich kann jeden Beitrag selbst total gut nachvollziehen. Ich würde sagen, dass es auf das Projekt ankommt. Ich hatte das Glück in meiner Vergangenheit ein paar agile Teams oder Projekte in verschiedenen Rollen führen zu dürfen, die gar nichts mit Software / IT zu tun hatten. Das war mega spannend und faszinierend zu erarbeiten, welche agilen Methoden richtig zu funktionieren und wo es hakt.
In allen meinen bisherigen Projekten war es so, dass das Kernthema nicht zwingend meine Fachlichkeit war. Ich habe mich reingearbeitet, so dass ich z.B. diverse Backends bedienen konnte oder ein Stück weit die Entwickler verstehen konnte. Genauso in den Nicht-IT Projekten und Teams. Meist war ich in der Scrum Master Rolle oder Projektleiterin oder Teamlead (alles Entwicklungswege der Rollen, usw.). Mir war es immer wichtig die Sprache der Kunden zu verstehen und die des Teams und die Brücke dazwischen abbilden zu können. Mein Gefühl war zusätzlich immer, dass die Teams mehr und mehr in ihre Sicherheit kamen und auf ihre Fachlichkeit vertraut haben, wenn ich ihnen in diesem Punkt nicht helfen konnte (das bezieht sich gerade auf meine alte Teamlead - Rolle). Ich habe sie dann eher aus Coaching-Sicht unterstützt und am Ende lief das - nach meinem Empfinden - richtig gut; im Sinne von: sie haben sich getraut ihre Fachlichkeit zu zeigen, dafür einzustehen, usw.
Ich glaube daher, dass es viele verschiedene Möglichkeiten und Wege gibt und es immer auf den Kontext ankommt, was es in den Konstellationen braucht. Daher mag ich da gerne frei denken.
Aus meiner Erfahrung her kann ich sagen, dass meine ganzen verschiedenen Konstellationen und Erlebnisse für ein gutes Repertoire gesorgt haben, würde aber auch da nicht sagen, dass es nur darauf ankommt. Vieles kann man sich aneignen, vermutlich hängt es davon ab, wie agil man selbst ist - wenn man dafür ein gutes Gespür hat, kann man sicherlich auch noch recht frisch andere sinnvoll unterstützen.
Hi,
tl;dr:
Meiner Meinung nach
Die lange Version:
Wir haben eine Scrum Masterin in einem Team aus SAP-Modulbetreuern und ABAP-Entwicklern. Sie selber hatte überhaupt kein technisches Know-How und dies waren obendrein ihre ersten Teams.
Sie hatte sich ebenfalls Sorgen gemacht, ob sie hier gut genug helfen könnte.
Spoiler: Sie kann und sie konnte. 
Gut war, dass sie schnell ein Gefühl für das Team und deren Mitglieder aufgebaut hat. Stellenweise war es sogar hilfreich, dass sie kein Know-How mitgebracht hat. So konnte sie ungehindert “doofe” Fragen stellen - welche sich dann durchaus häufiger als alles andere als doof heraus gestellt hatten.
Bei einem PO sehe ich das ähnlich. Er muss sich mit dem Produkt und der Branche auskennen. Wenn dies technische Verständnis voraussetzt, braucht er es natürlich.
Ansonsten ist es mitunter eher störend, da er ohne technisches Wissen auch schlechter in Lösungen denken kann.
Wenn ich z.B. PO für ein Online-Versicherungsvergleich bin, sollte ich mich mit Versicherungen und den Kundenwünschen auskennen. Nicht mit Node.js 
In dem gleichen Team von oben hatten wir eine PO aus dem Fachbereich. Null Kenntnisse im Customizing und ABAP-Entwicklung, jedoch top in den Prozessen. Sie hat einen super Job als PO hingelegt.
Beide haben in kurzer Zeit die “Sprache” der Devs ausreichend schnell gelernt.
Ich habe jetzt schon häufiger gehört, dass Firmen Neueinsteigern keine Chance geben. Unsere Scrum Master Einsteiger kamen teilweise mit Null Scrum Wissen. Noch nicht einmal mit einem 3-Tage-Kurs. Ist uns auch nicht wichtig. Wichtig ist uns, dass wir Potential sehen. Daher nehmen wir uns viel Zeit bei den Bewerbern, was sich bisher wirklich bezahlt gemacht hat.
Gute Punkte, Markus. Danke dir dafür! Und sehr schön zu lesen, welche Erfahrungen du / ihr da machen konntet.
Danke Daniela, dass du ergänzt hast, dass bei der Frage nach dem technischen Know-how nicht nur Software-, sondern auch Hardwareentwicklung gemeint war. Dieser Bereich holt in letzter Zeit stark auf.
Ich folge den Bullets von Markus und würde höchstens noch den SM mit Agile Coach ergänzen sowie bei diesen beiden Rollen ein Auge für den Entwicklungsprozess fordern. Das ist im weitesten Sinne auch Methodik, ich sehe es aber oft vernachlässigt, weshalb ich es speziell erwähne.
Meiner bisherigen Erfahrung nach ist es eine sehr kontextabhängige Entscheidung, ob und wie viel technisches Know-how für die jeweilige Rolle wirklich notwendig ist. Es gibt da viele Aspekte, die eine Rolle spielen können. Hier ein paar Ansätze:
Ich stelle oft fest, dass meistens sehr viel weniger notwendig ist, als es insbesondere die “Techniker” denken und fordern. Fängt etwa ein Scrum Master an, regelmässig auch technische Probleme zu lösen, kann dies sogar ein Warnhinweis sein (z. B. falsches Rollenverständnis, Überforderung des Teams, zu viele Junior-Entwickler…).
Ich habe auch schon (inkl. bei mir selbst) festgestellt, dass ein sehr grosses Know-how schädlich sein kann, wenn sich z. B. ein Scrum Master mit seiner Meinung durchsetzen will, weil “Fehler” vermieden werden sollen. Es fällt diesem dann schwer, sich zurückzunehmen und dem Team das Experiment zu ermöglichen und daraus zu lernen. Unschön, weil man mit der eigenen Meinung falsch liegen kann, aber auch, weil oft noch eine unerwünschte (unterbewusste und informelle) Wahrnehmung als Teamlead besteht. Ein Risiko, besonders in frühen Phasen von Transformationen.
Technisches Wissen kann dazu führen, dass man schneller eine gemeinsame Sprache im Team entwickelt und ist damit sicher positiv. Andererseits muss ein Team in der überwiegenden Anzahl der Fälle auch mit Personen kommunizieren, denen das technische Wissen fehlt. Klassisch bei Scrum ist eine sehr gemischte Gruppe an Stakeholdern im Review. Zu dieser Kommunikation sollten alle Teammitglieder in der Lage sein!
Ich will jedoch nicht leugnen, dass es auch Entwickler-Teams gibt, bei denen die Akzeptanz eines Teammitglieds (insbesondere PO und SM) stark vom technischen Wissen abhängt. Ob diese Haltung von Teammitgliedern allerdings zielführend ist, muss bezweifelt werden, weil es dauerhaft praktisch nie die technischen Themen sind, die die Effektivität und Effizienz eines Teams ausbremsen.
Beim PO ist eigentlich immer nötig, dass ein “branchenfachliches” Wissen vorhanden ist. Ok, es gibt auch Beispiele, bei denen gerade der branchenfremde Blick zu disruptiven Produkten und Geschäftsmodellen geführt hat, aber das ist doch die extreme Ausnahme. Technisches Wissen kann bei der Auswahl einer Person für die PO-Rollen vernachlässigt werden. Der Wille zur Priorisierung (speziell in Richtung Stakeholder) ist um Faktoren entscheidender.
Aus meiner Sicht wird viel zu oft technisches und/oder “branchenfachliches” Wissen bei der Auswahl von agilen Begleitern wie SM und Agile Coach hoch priorisiert, weil dieses Wissen in den Organisationen vorhanden ist und man es so z. B. bei Bewerbern beurteilen kann. Ein möglicherweise falsches Rollenverständnis hatte ich schon erwähnt. Die Qualität der agilen Führung ist regelmässig mit einer Zertifizierung und dem Nachweis eine gewisse Zeit einen entsprechenden Jobtitel wie Scrum Master gehabt zu haben ausreichend belegt. Es ist jedoch nicht ungewöhnlich, dass man bei etwas bohren auf althergebrachtes und ausgeprägtes Teamlead oder Projektmanager verhalten stösst, was kontraproduktiv ist, wenn man tatsächlich den Wunsch nach selbstorganisierten, agilen Teams hat. Im Ergebnis führt es dann eher zu “doing agile” und nicht “being agile”, wenn man sich für jemandem mit diesem Verhalten, aber mit dem vermeintlich nötigen technischem Know-how entscheidet.
Sorry, ist länger geworden als gewollt
Gruss
Stuart
Danke schön, Stuarth, für deinen Beitrag. Scheinbar hab ich für diese Woche eine stimmige Frage der Woche ausgesucht. 
Ich finde es gut, dass du auch Hardwareentwicklung reingebracht hast, um das Ganze nochmal zu ergänzen. Denn das Spektrum ist einfach sehr groß. In meiner Vergangenheit waren es z.B. HR-Teams und HR-Produkte oder Andere … ich sag mal “artfremde” Sachen.
Danke auch für deine Offenheit. Ich bin oft mit Anlauf vor die Wand gelaufen, weil ich dachte “ich müsste dies oder jenes wissen”, “nur dann akzeptiert werden” oder ich müsste “das Team hierhin oder dorthin führen”, usw. Gute Learnings, für die Zukunft wünsche ich mir, dass diese Dinge etwas leichter werden.
Daher ist für mich der Aspekt, den du gerade nochmal aufwirfst, am wichtigsten - wenn ich auswählen dürfte. Das ist das Agile Beeing und daran zu arbeiten. Mir ist völlig klar, dass das nur ein Bestandteil ist, es ist aber der, den ich am meisten fördern wollen würde, weil da so viel Kraft und Transformation auf persönlicher, Team- und Organisationsebene möglich ist.
Kontext (Software-Produkt, Hardware-Produkt) ist wichtig. Aber schon 2011 stellte Marc Andreessen fest:
Software is eating the world
Daher ist dies das dominante Denken in meinen Überlegungen. Es ist unvermeidbar, dass in Hardware auch (nicht wenige) Software-Komponenten stecken.
Software-Systeme sind auch für das Business der Schlüssel für die Überlebensfähigkeit von Organisationen in der Zukunft (mehr Profit, schnellere Anpassungsfähigkeit ggüber Marktänderungen, vergleichsweise einfacher als HW-Produktion, usw.)
Ein Scrum Master benötigt auch “technisches Verständnis”, um für das Team und damit das Produkt und die Organisation wirksam zu sein.
Wenn man sich bei diesem schon etwas älteren Artikel von Barry Overeem orientiert, so liest man dort:
Is also competent with XP, Kanban and Lean
und folgenden Beispiel-Fragen
How are our engineering practices doing?
- Is the team caring and improving them?
- How is the test automation?
- Is the team expanding their Definition of Done?
eXtreme Programming (XP) - das im Übrigen die Rolle des Scrum Masters nicht kennt - und verwandte Themen wie Software Craftership enthalten Praktiken und Haltung zu professioneller Softwareentwicklung.
Wenn ein Scrum Master also weiß,
kann er also besser beobachten, “was gerade Phase ist” im Team. Er kann besser agieren, passgenauere Interventionen setzen, wenn es darum geht, das Team zu unterstützen oder es zu neuer Höchstleistung zu bringen.
Skalierungs-Frameworks wie LeSS propagieren sehr stark eine Haltung, die sehr nah an den Praktiken von XP ist.
SAFe verwendet “ScrumXP”, eine abgewandelte Form von Scrum, die XP-Elemente enthält.
Das Agile Manifest und die dahinter liegenden Werte entstammen dem Leidensdruck, den Software-Professionals um die Jahrtausendwende bei der Realisierung großer Software-Systeme hatten.
Software ist in den letzten 20 Jahren viel komplexer geworden. Es ist hilfreich zu wissen, was Business und Entwickler denn da im Event Storming Workshop zusammen machen, wozu die vielen Klebezettel notwendig sind, was Bounded Contexts sind, wieso man Teams nach Domänen schneiden (zusammenstellen) kann und sollte, warum Team Topologies verschiedene Team-Typen kennt und was dieses DevOps-Ding ist, von dem immer alle sprechen. Welche Auswirkungen dies auf Flow Metrics (hallo Kanban) mit der Prozesseffizienz hat, warum oftmals Effektivität besser ist als Effizienz, manchmal aber dann doch Effizienz wichtiger als Effektivität ist und und und.
The Scrum Master is accountable for the Scrum Team’s effectiveness. They do this by enabling the Scrum Team to improve its practices, within the Scrum framework.
(Scrum Guide)
Der Scrum Master ist also ergebnisverantwortlich für die Effektivität des Teams.
Enabling the team to improve its practices betrifft nicht nur, dass die Scrum Rituale “gut sitzen”, sondern dass eben genau die Praktiken, die das Team verwendet, sich auch verbessern.
Oder wie der deutschsprachige Scrum Guide schreibt:
Der Scrum Master ist ergebnisverantwortlich für die Effektivität des Scrum Teams. Er tut dies, indem er
das Scrum Team in die Lage versetzt, seine Praktiken innerhalb des Scrum-Rahmenwerks zu verbessern.
Und dazu muss der Scrum Master den Kontext, in dem das/sein Team agiert, und die Praktiken, die das Team jetzt und zukünftig verwendet, hinreichend gut verstehen können.