{"version":"https:\/\/jsonfeed.org\/version\/1","title":"NVSBL Feed","home_page_url":"https:\/\/nvsbl.cm","feed_url":"https:\/\/nvsbl.cm","items":[{"id":"https:\/\/nvsbl.cm\/notes\/pair-programming","url":"https:\/\/nvsbl.cm\/notes\/pair-programming","title":"Pair Programming","content_html":"<p>Pair-Programming ist eine simple Arbeitstechnik, bei der zumeist zwei Personen vor einem Rechner sitzen. Eine Person hat die Kontrolle \u00fcber Tastatur und Maus. Beide arbeiten an der L\u00f6sung der gleichen Aufgabe. Eine Person tippt, was zwei denken. Weniger Fehler und besserer Code sind das Ergebnis.<\/p>\n<ul>\n<li><a href=\"#1\">Pair-Programming<\/a><\/li>\n<li><a href=\"#2\">Praktische Hinweise<\/a><\/li>\n<li><a href=\"#3\">Remote Pair-Programming<\/a><\/li>\n<li><a href=\"#4\">Das wahrscheinlich erste Programming Pair war weiblich<\/a><\/li>\n<\/ul>\n<figure class=\"figure\"><div class=\"image-wrapper\"><img alt=\"\u00bbNever code alone.\u00ab\" loading=\"lazy\" src=\"https:\/\/nvsbl.cm\/media\/pages\/notes\/pair-programming\/3d728f41b3-1695706610\/nevervcodealone.jpg\"><\/div><figcaption>Ihr Code wird wahrscheinlich von mehr als einer weiteren Person gesehen. Damit kann man gleich bei der Entstehung beginnen und voneinander lernen.<\/figcaption><\/figure>\n<h2><a name=\"1\"><\/a>Pair-Programming<\/h2>\n<p>Vier Augen sehen mehr als zwei. Genau darum geht es hier. Statt alleine vor dem Bildschirm zu sitzen, nimmt man zu zweit Platz und kontrolliert abwechselnd Maus und Tastatur. Paarweises Programmieren ist ein Dialog zwischen zwei Personen, die gleichzeitig programmieren, analysieren, entwerfen und testen. Sie helfen sich gegenseitig beim Verst\u00e4ndnis der Aufgabe, besprechen Verbesserungen und Optimierungen, kl\u00e4ren Ideen, und ergreifen die Initiative, wenn ihr Partner feststeckt, und verringern so Frustration.<\/p>\n<p>In Studien wurde gezeigt, dass Paare bis zu 41 % schneller entwicklen, und signifikant weniger Fehler produzieren.<sup id=\"fnref1:master\"><a href=\"#fn:master\" class=\"footnote-ref\">1<\/a><\/sup><\/p>\n<p>Ein <em>merge request<\/em> tut es doch auch, k\u00f6nnte man meinen. Nat\u00fcrlich fehlt hier die zeitliche Kopplung. Ein <em>merge request<\/em> ist geschieht nachdem eine Person gedacht und gehandelt hat. Alle Fehler, ungenutzten Potenziale und Missverst\u00e4ndnisse stecken bereits in dem Code. Beim <em>pairen<\/em> kommt es erst gar nicht dazu.<\/p>\n<p>Zu meinem Job als Technischer Projektmanager geh\u00f6rte es einmal, die Website von McDonald\u2018s mit neuen Flash-Inhalten zu versorgen. Das CMS sah dazu einen fehleranf\u00e4lligen Prozess vor, bei dem Dateien in einer bestimmten Reihenfolge hochgeladen werden mussten. Nach einigen schief gelaufenen Launches sa\u00dfen wir nur noch zu zweit vor dem Bildschirm. Siehe da, keine Fehler mehr.<\/p>\n<blockquote>\n<p>We believe that pair programming is often avoided because it can create friction, but we would ask you to give it a chance. If you consciously treat it as an improvable skill, and work on getting better at it, you will end up with a more resilient team.<sup id=\"fnref1:Boeckeler-Siessegger\"><a href=\"#fn:Boeckeler-Siessegger\" class=\"footnote-ref\">2<\/a><\/sup><\/p>\n<\/blockquote>\n<h2><a name=\"2\"><\/a>Praktische Hinweise<\/h2>\n<figure class=\"figure\"><div class=\"image-wrapper\"><img alt=\"Eine Frau gibt einer Fahrer*in Handzeichen zur Navigation durch unwegsames Gel\u00e4nde.\" loading=\"lazy\" src=\"https:\/\/nvsbl.cm\/media\/pages\/notes\/pair-programming\/a334ae59d4-1695706610\/driver-navigator.jpg\"><\/div><figcaption>Nicht nur vor dem Bildschirm gibt es Paare, die gemeinsam Aufgaben bew\u00e4ltigen.<\/figcaption><\/figure>\n<h3>Reden<\/h3>\n<p>Pair-Programming funktioniert, weil beide Personen miteinander sprechen. Sowohl die Person, die gerade Code schreibt (manchmal <em>driver<\/em> genannt), als auch die beobachtende Person (<em>observer<\/em> oder <em>navigator<\/em> genannt) d\u00fcrfen und sollen sprechen, kommentieren und sich gegenseitig Hinweise geben.<\/p>\n<h3>Respektvolles Verhalten<\/h3>\n<p>Unser Raumbed\u00fcrfnis unterscheidet sich sehr. Schreibtische und Bildschirme sollten gro\u00df sein, je gr\u00f6\u00dfer desto besser, die Kabel lang genug, um den gesamten Platz nutzen zu k\u00f6nnen.<\/p>\n<p>Kommen zwei Menschen auf engen Raum zusammen, sollten sie R\u00fccksicht walten lassen. Im Zweifel mehr Abstand halten, mehr R\u00fccksicht nehmen. Mit der Zeit stellt man sich auf die Situation ein.<\/p>\n<h3>Paare dokumentieren<\/h3>\n<p>Beginnt ein Team mit Pair-Programming, kann es n\u00fctzlich sein, die <em>pairs<\/em> zu dokumentieren. Ich mag den <a href=\"https:\/\/pairingmatrix.com\/#\/generator\">Generator von Paringmatrix.com<\/a>. Die Dokumentation hilft, im Blick zu halten, wer mit wem woran gearbeitet hat. Ein Team kann sie auch benutzen, um regelm\u00e4\u00dfige Wechsel zu planen. <\/p>\n<h3>Regelm\u00e4\u00dfig wechseln<\/h3>\n<p>Teams sollten mit dem Rhythmus experimentieren, in dem sie ihre Paarungen durchtauschen. Arbeitstagweise, halbtags, oder h\u00e4ufiger. Es gibt hier kein Optimum, statt dessen viel Raum f\u00fcr Experimente.<\/p>\n<h2><a name=\"3\"><\/a>Remote Pair-Programming<\/h2>\n<p>Auch remote l\u00e4\u00dft sich Pair-Programming anwenden. Voraussetzung ist eine Screen-Sharing-L\u00f6sung, bei der man die Kontrolle \u00fcber den geteilten Rechner abgeben kann. F\u00fcr Visual Studio Code zum Beispiel hat Microsoft die Erweiterung <a href=\"https:\/\/marketplace.visualstudio.com\/items?itemName=MS-vsliveshare.vsliveshare\">Live Share<\/a> parat. Weitere Empfehlungen finden sich bei <a href=\"https:\/\/www.sitepoint.com\/collaborative-coding-tools-for-remote-pair-programming\/\">Sitepoint<\/a>. Es gibt dedizierte Angebote wie <a href=\"https:\/\/www.coscreen.co\">CoScreen<\/a> und <a href=\"https:\/\/www.use-together.com\">USE Together<\/a>. Im Zweifel VNC oder SSH.<\/p>\n<h2><a name=\"4\"><\/a>Das wahrscheinlich erste Programming Pair<\/h2>\n<p>Jean Bartik war eine der ENIAC-Frauen, die von vielen als die ersten Programmiererinnen \u00fcberhaupt angesehen werden. Sie \u00fcbernahmen die Aufgabe des Programmierens, als das Wort \u00bbProgramm\u00ab noch nicht einmal verwendet wurde und es keine Vorbilder oder B\u00fccher gab, die ihnen sagten, wie sie dies tun sollten - und sie beschlossen, dass es eine gute Idee w\u00e4re, zu zweit zu arbeiten. Es dauerte etwa 50 weitere Jahre, bis Pair Programmierung zu einem weit verbreiteten Begriff wurde.<\/p>\n<figure class=\"figure content-wide\"><div class=\"image-wrapper\"><video controls=\"controls\" poster=\"https:\/\/nvsbl.cm\/media\/pages\/notes\/pair-programming\/2acc51cec1-1695706610\/jean-bartik.jpg\" preload=\"metadata\" width=\"100%\"><source src=\"https:\/\/nvsbl.cm\/media\/pages\/notes\/pair-programming\/7b0f4d4ef3-1695706610\/pair-programming-video.mp4\" type=\"video\/mp4\"><\/source><\/video><\/div><figcaption>Zitat: \u00bbBetty Snyder and I, from the beginning, were a pair. And I believe that the best programs and designs are done by pairs.\u00ab<\/figcaption><\/figure>\n<div class=\"footnotes\">\n<hr \/>\n<ol>\n<li id=\"fn:master\">\n<p>Sch\u00fctt, <a href=\"https:\/\/www.inf.fu-berlin.de\/inst\/ag-se\/theses\/Schuett14-PP-gemeins-Wissensproduktion.pdf\">Gemeinsame Wissensproduktion in der Paarprogrammierung<\/a>. FU Berlin, 2014.&#160;<a href=\"#fnref1:master\" rev=\"footnote\" class=\"footnote-backref\">&#8617;<\/a><\/p>\n<\/li>\n<li id=\"fn:Boeckeler-Siessegger\">\n<p>B\u00f6ckeler, Siessegger, <a href=\"https:\/\/martinfowler.com\/articles\/on-pair-programming.html\">On Pair Programming<\/a>.&#160;<a href=\"#fnref1:Boeckeler-Siessegger\" rev=\"footnote\" class=\"footnote-backref\">&#8617;<\/a><\/p>\n<\/li>\n<\/ol>\n<\/div>","date_published":"c","date_modified":"Y-m-d\\TH:i:sP"},{"id":"https:\/\/nvsbl.cm\/notes\/entscheidungen","url":"https:\/\/nvsbl.cm\/notes\/entscheidungen","title":"Entscheidungen, Entscheidungen","content_html":"<p>Kein Wort steht besser f\u00fcr den Konflikt zwischen zentraler Macht und dezentraler Autonomie. Wer viel zu entscheiden hat, ist wichtig. Auf wessen Entscheidung andere warten m\u00fcssen, ist wichtiger. Wessen Entscheidungen mehr Menschen beeintr\u00e4chtigen, ist m\u00e4chtiger. Indem wir Management als Funktion denn als Rolle begreifen, entlarven wir die Leere dieser S\u00e4tze.<\/p>\n<p>Inhalt:<\/p>\n<ul>\n<li><a href=\"#1\">Nadel&ouml;hr<\/a><\/li>\n<li><a href=\"#2\">Risiken<\/a><\/li>\n<li><a href=\"#3\">Entscheiden lassen<\/a><\/li>\n<li><a href=\"#4\">Welche Entscheidungen &uuml;brig bleiben<\/a><\/li>\n<\/ul>\n<h2><a name=\"1\"><\/a>Nadel\u00f6hr<\/h2>\n<figure class=\"figure\"><div class=\"image-wrapper\"><img alt=\"Diagramm mit zwei Achsen. X-Achse: Risiko, Y-Achse: Strategische Ebene.\" loading=\"lazy\" src=\"https:\/\/nvsbl.cm\/media\/pages\/notes\/entscheidungen\/c33716b9cb-1695706609\/entscheidungen.jpg\"><\/div><figcaption>Die operativen und wenig risikoreichen Entscheidungen sollten Sie nicht selbst treffen m\u00fcssen. Sie brauchen Kapazit\u00e4t f\u00fcr die strategischen und risikoreichsten Entscheide.<\/figcaption><\/figure>\n<p>Das Unternehmen m\u00f6chte seine Investitionen besser steuern. Es baut sich dazu einen mehrstufigen Prozess. Nach bestimmten Meilensteinen m\u00fcssen Initiativen zeigen, dass sie weiterhin auf gutem Kurs sind. Ist der Vorstand \u00fcberzeugt, wird Budget f\u00fcr die n\u00e4chste Phase freigegeben.<\/p>\n<p>Es gibt 30 solcher Initiativen. Von der ersten Idee bis zur Produktreife stehen f\u00fcnf Phasen an, es sind also 150 Entscheidungen zu f\u00e4llen. Das Gremium kommt alle vier Wochen zusammen, de facto zehn Mal im Jahr und kann im Schnitt f\u00fcnf Entscheidungen treffen. 150 Entscheidungen stehen einer Kapazit\u00e4t f\u00fcr 50 Entscheidungen gegen\u00fcber. Entkoppelt von der m\u00f6glichen Umsetzungsgeschwindigkeit ben\u00f6tigt das Unternehmen also drei Jahre zur Entscheidung.<\/p>\n<p>Wie s\u00e4he es aus, wenn der Vorstand sich auf 5 Initiativen beschr\u00e4nkt und die restlichen 25 den vier Unternehmensbereichen \u00fcberl\u00e4sst? Auf oberster Ebene stehen 25 Entscheidungen einer Kapazit\u00e4t f\u00fcr 50 gegen\u00fcber. Teilten sich die 25 Initiativen gleichm\u00e4\u00dfig auf, st\u00fcnden auf Bereichsebene 30-35 Entscheidungen einer Kapazit\u00e4t f\u00fcr 50 gegen\u00fcber. Nun k\u00f6nnen die schnelleren Initiativen schneller behandelt werden, zumal die Bereiche Entscheidungen autonom anders regeln k\u00f6nnten.<\/p>\n<p>Greifbarer Ausdruck dessen ist \u2026 Warten. Warten auf Frau oder Herr M\u00fcller, ohne deren Anwesenheit das Meeting nicht beginnen kann, weil nur sie die richtige Hierarchiestufe haben, um Entscheidungen treffen zu k\u00f6nnen.<\/p>\n<h2><a name=\"2\"><\/a>Risiken<\/h2>\n<p>Dabei bezeichnen wir h\u00e4ufig simple Auswahlen als Entscheidungen. Option A oder B? Die Vor- und Nachteile liegen auf der Hand, wir sind uns einig \u00fcber den Ma\u00dfstab und die Bewertung. Das ist eine Auswahl. Eine Entscheidung hingegen ist n\u00f6tig,<br \/>\n\u00bb[w]enn [\u2026] gleichwertige Argumente f\u00fcr oder gegen ein Handeln sprechen.\u00ab Wenn es gute Gr\u00fcnde f\u00fcr A gibt, und ebenso gute Gr\u00fcnde f\u00fcr B.<\/p>\n<blockquote>\n<p>Entscheidungen sind genau dann n\u00f6tig, wenn sie unm\u00f6glich sind\u00a0\u2013 unm\u00f6glich im Sinne von \u00bbschl\u00fcssig zu begr\u00fcnden\u00ab. Sie k\u00f6nnten auch eine M\u00fcnze werfen oder einen Strohhalm ziehen. Es ist gerade das Fehlen der Begr\u00fcndung, die uns zur Entscheidung dr\u00e4ngt.<sup id=\"fnref1:sprenger\"><a href=\"#fn:sprenger\" class=\"footnote-ref\">1<\/a><\/sup><\/p>\n<\/blockquote>\n<p>Eine Entscheidung tr\u00e4gt also ein Risiko in sich. Ohne zumindest einen Teil des Weges zu gehen, k\u00f6nnen wir nicht wissen, was uns auf dem Weg erwartet. Die Idee des MVP, des \u00bbminimal viable product\u00ab, und auch die Idee der Agilit\u00e4t setzen hier an. Beide versprechen, Risiken durch m\u00f6glichst kurze Hypothese-Experiment-Zyklus zu reduzieren.<\/p>\n<blockquote>\n<p>Your prioritized list of hypotheses has given you several paths to explore. To do this exploration, you are going to want to create the smallest thing you can to determine the validity of each of these hypothesis statements. That is your MVP. You will use your MVP to run experiments. The outcome of the experiments will tell you whether your hypothesis was correct and thus whether the direction you are exploring should be pursued, refined or abandoned.<sup id=\"fnref1:gothelf\"><a href=\"#fn:gothelf\" class=\"footnote-ref\">2<\/a><\/sup><\/p>\n<\/blockquote>\n<p>Wenn \u00fcberhaupt, dann sollten F\u00fchrungskr\u00e4fte daf\u00fcr sorgen, ausschlie\u00dflich echte Entscheidungen treffen zu m\u00fcssen. Auswahlen jedoch verstopfen das Nadel\u00f6hr, auch wenn sie vielleicht dem Ego schmeicheln.<\/p>\n<h2><a name=\"3\"><\/a>Entscheiden lassen<\/h2>\n<p>Arbeiten Sie als F\u00fchrungskraft an einer <a href=\"https:\/\/nvsbl.cm\/notes\/die-wirksamkeit-anderer-jenseits-von-heldentum\">Management-Infrastruktur<\/a>, in der andere wirksam werden k\u00f6nnen?<\/p>\n<blockquote>\n<p>Management und seine Facetten sind keine Rollen, sondern Aufgaben, und Ihre erste Pflicht besteht darin, sie umzuverteilen. Verschieben Sie den Ort der Entscheidung an die Stelle, an der sie maximal wirksam sein kann.<sup id=\"fnref1:carlin\"><a href=\"#fn:carlin\" class=\"footnote-ref\">3<\/a><\/sup><\/p>\n<\/blockquote>\n<p>Ihre Infrastruktur sollte es Ihnen erm\u00f6glichen, m\u00f6glichst viele Auswahlen und Entscheidungen nicht selbst treffen zu m\u00fcssen.<\/p>\n<h2><a name=\"4\"><\/a>Welche Entscheidungen \u00fcbrig bleiben<\/h2>\n<p>Neben der Unterscheidung zwischen operativer und strategischer Arbeit sind es Entscheidungen mit hohem Risiko, <a href=\"https:\/\/nvsbl.cm\/notes\/hierarchie-in-unternehmen\">die reine Management-Rollen in Organisationen rechtfertigen<\/a>. Die Verantwortung einer Gesch\u00e4ftsf\u00fchrung oder die eines Vorstands ist gesetzlich geregelt und kann nicht umgangen werden. So wird es also immer Entscheidungen geben, die sich die Menschen in diesen Rollen vorbehalten, alleine oder zumindest letztlich entscheiden zu wollen. Je nach Gr\u00f6\u00dfe der Organisation sickert dieser Gedanke die Hierarchie nach unten.<\/p>\n<p>Wo Ihr Unternehmen die Grenze zieht, ist von vielen Faktoren abh\u00e4ngig. Als Prinzip kann gelten: Je konkreter die Auswirkungen einer Entscheidung morgen im Betrieb sp\u00fcrbar sind, desto eher sollten Sie diese Entscheidung nicht selbst treffen m\u00fcssen.<\/p>\n<p>Nimmt man den Gedanken Ernst, Entscheidungen als Funktion von Management zusehen, die dort erf\u00fcllt werden soll, wo sie maximal wirksam werden kann, bleiben erstaunlich wenig Entscheidungen \u00fcbrig, die zentral von oben zu treffen sind. Den gewonnenen Freiraum in Kalender und Kopf k\u00f6nnen Sie zum Beispiel nutzen, um weiter in Ihrer Management-Infrastruktur zu arbeiten.<\/p>\n<div class=\"footnotes\">\n<hr \/>\n<ol>\n<li id=\"fn:sprenger\">\n<p>Richard Sprenger, Radikal F\u00fchren. Campus 2012. Kapitel \u00bbDritte Kernaufgabe: Konflikte entscheiden\u00ab&#160;<a href=\"#fnref1:sprenger\" rev=\"footnote\" class=\"footnote-backref\">&#8617;<\/a><\/p>\n<\/li>\n<li id=\"fn:gothelf\">\n<p>Jeff Gothelf, Lean UX. O\u2018Reilley 2013. Kapitel \u00bbMVPs and Experiments\u00ab&#160;<a href=\"#fnref1:gothelf\" rev=\"footnote\" class=\"footnote-backref\">&#8617;<\/a><\/p>\n<\/li>\n<li id=\"fn:carlin\">\n<p><a href=\"https:\/\/nvsbl.cm\/notes\/die-wirksamkeit-anderer-jenseits-von-heldentum\">Ihre Wirksamkeit als Manager<\/a>&#160;<a href=\"#fnref1:carlin\" rev=\"footnote\" class=\"footnote-backref\">&#8617;<\/a><\/p>\n<\/li>\n<\/ol>\n<\/div>","date_published":"c","date_modified":"Y-m-d\\TH:i:sP"},{"id":"https:\/\/nvsbl.cm\/notes\/agile-transformation-messen","url":"https:\/\/nvsbl.cm\/notes\/agile-transformation-messen","title":"Agile Transformation messen","content_html":"<p>\u00bbWoher wissen wir, dass wir in unserer agilen Transformation vorankommen?\u00ab Das Spektrum m\u00f6glicher Antworten auf dem Beratungsmarkt reicht von Velocity-Tracking bis Kultur-Untersuchung.<\/p>\n<p>Inhalt:<\/p>\n<ul>\n<li><a href=\"#1\">Lieber nicht den Output messen<\/a><\/li>\n<li><a href=\"#2\">Output &amp; Outcome<\/a><\/li>\n<li><a href=\"#3\">Sinnvolle Outcome-Kennzahlen<\/a><\/li>\n<li><a href=\"#4\">Velocity und Burndowns<\/a><\/li>\n<li><a href=\"#5\">Und wenn man vom Weg abkommt?<\/a><\/li>\n<\/ul>\n<p>Um das Ergebnis einer Ver\u00e4nderung zu messen, braucht man ein Instrument, dass m\u00f6glichst viele Aspekte der Ver\u00e4nderung beinhaltet. Andererseits sollte das Instrument sich nicht direkt auf den Output der Teams beziehen \u2013 denn das l\u00e4\u00dft sich zu leicht f\u00e4lschen.<\/p>\n<figure class=\"figure\"><div class=\"image-wrapper\"><img alt=\"Comic zum Thema KPI.\" loading=\"lazy\" src=\"https:\/\/nvsbl.cm\/media\/pages\/notes\/agile-transformation-messen\/e3f1ee3a29-1695706609\/191111.highres.roi.jpg\"><\/div><figcaption>Key Performance Indicators taugen nur, wenn sie den Fortschritt hinsichtlich wichtiger Zielsetzungen innerhalb einer Organisation ermitteln k\u00f6nnen.<\/figcaption><\/figure>\n<p>Ein sch\u00f6nes Beispiel daf\u00fcr ist die Idee eines Bonus f\u00fcr gefundene und behobene Bugs. <\/p>\n<h2><a name=\"1\"><\/a>Lieber nicht den Output messen<\/h2>\n<p>Der CTO eines mittelgro\u00dfen Lager- und Transportunternehmens in Nordkalifornien k\u00fcndigte ein innovatives Programm an, um die Mitarbeiter zu motivieren und die Qualit\u00e4t ihrer Logistiksoftware zu steigern. F\u00fcr jeden Fehler, der von einem Tester gefunden und von einem Programmierer behoben wird, w\u00fcrden beide 10 Dollar erhalten:<\/p>\n<blockquote>\n<p>Der CTO hoffte, die Codequalit\u00e4t bei der weitreichenden \u00dcberholung der Beschaffungs-, Einkaufs-, Bestands-, Lager-, Vertriebs-, Transport-, Kundensupport- und Finanzsysteme des Unternehmens zu verbessern. Das Entwicklungsteam war anfangs skeptisch, aber am Ende des ersten Tages des Anreizprogramms waren sowohl die Programmierer als auch die Tester \u00fcberzeugt. Nach einem durchschnittlichen Tag, an dem sie Fehler gefunden und behoben hatten, hatte jeder von ihnen zwischen 30 und 40 Dollar zus\u00e4tzlich verdient.<\/p>\n<p>Am vierten Tag war der Brunnen ausgetrocknet. Die Tester lie\u00dfen die Testf\u00e4lle laufen, wiederholten sie und wiederholten sie, aber sie konnten nur eine handvoll Probleme finden. Die Entwickler strapazierten das Fehlerverfolgungssystem, luden st\u00e4ndig die Seite mit den \"nicht zugewiesenen Fehlern\" neu und beeilten sich, alles, was auftauchte, sich selbst zuzuweisen.<\/p>\n<p>Und dann passierte beim Mittagessen etwas Seltsames. Anstatt mit seinen \u00fcblichen Teamkollegen essen zu gehen, ging einer der Entwickler mit einem Tester aus. Bald darauf ging ein anderer Entwickler mit einem anderen Tester aus. Innerhalb weniger Minuten hatten sich fast alle Entwickler mit Testern zusammengetan.<\/p>\n<p>Als die Entwickler vom Mittagessen zur\u00fcckkamen, machten sie sich sofort an die Arbeit. Anstatt nach neu gefundenen Fehlern zu suchen, arbeiteten sie an \"Code-Refactoring\" und neuen Funktionen. Und sobald sie ihre \u00c4nderungen einsetzten, fanden die Tester Fehler - kleinere, obskure Fehler, die ein Entwickler leicht \u00fcbersehen konnte. Und genau so schnell, wie die Tester Fehler gefunden hatten, konnten die Entwickler diese beheben und neu implementieren. Am Ende des Tages hatten die Entwickler und Tester durchschnittlich 120 Dollar verdient.<\/p>\n<p>Zitiert nach <a href=\"https:\/\/thedailywtf.com\/articles\/The-Defect-Black-Market\">The Defect Black Market<\/a>, The Daily WTF, 2008.<\/p>\n<\/blockquote>\n<p>Wie also messen wir unsere agile Transfomation? In dem wir auf Outcome achten.<\/p>\n<h2><a name=\"2\"><\/a>Output &amp; Outcome<\/h2>\n<p>Output ist, trocken formuliert, die Leistung der Organisation als direktes <em>Ergebnis<\/em> der Prozesse. Es gibt einen Prozess, dessen Ergebnis Softwarecode ist, also ist Softwarecode ein Output der Organisation.<\/p>\n<p>Hingegen ist Outcome die <em>Folge<\/em> der Leistung.<\/p>\n<p>Hier wird gerne Umsatz als Beispiel genannt. Pr\u00fcfen wir mal, ob das stimmt: Umsatz ist das Geld das Dritte uns f\u00fcr unsere Leistung bezahlt haben.\u00ab Aus der Leistung, deren Ergebnis ein St\u00fcck Software ist, wird Umsatz. Passt.<\/p>\n<p>Leider ist Umsatz ein \u00bblagging indicator\u00ab. Die Information zum Umsatz kommt mit Verz\u00f6gerung an. Es ist als Messinstrument f\u00fcr Kurskorrekturen einer agile Transformation zu langsam.<\/p>\n<p>Die meisten Outcome-Kennzahlen beinhalten mehr als einen Faktor. Das macht die Zurechnung einzelner Ma\u00dfnahmen zu Erfolg und Misserfolg schwierig. Diese intellektuelle Arbeit, die Analyse und Schlussfolgerung aus Ihrer Beobachtung einer Kennzahl, kann Ihnen kein Dashboard und kein Management-System abnehmen.<\/p>\n<p>Gute Zusammenarbeit entsteht durch stetige Investition Ihrer Zeit in Vertrauen, Respekt und Sicherheit. Auch das nimmt Ihnen niemanden ab.<\/p>\n<figure class=\"figure\"><div class=\"image-wrapper\"><img alt=\"Kollaboration kann nicht befohlen werden. Zusammenarbeit entsteht dank Zeit, Vertrauen, Respekt und Sicherheit.\" loading=\"lazy\" src=\"https:\/\/nvsbl.cm\/media\/pages\/notes\/agile-transformation-messen\/1bd612d910-1695706609\/kollaboration.jpg\"><\/div><figcaption>Kollaboration kann nicht befohlen werden. Zusammenarbeit entsteht dank Zeit, Vertrauen, Respekt und Sicherheit.<\/figcaption><\/figure>\n<h2><a name=\"3\"><\/a>Sinnvolle Outcome-Kennzahlen<\/h2>\n<p>Grunds\u00e4tzlich sollten Agilit\u00e4ts-Kennzahlen \u00fcber mehrere Teams hinweg Vergleichbarkeit herstellen. Ist eine Kennzahl f\u00fcr ein Team nicht relevant, oder erlaubt eine Kennzahl keinen Vergleich, ist sie nicht geeignet, die Ausgangsfrage nach der Verbesserung der Arbeitsweise durch agile Methoden zu beantworten. Siehe den Abschnitt \u00fcber <a href=\"#4\">Velocity und Burndowns<\/a>.<\/p>\n<h3>Scrum-Metriken<\/h3>\n<p>Diese Metriken h\u00e4ngen von Artefakten und Praktiken in Scrum ab.<\/p>\n<ul>\n<li><strong>\u00bbHaben wir unser Sprintziel erreicht?\u00ab<\/strong> Schlicht und simpel. Haben wir, gem\u00e4\u00df unserer \u00bbdefinition of done\u00ab, unser Sprint-Ziel erreicht. Wenn die Antwort darauf konsistent \u00bbnein\u00ab lautet, l\u00e4uft etwas schief.<\/li>\n<li><strong>L\u00e4nge des vollst\u00e4ndigen Plannings.<\/strong> In Scrum hat ein Planning-Event eine Timebox. Es darf f\u00fcr einen Zwei-Wochen-Sprint nicht l\u00e4nger dauern als vier Stunden. <a href=\"https:\/\/nvsbl.cm\/notes\/pace-cadence-von-durchsatz-und-takt\">Mehr dazu im Sprint-Kalender.<\/a> Warum diese Festlegung? Dahinter steckt die \u00dcberlegung, dass ein Planning umso l\u00e4nger dauert, je mehr Unklarheiten \u00fcber den Scope bestehen. Da Scrum vorsieht, Unklarheiten zeitnah nach ihrem Auftreten zu kl\u00e4ren, sind konsistent zu lange laufende Plannings ein guter Indikator f\u00fcr Schwierigkeiten.<\/li>\n<li><strong>Ticket-\u00dcberlauf.<\/strong> Tickets wandern von einem Sprint in den n\u00e4chsten. H\u00e4ufig ist eine unvollst\u00e4ndige \u00bbdefinition of done\u00ab sichtbares Artefakt des Problems. <a href=\"https:\/\/nvsbl.cm\/notes\/erste-schritte-mit-einer-definition-of-done\">Im Detail habe ich das hier beschrieben<\/a>.<\/li>\n<\/ul>\n<p>Beide kann man nat\u00fcrlich auch negativ betrachten. Wir erreichen immer unsere Sprint-Ziele, aber gef\u00fchlt tut das Team quasi nichts. Das Planning dauert nur eine Stunde. Weiter oben sagten wir: \u00bbDiese intellektuelle Arbeit, die Analyse und Schlussfolgerung aus Ihrer Beobachtung einer Kennzahl kann Ihnen kein Dashboard und kein Management-System abnehmen.\u00ab<\/p>\n<h3>Produkt-bezogene Metriken<\/h3>\n<ul>\n<li><strong>Fehlermeldungen nach Release.<\/strong> Je mehr Fehler durch Kund*innen gemeldet werden, desto schlechter. Durch agiles Arbeiten, also z. B. Einbeziehung der Kund*innen, Zusammenarbeit zum Verst\u00e4ndnis des Scopes und der L\u00f6sungsans\u00e4tze, Test Driven Development, Pair Programming (oder sogar Mob Programming), oder regelm\u00e4\u00dfige Integrationstest m\u00f6chten wir m\u00f6glichst viel gleich im ersten Anlauf richtig machen, und handwerklich Schlamperei rechtzeitig zu erkennen und zu korrigieren.<\/li>\n<li>\u00c4hnlich dazu: <strong>Die Anzahl der Bugs, die erst im n\u00e4chsten Zeitabschnitt gefixt werden.<\/strong> Diese Zahl sollte ebenfalls gegen Null gehen. Einerseits sollte ein Bug grunds\u00e4tzlich immer sofort gefixt werden. Andererseits fallen Bugs manchmal erst nach dem Deployment auf. Hier sind sie ein Indikator f\u00fcr mangelnde Automatisierung bzw. zu unregelm\u00e4\u00dfige Integration. Finden Integrationstest zu selten und gegen Ende einer Entwicklungsphase statt, bleibt keine Zeit mehr f\u00fcr Bugfixes.<\/li>\n<\/ul>\n<h2><a name=\"4\"><\/a>Velocity und Burndowns<\/h2>\n<p>Warum Velocity eine denkbar schlechte Metrik ist, dar\u00fcber haben schon andere geschrieben. <a href=\"https:\/\/www.scrum.org\/resources\/blog\/myth-velocity-productivity\">Jedes<\/a> <a href=\"https:\/\/holub.com\/kpis-velocity-and-other-destructive-metrics\/\">Wort<\/a> <a href=\"https:\/\/blog.backlogapp.io\/how-to-use-velocity-5149e9c1b31c\">in<\/a> <a href=\"https:\/\/linearb.io\/blog\/why-agile-velocity-is-the-most-dangerous-metric-for-software-development-teams\/\">diesem<\/a> <a href=\"https:\/\/www.infoq.com\/articles\/not-destroy-team-metrics\/\">Satz<\/a> (der n\u00e4chste ist ein Klassiker) <a href=\"https:\/\/www.scrum.org\/resources\/blog\/agile-metrics-velocity\">verlinkt<\/a> <a href=\"https:\/\/docs.microsoft.com\/en-us\/azure\/devops\/report\/dashboards\/velocity-guidance?view=azure-devops&amp;tabs=in-context\">auf<\/a> <a href=\"https:\/\/www.scrum.org\/resources\/blog\/velocity-false-metric-productivity\">einen<\/a> <a href=\"https:\/\/dotdotdev.com\/2019\/07\/08\/is-velocity-a-vanity-metric\/\">Artikel<\/a> <a href=\"https:\/\/aimconsulting.com\/insights\/velocity-elusive-metric-scrum\/\">dazu<\/a>.<\/p>\n<p>Burndowns sind \u00fcber Teams hinweg nicht vergleichbar. Warum Team A heute fr\u00fch vier Storypoints weiter ist als Team B ist keine relevante Frage, weil es in der Situation gute Gr\u00fcnde daf\u00fcr gibt, die nicht ver\u00e4nderbar sind. Burndowns m\u00f6gen R\u00fcckschl\u00fcsse auf den Fortschritt der aktuellen Timebox liefern, weiteren Nutzen haben sie nicht.<\/p>\n<p>Das l\u00e4sst sich analog f\u00fcr Velocity formulieren: Die Velocity ist \u00fcber Teams hinweg nicht vergleichbar. Warum Team A vier Storypoints mehr geschafft hat als Team B ist keine relevante Frage, weil es in der Situation gute Gr\u00fcnde daf\u00fcr gibt, die nicht ver\u00e4nderbar sind. Gleiches gilt f\u00fcr die Ver\u00e4nderung der Velocity eines Teams \u00fcber die Zeit. Davon unbenommen ist die Frage, ob Storypoints an sich eine gute Idee sind. Tipp: sind sie nicht.<\/p>\n<h2><a name=\"5\"><\/a>Und wenn man vom Weg abkommt?<\/h2>\n<p>Wir konnten die vier vorgestellten Metriken auf Werte und Prinzipien des Scrum-Guides und des Agilen Manifests zur\u00fcckf\u00fchren. Wenn wir den Fortschritt unserer Agilen Transformation messen wollen, ist das nur folgerichtig: Wonach sonst, als nach den Ideen in diesen Dokumenten wollen wir uns richten?<\/p>\n<h3>Was war Ihr Ziel?<\/h3>\n<p>Welcher Handlungsdruck Sie Ihre Agile Transformation auch starten lie\u00df, nat\u00fcrlich sollten Sie sich auch darin messen, ob Mitarbeiter*innenflukuation oder Kundenzufriedenheit. Wichtig ist nur, dass Sie sich ein relevantes Ziel gesetzt haben, es nachhalten und nachjustieren und auf dem Weg keine Scheuklappen aufsetzen.<\/p>\n<h3>Agile Realign<\/h3>\n<p>Mit dem Agile Realign-Workshop kann ich Ihnen helfen, sowohl Ziele zu formulieren als auch Werkzeuge und Ma\u00dfnahmen zu entwickeln, mit denen Sie auf Kurs bleiben und, am wichtigsten, den Kurs jederzeit sinnvoll korrigieren k\u00f6nnen. Sprechen Sie mich an.<\/p>","date_published":"c","date_modified":"Y-m-d\\TH:i:sP"},{"id":"https:\/\/nvsbl.cm\/notes\/erste-schritte-mit-einer-definition-of-done","url":"https:\/\/nvsbl.cm\/notes\/erste-schritte-mit-einer-definition-of-done","title":"Erste Schritte mit einer Definition of Done","content_html":"<p>Das erste Thema in meiner Arbeit mit einem neuen Team ist deren <em>definition of done<\/em>. Mit agilem Vorgehen unerfahrene Teams tun sich hier zu Beginn oft schwer. Wozu braucht man eine DoD, wie startet man, was ist zu beachten?<\/p>\n<p>Inhalt<\/p>\n<ul>\n<li><a href=\"#1\">DoD, die ersten Schritte<\/a><\/li>\n<li><a href=\"#2\">Der Software Development Lifecycle<\/a><\/li>\n<li><a href=\"#3\">#NoEstimates<\/a><\/li>\n<li><a href=\"#4\">Definition of Done im &Uuml;berblick<\/a><\/li>\n<li><a href=\"#5\">Und wenn wir keine DoD haben?<\/a><\/li>\n<\/ul>\n<h2><a name=\"1\"><\/a>DoD, die ersten Schritte: Was muss getan werden<\/h2>\n<p>Am Ende eines Sprints steht die Releasef\u00e4higkeit. Alles, woran das Team gearbeitet hat, womit es fertig ist, muss release-bar sein. Die Begr\u00fcndung daf\u00fcr ist simpel: Wenn wir nicht regelm\u00e4\u00dfig bis zur Releasef\u00e4higkeit arbeiten, wird die f\u00fcr ein Release n\u00f6tige Arbeit mehr, komplizierter und schwerer nachvollziehbar. Sie wird fehleranf\u00e4lliger und langwieriger.<\/p>\n<p>Was aber ist \u00bbfertig\u00ab? Diese Frage beantwortet das Development-Team mit einer <em>definition of done<\/em>. Eine DoD ist eine Checkliste, die man gegen jedes Ticket, jede Story halten und pr\u00fcfen kann, ob dieses Ticket erledigt ist, oder nicht.<\/p>\n<p>Hier ein Beispiel:<\/p>\n<ul>\n<li>All assets are finalized and available as agreed<\/li>\n<li>Code style is met<\/li>\n<li>Implementation tests out in Unity Editor<ul>\n<li>No errors related to implemented feature<\/li>\n<li>Report error for other features<\/li>\n<li>If possible, feature is reviewed by assigned reviewer (see Task Definition in DoR)<\/li>\n<li>If feature is UI related it must be viewed in device simulator<\/li>\n<\/ul>\n<\/li>\n<li>New and previously created Unit tests passed <\/li>\n<li>Committed &amp; pushed to current branch with appropriate comment(s)<\/li>\n<li>Commits are part of a build<\/li>\n<li>Build working on Unity Cloud Build<\/li>\n<li>Create a release notes for changes in the build<\/li>\n<li>Feature is reviewed by assigned reviewer on a device<\/li>\n<li>Create enduser documentation for features in Confluence<\/li>\n<\/ul>\n<p>Diese DoD ist vier Sprints alt, also noch frisch. Man bemerkt das an den sehr konkreten, kleinteiligen Spiegelstrichen. Dennoch kann das Team damit arbeiten jede Aufgabe pr\u00fcfen: \u00bbdone or not done.\u00ab<\/p>\n<h2><a name=\"2\"><\/a>Der Software Development Lifecycle und die DoD<\/h2>\n<p>Hinter der DoD scheint der Software Development Lifecycle durch, der die zur Lieferung potenziell n\u00fctzlicher Software notwendigen T\u00e4tigkeitsfelder zeigt \u2013 in Abgrenzung zur Definition of ready, bei der es darum geht, ob ein Backlog-Item umsetzbar ist.<\/p>\n<figure class=\"figure\"><div class=\"image-wrapper\"><img alt=\"Schematische Darstellung des Software Development Lifecycles.\" loading=\"lazy\" src=\"https:\/\/nvsbl.cm\/media\/pages\/notes\/erste-schritte-mit-einer-definition-of-done\/75db130ddb-1695706609\/sdlc.003.png\"><\/div><figcaption>Die <em>Definition of Ready<\/em> ist f\u00fcr die Aufgaben n\u00fctzlich, die auf Verst\u00e4ndnis und L\u00f6sungsoptionen abzielen. In der Umsetzung hilft dann die <em>Definition of Done<\/em>.<\/figcaption><\/figure>\n<p>Man nutzt den SDLC im Zusammenhang mit der DoD zur Pr\u00fcfung der Zusammenstellung des Development-Teams. Tauchen in der DoD Aufgaben auf, f\u00fcr die dem Team die passende Expertise fehlt, sollte dem nachgegangen werden. Wird das nicht gepr\u00fcft, k\u00f6nnte das Team nicht in der Lage zu sein, seine Aufgabe zu erf\u00fcllen. Es w\u00e4re immer wieder von anderen Teams abh\u00e4ngig, und k\u00f6nnte somit nicht selbst-organisiert arbeiten.<\/p>\n<h2><a name=\"3\"><\/a>#NoEstimates<\/h2>\n<p>Storypoints und T-Shirt-Gr\u00f6\u00dfen, oder Sch\u00e4tzungen der ben\u00f6tigten Zeit sind hart diskutierte Themen. Doch ein eingespieltes Team wird allein anhand der DoD eine sehr gute Sch\u00e4tzung dessen angeben k\u00f6nnen, was es in einem Sprint liefern kann. Ist es aber nicht notwendig, zu wissen, ob Aufgabe A einen halben Tage mehr braucht als Aufgabe B, oder ob Aufgabe C in dreieinviertel Stunden machbar ist? Wozu dient diese Angebe dem Development-Team? Wenn Sie darauf, nat\u00fcrlich mit dem Team, keine gute Antwort finden, warum sollten Sie das Team dann mit der Ermittlung dieser Werte belasten? Weil Scrum, und auch die DoD, immer auf das in einem Sprint Erreichbare schaut.<\/p>\n<p>Ob eine Aufgabe innerhalb eines Sprints l\u00e4nger dauert als eine andere, spielt keine Rolle. Wenn das Team als Teil des Refinements zeitliche Sch\u00e4tzungen abgeben soll, damit Sie als Product-Owern*in das Backlog anhand dieser Angaben sortieren k\u00f6nnen, zum Beispiel um m\u00f6glichst viele Backlog-Items umsetzen zu k\u00f6nnen, verringern Sie im Zweifel den lieferbaren Wert. Selbst wenn das nicht zutr\u00e4fe, es bleibt dabei: Eine Sch\u00e4tzung als explizit angegebener Zeit schafft keine Mehrwert gegen\u00fcber einer implizite Abw\u00e4gung des Teams anhand der DoD.<\/p>\n<p>Zumal \u00fcber das Planning hinaus die explizite zeitliche Sch\u00e4tze keine relevante Kenngr\u00f6\u00dfe mehr ist. F\u00fcr Abweichungen gibt es immer Gr\u00fcnde \u2013 im Zweifel solche, die nicht im Team selbst liegen.<\/p>\n<h2><a name=\"4\"><\/a>Definition of Done im \u00dcberblick<\/h2>\n<p>Die <em>definition of done<\/em> hilft dem Team, den vollen Umfang der n\u00f6tigen Arbeit zu verstehen, die zur Erf\u00fcllung eines Backlogs-Items getan werden muss.<\/p>\n<p>Das ist wichtig f\u00fcr das Team, um einsch\u00e4tzen zu k\u00f6nnen, wie viele beziehungsweise welche Backlog-Items es f\u00fcr einen Sprint ausw\u00e4hlen kann.<\/p>\n<p>Wenn ein Team zum ersten Mal zusammenkommt, um an ihrer DoD zu arbeiten, werden verschiedene Aspekte und Details zur Sprache kommen. Das Team hat die Wahl, sich zu Beginn auf wenige Aspekte zu konzentrieren, in der Regel auf diejenigen, die am meisten mit der Produktqualit\u00e4t zu tun haben. Mit der Zeit wird ein Team an ihrer DoD arbeiten und immer mehr Aspekte einbeziehen. Auf diese Weise hilft ein DoD dem Team, wertvollere Software zu entwickeln. Bestimmte DoD-Angaben, wie im obigen Beispiel \u00bbCode style is met\u00ab, helfen bei der Automatisierung, was wiederum Zeit freir\u00e4umt.<\/p>\n<h2><a name=\"5\"><\/a>Und wenn wir keine DoD haben?<\/h2>\n<blockquote>\n<p>Die <em>definition of done<\/em> hilft, den vollen Umfang der n\u00f6tigen Arbeit zu verstehen, die zur Erf\u00fcllung eines Backlogs-Items getan werden muss.<\/p>\n<\/blockquote>\n<p>Wenn Sie keine DoD haben, m\u00fcssen Sie immer wieder, f\u00fcr jede Aufgabe neu \u00fcberlegen und formulieren, was zu tun ist, um dieses St\u00fcck Arbeit bis zur Releasef\u00e4higkeit zu entwicklen. Das ist anstrengend und fehlerf\u00e4llig. Leicht geht vergessen, dass ja noch Integrationstests machen, Dokumentation zu schreiben, Assets komprimiert, Konfigurationsangaben zu \u00e4ndern sind. Eine Stunde vor dem geplanten Release ist es daf\u00fcr zu sp\u00e4t.<\/p>\n<p>Hat man nicht diese gesamte Arbeit auf dem Schirm, kann das Team auch keine belastbare Aussage \u00fcber den Umfang der im Sprint leistbaren Arbeit treffen. Sprintziele werden nicht erreicht oder es bleibt keine Zeit f\u00fcr Bugfixing, am Ende kann das Team nicht liefern, was es liefern wollte.<\/p>","date_published":"c","date_modified":"Y-m-d\\TH:i:sP"},{"id":"https:\/\/nvsbl.cm\/notes\/software-sollte-nuetzlich-sein","url":"https:\/\/nvsbl.cm\/notes\/software-sollte-nuetzlich-sein","title":"Software sollte n\u00fctzlich sein","content_html":"<p>Das Signal-Rausch-Verh\u00e4ltnis, auch Rauschabstand, von englisch signal-to-noise ratio, ist ein Ma\u00df f\u00fcr die technische Qualit\u00e4t eines Nutzsignals (z. B. Sprache oder Video), das von einem Rauschsignal \u00fcberlagert ist.<\/p>\n<p>Im \u00fcbertragenen Sinne sprechen wir auch von Informationsflut. Gro\u00dfe Mengen (\u201eFlut\u201c) an alten Daten, an neu hinzugef\u00fcgten Daten, Widerspr\u00fcche in vorhandenen Daten und ein niedriges Signal-Rausch-Verh\u00e4ltnis, also ein hohes Rauschen (im \u00fcbertragenen Sinne), machen es schwierig, Informationen zu filtern (= Wichtiges von Unwichtigem und Interessantes von Uninteressantem zu trennen).<\/p>\n<ul>\n<li><a href=\"#1\">Wenn das Rauschen &uuml;berwiegt<\/a><\/li>\n<li><a href=\"#2\">Know-how: Produktivit&auml;t durch Enablement<\/a><\/li>\n<li><a href=\"#3\">Digital Workplace ist mehr als Software-Shopping<\/a><\/li>\n<\/ul>\n<p><a name=\"1\"><\/a><strong>Wenn das Rauschen \u00fcberwiegt<\/strong>, das kennen Sie von Video-Calls und Telefonaten mit schlechter Leitung, muss frau und man umso konzentrierter hinh\u00f6ren. R\u00fcckfragen und Wiederholungen verringern die Informationsweitergabe. Das strengt an und ist fehlerbehaftet.<\/p>\n<figure class=\"figure\"><div class=\"image-wrapper\"><img alt=\"Grafische Darstellung eines Bildschirms mit Signalst\u00f6rung.\" loading=\"lazy\" src=\"https:\/\/nvsbl.cm\/media\/pages\/notes\/software-sollte-nuetzlich-sein\/87ca85c041-1695706610\/signal-noise.jpg\"><\/div><figcaption>\u00bbRauschen, irrelevantes oder st\u00f6rendes Ger\u00e4usch bzw. Schallereignis, das im Vergleich zu L\u00e4rm in seinem Verlauf relativ kontinuierlich in bezug auf Frequenz und Intensit\u00e4t ist, aber zu einer Maskierung der Signale und Fehlern bei der Signal\u00fcbertragung f\u00fchren kann.\u00ab \u2013 <a href=\"https:\/\/www.spektrum.de\/lexikon\/psychologie\/rauschen\/12504\">Lexikon der Psychologie von Spektrum<\/a>.<\/figcaption><\/figure>\n<p>Das liegt daran, dass es f\u00fcr das Gehirn Schwerstarbeit ist, das Signal aus dem Rauschen zu filtern. Es muss zwei Aufgaben gleichzeitig bew\u00e4ltigen: Erkennen und Ignorieren des Rauschens, Erkennen und Verarbeiten des Signals. Das kostet Kraft, Nerven, und ist ineffizient.<\/p>\n<p>Jetzt schauen Sie sich die Software-Tools an, die Sie und Ihre Teams im Einsatz haben. Die Tools, mit denen t\u00e4glich gearbeitet wird. JIRA oder Asana zum Beispiel. Achten Sie darauf, wie viel Raum auf dem Bildschirm, wie viel \u00bbscreen estate\u00ab, die relevante Information einnimmt.<\/p>\n<p>Es ist schreckend wenig. In diesem Beispiel hier haben wir 1,9 % Signal gegen 98,1 % Rauschen. Das kostet Kraft, Nerven, und ist ineffizient.<\/p>\n<h2><a name=\"2\"><\/a>Know-how: Produktivit\u00e4t durch Enablement<\/h2>\n<p>Was haben Sie getan, um sich selbst und Ihre Mitarbeiter:innen zu bef\u00e4higen, die eingesetzten Tools zu nutzen und ihren Mehrwert zu heben?<\/p>\n<p>Je teurer die Software ist, desto eher geh\u00f6ren zur Einf\u00fchrung oder neuen Versionen auch Schulungen. Doch die in der Breite eingesetzte Software kommt regelm\u00e4\u00dfig zu kurz. Ob als \u00bbzu teuer\u00ab oder \u00bbzu banal\u00ab abgetan, hier liegen ungenutzte Potenziale. Produktiver Umgang mit digitalen Werkzeugen ist keine Kleinigkeit. Neben der reinen Bedienung, \u00bbwo muss ich wann klicken\u00ab, geht es im Kern auch immer um Orientierung zwischen den Tools und in den Tools. Wie greifen sie ineinander? Wie m\u00fcssen wir sie einsetzen, damit sie uns Arbeit abzunehmen statt mehr Arbeit zu machen?<\/p>\n<p>Im Enablement geht es um Wege, die eigenen Ziele zu erreichen, ohne zu gro\u00dfer Frustration ausgesetzt zu werden. So kann kurzfristig Akzeptanz entstehen \u2013 \u00bbAh, so geht das!\u00ab \u2013 und auf Dauer Meisterschaft \u2013 \u00bbWenn ich X mit Y so kombiniere, kann sich mein gesamtes Team Z sparen!\u00ab<\/p>\n<h2><a name=\"3\"><\/a>Digital Workplace ist mehr als Software-Shopping<\/h2>\n<p>Interessieren Sie sich als F\u00fchrungskraft f\u00fcr das Handwerkszeug Ihrer Teams? Achten Sie darauf, ob die Software n\u00fctzlich ist, und ob sie nutzbringend eingesetzt wird? F\u00fcr Sie als F\u00fchrungskraft ist die Frage der eingesetzten Software essentiell. In unserer Arbeitswelt ist Software nicht nur das Arbeitsergebnis, sondern auch das wichtigste Arbeitsmittel. Quasi jede arbeitsrelevante Aufgabe wird mit Software erledigt. Einige von Ihnen verdienen damit sogar Ihr Geld. Wir produzieren nicht nur Software, und nehmen damit Einfluss auf den Arbeitsalltag anderer, wir sind dem gleichen Einfluss ausgesetzt.<\/p>\n<figure class=\"figure\"><div class=\"image-wrapper\"><img alt=\"Screenshot der Projektmanagement-Software Asana mit einem beispielhaften Kanban-Board.\" loading=\"lazy\" src=\"https:\/\/nvsbl.cm\/media\/pages\/notes\/software-sollte-nuetzlich-sein\/694f282435-1695706610\/asana-screen-estate.jpg\" title=\"1,9 %\"><\/div><figcaption>Die eigentliche Information nimmt hier minimalen Raum ein.<\/figcaption><\/figure>\n<p>Als F\u00fchrungskr\u00e4fte sind wir f\u00fcr die Arbeits-Infrastruktur <a href=\"https:\/\/nvsbl.cm\/notes\/die-wirksamkeit-anderer-jenseits-von-heldentum\">verantwortlich<\/a>. Wir k\u00f6nnen uns der inhaltlichen Diskussion um Slack vs. MS Teams, GitLab vs GitHub oder Asana vs Trello nicht entziehen. Im Gegenteil, wir sollten sie moderieren. Nach Nutzen fragen, nach N\u00fctzlichkeit, nach dem Rauschabstand.<\/p>","date_published":"c","date_modified":"Y-m-d\\TH:i:sP"},{"id":"https:\/\/nvsbl.cm\/notes\/aus-dem-echten-leben-real-life-scrum-master-stories","url":"https:\/\/nvsbl.cm\/notes\/aus-dem-echten-leben-real-life-scrum-master-stories","title":"Aus dem echten Leben","content_html":"<p>Carpie diem. Ich habe den Juli f\u00fcr ein Experiment benutzt. Zwischenstand: <a href=\"https:\/\/nv.sb\/20bt\">Ein ver&ouml;ffentlichtes Buch.<\/a> \ud83d\ude80\ud83d\udcaa\ud83d\ude0e<\/p>\n<figure class=\"figure\">\n<div class=\"image-wrapper\" style=\"-webkit-user-select: auto;-webkit-box-shadow: 5px 5px 10px 0px rgba(0,0,0,0.5);-moz-box-shadow: 5px 5px 10px 0px rgba(0,0,0,0.5);box-shadow: 5px 5px 10px 0px rgba(0,0,0,0.5);:hover {box-shadow: 5px 5px 10px 0px #feeb35;}\">\n<a href=\"https:\/\/nv.sb\/20bt\" title=\"Das Buch ist in allen E-Book-Shops erh\u00e4ltlich.\"><img src=\"https:\/\/nvsbl.cm\/media\/pages\/notes\/aus-dem-echten-leben-real-life-scrum-master-stories\/ca59340435-1599126095\/e-book-banner.jpg\" alt=\"Banner mit Link zu Kauf-M\u00f6glichkeit\"><\/a>\n<\/div><\/figure>\n<p>Es begann mit der Idee, Situationen aus meiner Erfahrung als Scrum-Master aufzuschreiben. Dazu packte ich L\u00f6sungsvorschl\u00e4ge, mein Vorgehen in diesen echten Situationen. Mit einem Tweet und einem LinkedIn-Post konnte ich in der ersten Woche 120 Exemplare verkaufen. W\u00e4hrend ich das tippe steht der Z\u00e4hler bei 250. \ud83e\udd2f<\/p>\n<p>Ok, es gibt hier eine Nachfrage.<\/p>\n<p>N\u00e4chstes Experiment: Als Erweiterung des Decks habe ich zu jedem Kapitel eine Anmerkung geschrieben. Sie erl\u00e4utert den L\u00f6sungsansatz, bezugnehmend auf die Scrum-Werte, Team-Rollen, Nexus, die agilen Prinzipien, und weitere Quellen. Die gibt es als kommentierte Liste von Literaturempfehlungen mit Autor*innen, die deinen Horizont erweitern werden, noch dazu.<\/p>\n<figure class=\"figure\"><div class=\"image-wrapper\"><img alt=\"Cover des Buchs.\" loading=\"lazy\" src=\"https:\/\/nvsbl.cm\/media\/pages\/notes\/aus-dem-echten-leben-real-life-scrum-master-stories\/8f652c7df3-1695706609\/20-brainteaser-fur-scrum-master-nvbsl.jpg\"><\/div><figcaption>20 Situationen und Fragen, die dein Wissen, deine Erfahrung und dein Gef\u00fchl f\u00fcr dich in der Rolle als Scrum-Masterin herausfordern.<\/figcaption><\/figure>\n<ul>\n<li>\u275320 Brainteaser\u2029<\/li>\n<li>\u2757\ufe0f20 L\u00f6sungsvorschl\u00e4ge<\/li>\n<li>\ud83d\udca120 Erl\u00e4uterungen zu den L\u00f6sungsvorschl\u00e4gen<\/li>\n<li>Quellen-Angaben<\/li>\n<li>Interessante Autorinnen<\/li>\n<\/ul>\n<p>In 20 Kapiteln beleuchten wir Fragen zu:<\/p>\n<ul>\n<li>Team-Aufbau<\/li>\n<li>Sprint-Planung<\/li>\n<li>Sprint-Reviews<\/li>\n<li>Sprint-Retrospektiven<\/li>\n<li>Dailys<\/li>\n<li>der empirischen Theorie hinter Scrum<\/li>\n<\/ul>\n<p><a href=\"https:\/\/webreader.mytolino.com\/reader\/index.html?epuburl=https:\/\/cdp.pageplace.de\/cdp\/public\/publications\/DT0400\/9783752981025_A40176177\/PREVIEW\/leseprobe-9783752981025_A40176177.epub&amp;purchaseurl=https:\/\/www.buecher.de\/go\/cart_cart\/cart_add_item\/prod_id\/59895050\/&amp;lang=de_DE&amp;reseller=30\">Leseprobe mit vollst&auml;ndigem Probekapitel.<\/a><\/p>\n<p>\u00bb20 Brainteaser f\u00fcr Scrum-Masterinnen\u00ab, das sind 20 Situationen, die dein Wissen, deine Erfahrung und dein Gef\u00fchl f\u00fcr dich in der Rolle als Scrum-Masterin herausfordern. Die Fragen helfen beim Selbststudium und funktionieren gemeinsam mit Kolleg*innen.<\/p>\n<p>Ich verwende in diesem Buch ausschlie\u00dflich die feminine Schreibweise.<\/p>\n<p>Wenn dir die Brainteaser ausreichen: das urspr\u00fcngliche \u00bbScrum Master Deck\u00ab <a href=\"https:\/\/nv.sb\/adel\">ist weiterhin erh&auml;ltlich<\/a>.<\/p>","date_published":"c","date_modified":"Y-m-d\\TH:i:sP"},{"id":"https:\/\/nvsbl.cm\/notes\/pace-cadence-von-durchsatz-und-takt","url":"https:\/\/nvsbl.cm\/notes\/pace-cadence-von-durchsatz-und-takt","title":"Pace & Cadence \u2013 von Durchsatz und Takt","content_html":"<p>Ein erfolgreiches Team ist in der Lage, \u00fcber lange Zeit regelm\u00e4\u00dfig Wert zu schaffen. Das gelingt durch Routinen, gleichm\u00e4\u00dfige Anstrengung und Rhythmus.<\/p>\n<p>Kurz vor der Deadline 14-Stunden-Tage abzurei\u00dfen, Terminverschiebungen f\u00fcr Regeltermine, starke Auslastungsschwankungen, all das sind eher schlechte Angewohnheiten. Kurzfristig mag ein Team in diesem Rahmen erfolgreich sein. Auf Dauer aber f\u00fchren diese Effekte zu Frustration, Vertrauensverlust, zu einem Verlust an Verantwortungsgef\u00fchl und zu einem starken Abfall der Produktivit\u00e4t. Nicht, weil das Team schlechter wird, sondern weil die Rahmenbedingungen die Gruppe daran hindert, ihr Potenzial auszuspielen. In XP (Extreme Programming) und Scrum sprechen wir daher von einer nachhaltigen, durchhaltbaren, gleichm\u00e4\u00dfigen Geschwindigkeit, in der Teams in festen Takten arbeiten k\u00f6nnen: in einen regelm\u00e4\u00dfigen und leicht zu merkenden zeitlichen Ablauf.<\/p>\n<figure class=\"figure\"><div class=\"image-wrapper\"><img alt=\"Ein Metronom.\" loading=\"lazy\" src=\"https:\/\/nvsbl.cm\/media\/pages\/notes\/pace-cadence-von-durchsatz-und-takt\/3e78d40051-1695706610\/takt.jpg\"><\/div><figcaption>Die Einhaltung des Takts ist effizient: es ist wertvoller, die Zeit mit produktiver Arbeit als mit Abstimmungen zur Synchronisierung zu verbringen.<\/figcaption><\/figure>\n<p>Ein Beispiel daf\u00fcr ist der oben stehenden Kalender f\u00fcr Sprints von zwei Wochen Dauer. Entscheidend dabei ist die Verantwortung aller f\u00fcr die Einhaltung der Regelm\u00e4\u00dfigkeit. Es ist grunds\u00e4tzlich keine gute Idee, zum Beispiel das Planning um einen Tag zu verschieben oder die Retro vorzuverlegen. Es mag f\u00fcr die einzelne Person so besser passen. Agilit\u00e4t ist ein Teamsport, und daher immer R\u00fccksicht auf die Befindlichkeiten der anderen zu nehmen. Selbst wenn sich alle einig w\u00e4ren: Jede Abweichung vom Kalender f\u00fchrt zu einem Kaskadeneffekt weiterer \u00c4nderungen. Die Einhaltung des Takts ist effizient: es ist wertvoller, die Zeit mit produktiver Arbeit als mit Kalenderabgleichen zu verbringen.<\/p>\n<figure class=\"figure\"><div class=\"image-wrapper\"><img alt=\"Kalender-Ansicht eines zweiw\u00f6chigen Sprints.\" loading=\"lazy\" src=\"https:\/\/nvsbl.cm\/media\/pages\/notes\/pace-cadence-von-durchsatz-und-takt\/ddb0056786-1695706610\/scrum-calendar.jpg\" title=\"Ein Sprint folgt dem immer gleichen Kalender.\"><\/div><figcaption>Dieser Kalender zeigt den Ablauf eines zwei-w\u00f6chigen Sprints.<\/figcaption><\/figure>\n<p>Den Sprint-Kalender gibt es als <a download href=\"https:\/\/nvsbl.cm\/media\/pages\/notes\/pace-cadence-von-durchsatz-und-takt\/a316f13b8c-1695706610\/scrum-kalendar.pdf\">kostenlosen Download<\/a> f\u00fcr zwei-, drei und vier-w\u00f6chige Sprints.<\/p>\n<p>Hat man sich einmal geeinigt, dass die dreiw\u00f6chigen Sprints dienstags beginnen, ist damit alles festgelegt: alle drei Wochen montags Review und Retro, darauf folgend dienstags Planning. Das merkt man sich einmal und muss nie mehr wieder dar\u00fcber nachdenken. F\u00fcr das Daily gilt das entsprechend. Kann ein Teammitglied nicht teilnehmen (krank, privater Termin, Urlaub etc.) hat es selbst Sorge zu tragen, dass seine Meinung vertreten wird.<br \/>\nF\u00fcr Personen, die diese festen Takte nicht gewohnt sind, f\u00e4llt die Umstellung schwer. Sie m\u00f6gen es als das Gegenteil von \u00bbagil\u00ab empfinden, wenn auf ihre W\u00fcnsche keine R\u00fccksicht genommen wird. Sind diese Personen nicht Teil des Scrum-Teams k\u00f6nnen Sie kaum Einfluss auf die Selbstorganisation nehmen. Tun sie es, vielleicht dank ihrer hierarchischen Stellung, doch, wirkt sich das \u00e4u\u00dferst negativ auf die Selbstorganisation des Teams aus.<\/p>\n<p>Statt sich auf Terminverschiebungen oder unregelm\u00e4\u00dfige Arbeitsbelastung einlassen zu m\u00fcssen, erm\u00f6glichen gleichm\u00e4\u00dfige Geschwindigkeit und vorhersehbare Ereignisse dem Team sich mit dem zu besch\u00e4ftigen, worum es eigentlich geht: dem Produkt. Einfach Viel zu arbeiten, hei\u00dft nicht gut, oder an der richtigen Sache zu arbeiten. Der Takt agiler Arbeit wird zwar vom Sprint-Kalender vorgegeben, doch das Ziel ist nicht die Einhaltung der Termine. Jeden Sprint mit einem release-baren Produkt-Inkrement zu beenden, darum geht es. Im besten Fall sogar mit einem Release.<\/p>\n<p>Pace und Cadence, oder Durchsatz und Takt, sind essenzielle Bauteile, auf denen Agilit\u00e4t aufsetzt. Trimmen wir unsere Teams zuerst auf Durchsatz, und geben ihnen dann die Mittel, sich selbstbestimmt zu takten? Nein, anders herum nat\u00fcrlich. Durchsatz folgt aus Takt.<\/p>","date_published":"c","date_modified":"Y-m-d\\TH:i:sP"},{"id":"https:\/\/nvsbl.cm\/notes\/wenn-fortschritt-in-features-gemessen-wird","url":"https:\/\/nvsbl.cm\/notes\/wenn-fortschritt-in-features-gemessen-wird","title":"Fortschritt in Features messen","content_html":"<p>Sie sind als Product Owner teil eines Scrum-Teams. Frisch im Unternehmen und mit den positiven Eindr\u00fccken des Bewerbungsverfahrens gehen Sie ans Werk. Und stellen nach und nach fest, dass es hier mit Selbst-Organisation nicht so weit her ist. Zun\u00e4chst war es nur die Bitte, ein Features in den laufenden Sprint aufzunehmen.<br \/>\nEs stellt sich heraus, dass es im Unternehmen vor allem darum geht, Features zu liefern. Je mehr Features, desto wertvoller die Software. Sie sind in einer <strong>Feature-Factory<\/strong> gelandet.<\/p>\n<p><strong>Inhalt:<\/strong><\/p>\n<ul>\n<li><a href=\"#po\">Ihre Aufgabe als Product Owner<\/a><\/li>\n<li><a href=\"#kosten\">Sprint-Kosten in Relation zum erwarteten Ergebnis<\/a><\/li>\n<li><a href=\"#cost-of-delay\">Wie viel ein Sprint kostet<\/a><\/li>\n<li><a href=\"#kundenzentrizitaet\">Kundenzentrizit\u00e4t<\/a><\/li>\n<\/ul>\n<figure class=\"figure\"><div class=\"image-wrapper\"><img alt=\"Grafische Darstellung eines Flie\u00dfbands.\" loading=\"lazy\" src=\"https:\/\/nvsbl.cm\/media\/pages\/notes\/wenn-fortschritt-in-features-gemessen-wird\/3d38b9b62e-1695706610\/feature-factory.jpg\"><\/div><figcaption>In der Feature-Factory geht es nicht um Ergebnisse, sondern, wie am Flie\u00dfband, um geleistete Arbeit.<\/figcaption><\/figure>\n<h2><a name=\"po\"><\/a>Ihre Aufgabe als Product Owner<\/h2>\n<p>Als Product Owner versuchen Sie, Einfluss darauf zu nehmen. Immerhin nehmen Sie Ihren Job ernst und f\u00fchlen sich daf\u00fcr verantwortlich, den Wert des Produktes zu maximieren, das aus der Arbeit des Entwicklungsteams entsteht.<br \/>\nDoch die Stakeholder messen Ihre Arbeit eher an termingerechter Lieferung der versprochenen Features. Was tun?<br \/>\nMachen Sie es den Stakeholdern einfach, Ihren Feature-Glauben abzulegen, in dem Sie Ihre Sprache sprechen. Lassen Sie Zweifel am Glauben an der Wertsch\u00f6pfung durch fristgerechte Lieferung entstehen. Leiten Sie sie dahin, Features nicht an Terminen, sondern am Ergebnis zu bewerten.<\/p>\n<h2><a name=\"kosten\"><\/a>Sprint-Kosten in Relation zum erwarteten Ergebnis<\/h2>\n<p>Dazu kann man sich an vergangenen Situationen orientieren und zum Beispiel diskutieren:<\/p>\n<ul>\n<li>Wie oft wird Feature X tats\u00e4chlich benutzt?<\/li>\n<li>Wird es selten genutzt, aber ein wichtiger Hygiene-Faktor, oder passt es nicht zu Ihren Kunden?<\/li>\n<li>Welche regelm\u00e4\u00dfigen Kosten verursacht es?<\/li>\n<li>Wie hoch waren die Entwicklungskosten des Features?<\/li>\n<li>Wie hoch war die Cost of Delay by Duration dieses Features, mit anderen Worten, wie viel Umsatz konnte nicht realisert werden, weil ein besseres Feature erst sp\u00e4ter entwickelt werden konnte?<\/li>\n<\/ul>\n<p>Letztlich f\u00fchren diese Fragen zu einer Diskussion \u00fcber den erwarteten Wert der Features im Vergleich untereinander und in Relation zu den Kosten eines Sprints.<\/p>\n<h2><a name=\"cost-of-delay\"><\/a>Wie viel ein Sprint kostet<\/h2>\n<p>Zun\u00e4chst die Personalkosten: die Geh\u00e4lter der Scrum-Team-Mitglieder. Aus der Diskussion \u00fcber den Wert der Features kennen Sie au\u00dferdem die Kosten, die durch sp\u00e4tere Lieferung eines Features entstehen.<\/p>\n<ul>\n<li>Kosten eines Sprints (Monatsgeh\u00e4lter von 8 Personen): \u20ac 50.000<\/li>\n<li>Feature A: \u20ac 10.000 mehr Umsatz nach Fertigstellung \u00fcber einen Sprins<\/li>\n<li>Feature B: \u20ac 15.000 mehr Umsatz nach Fertigstellung \u00fcber drei Sprints<\/li>\n<li>Feature C: \u20ac 25.000 mehr Umsatz nach Fertigstellung \u00fcber zwei Sprints<\/li>\n<\/ul>\n<figure class=\"figure\"><div class=\"image-wrapper\"><img alt=\"Kosten und Ersparnis bei Priorisierung nach Umsatz.\" loading=\"lazy\" src=\"https:\/\/nvsbl.cm\/media\/pages\/notes\/wenn-fortschritt-in-features-gemessen-wird\/6d20b5ccf0-1695706610\/prio-nach-umsatz.png\"><\/div><figcaption>Auf den Umsatz zu achten f\u00fchrt nicht immer zu den besten Entscheidungen.<\/figcaption><\/figure>\n<figure class=\"figure\"><div class=\"image-wrapper\"><img alt=\"Kosten und Ersparnis bei Priorisierung nach Umsetzungsdauer.\" loading=\"lazy\" src=\"https:\/\/nvsbl.cm\/media\/pages\/notes\/wenn-fortschritt-in-features-gemessen-wird\/562dbd0acc-1695706610\/prio-nach-zeit.png\"><\/div><figcaption>Die Umsetzungdauer spielt durchaus eine Rolle.<\/figcaption><\/figure>\n<figure class=\"figure\"><div class=\"image-wrapper\"><img alt=\"Kosten und Ersparnis bei Priorisierung nach Cost of Delay by Duration.\" loading=\"lazy\" src=\"https:\/\/nvsbl.cm\/media\/pages\/notes\/wenn-fortschritt-in-features-gemessen-wird\/3e2f30c14b-1695706610\/prio-nach-cost-of-delay-by-duration.png\"><\/div><figcaption>Erst wenn man die Umsatzausf\u00e4lle berachtet, findet man das optimale Ergebnis.<\/figcaption><\/figure>\n<h2><a name=\"kundenzentrizitaet\"><\/a>Kundenzentrizit\u00e4t<\/h2>\n<p>Hier sind wir inmitten der Product-Owner-Kernaufgabe, n\u00e4mlich den Wert des Produktes zu maximieren, das aus der Arbeit des Entwicklungsteams entsteht.<\/p>\n<blockquote>\n<p>Jetzt messen wir Fortschritt nicht mehr in Features, sondern in geschaffenem Wert.<\/p>\n<\/blockquote>\n<p>Diese Basiszahlen sind die Grundlage f\u00fcr viele spannende Diskussionen zur Rentabilit\u00e4t, dem ROI, zu Headcount. Sie er\u00f6ffnen den Weg zu relevanterem Controlling (\u00bbBeyond Budgeting\u00ab) und sind doch nur die interne Sicht der Kundenzentrizit\u00e4t.<\/p>","date_published":"c","date_modified":"Y-m-d\\TH:i:sP"},{"id":"https:\/\/nvsbl.cm\/notes\/machen","url":"https:\/\/nvsbl.cm\/notes\/machen","title":"Komplexit\u00e4t und \u00bbBest Practice\u00ab","content_html":"<p>W\u00fcrden Sie den folgenden Satz unterschreiben?: \u00bbEin komplexes Problem hat keine einfache L\u00f6sung.\u00ab<\/p>\n<p><strong>Inhalt:<\/strong><\/p>\n<ul>\n<li><a href=\"#best-practice\">Keine Best Practices<\/a><\/li>\n<li><a href=\"#iteration\">Verbesserung in kleinen Schritten<\/a><\/li>\n<li><a href=\"#risiko-vermeidung\">Vermeintliche Risikominimierung<\/a><\/li>\n<li><a href=\"#hypothesen\">Professionelle Nichtwissende<\/a><\/li>\n<\/ul>\n<h2><a name=\"best-practice\"><\/a> Keine Best Practices<\/h2>\n<p>\u00bbAnekdotenhaft wissen wir, dass in Stein gemei\u00dfelte Formalien genau in dem Moment den Weg verstellen, in dem wir es am wenigsten gebrauchen k\u00f6nnen. Wenn wir von komplexen Situationen sprechen, sagen wir damit implizit, dass wir sie nicht regeln k\u00f6nnen.\u00ab<\/p>\n<p>So heisst es im <a href=\"https:\/\/nvsbl.cm\/notes\/manifest-fuer-effektives-management\">Manifest f\u00fcr wirksames Management<\/a>. Nicht regeln zu k\u00f6nnen bedeutet hier, keiner L\u00f6sungsanleitung folgen zu k\u00f6nnen.<\/p>\n<p>Das ist ja auch logisch, bedenkt man die Eigenschaften einer komplexen Situation: Es gibt keine L\u00f6sung, die jedes Vorkommen des Problem l\u00f6st. Es gibt keine Handlungsanweisung, die zum immer gleichen Ergebnis f\u00fchrt. Das sind Aspekte komplizierter Situationen, in denen es unver\u00e4nderliche Regeln gibt, die auf die Akteure einwirken. In komplexen Situationen kann alles auf alles Einfluss nehmen, Regeln ver\u00e4ndern sich st\u00e4ndig. Ein gestern als Best Practice gefeiertes Vorgehen muss heute scheitern \u2013 und wir k\u00f6nnen nur nachtr\u00e4glich erkennen, warum.<\/p>\n<h2><a name=\"iteration\"><\/a> Verbesserung in kleinen Schritten<\/h2>\n<p>Stattdessen geht es um viele kleine Schritte, die sich nicht \u00fcberschneiden sollten, damit man ihre Effekte messen kann. Das ist gemeint, wenn von Iterationen oder Inspect &amp; Adapt gesprochen wird. Das Muster ist dabei immer gleich:<\/p>\n<ol>\n<li>Situationsanalyse<\/li>\n<li>Problemeingrenzung<\/li>\n<li>Hypothesen bilden, Alternativen aufzeigen<\/li>\n<li>Tragweite analysieren \u2013 Chancen und Risiken absch\u00e4tzen<\/li>\n<li>L\u00f6sungsauswahl<\/li>\n<li>Entscheidung<\/li>\n<li>Umsetzung<\/li>\n<li>Nachbereitung und Lernen<\/li>\n<\/ol>\n<p>Diese Schritte helfen auch bei der <a href=\"https:\/\/nvsbl.cm\/notes\/wirksame-meetings\">Fokussierung in Meetings<\/a>.<\/p>\n<blockquote>\n<p>Warum greifen wir, obwohl wir den passenderen Weg kennen, so oft zum Dampfhammer und <strong>machen einfach<\/strong>?<\/p>\n<\/blockquote>\n<figure class=\"figure\"><div class=\"image-wrapper\"><img alt=\"Wecker, der auf f\u00fcnf vor zw\u00f6lf steht.\" loading=\"lazy\" src=\"https:\/\/nvsbl.cm\/media\/pages\/notes\/machen\/7c1eec4a1e-1695706610\/uhr.jpg\" title=\"Zeit ist Geld, machen Sie endlich!\"><\/div><figcaption>\u00bbZeit ist Geld, machen Sie endlich!\u00ab \u2013 Wer VUCA sagt, muss Zeit mitbringen. Alles andere ist Theater.<\/figcaption><\/figure>\n<blockquote>\n<p>Wer VUCA sagt, muss Zeit mitbringen. Alles andere ist Theater.<\/p>\n<\/blockquote>\n<h2><a name=\"risiko-vermeidung\"><\/a> Vermeintliche Risikominimierung<\/h2>\n<p>Vielleicht sind wir einfach so gestrickt. Es kostet Disziplin, sich f\u00fcr eine Ma\u00dfnahme zu entscheiden und abzuwarten. Dem gegen\u00fcber steht der Wunsch, so schnell wie m\u00f6glich das beste Ergebnis zu erzielen. Was, wenn die entschiedene Ma\u00dfnahme nicht den gew\u00fcnschten Effekt hat? Haben wir versagt? Lieber drei Dinge gleichzeitig mit h\u00f6herer Chance, dass eines z\u00fcndet!<\/p>\n<p>Diese Situation kennen wir alle. Und wir wissen auch, wie sie enden wird. Das Problem verlagert sich, niemand kann sagen, welche Ma\u00dfnahme wie viel Anteil daran hatte, und das Theater geht von vorne los.<\/p>\n<h2><a name=\"hypothesen\"><\/a> Professionelle Nichtwissende<\/h2>\n<p>Ich hatte Anfang des Jahres das Privileg mit dem Berliner Service-Design-Studio Dayone zu arbeiten. Dayone bildet Hypothesen und testet sie. Nico Wohlgemuth sagt \u00fcber sein Studio: \u00bbWir sind professionelle Nichtwissende.\u00ab<\/p>\n<p>Und das finde ich eine gro\u00dfartige Haltung. Sie verbindet viele wichtige Themen. Aus der Achtsamkeit die Haltung des Anf\u00e4ngergeists, aus agilem Vorgehen die Idee der Iteration in kleinen Schritten, aus der Systemtheorie die unvorhersehbare Ver\u00e4nderung durch Handlung.<\/p>\n<p>Als Agile Coach f\u00fcr F\u00fchrungskr\u00e4fte gehe ich mit Ihnen nicht mehr, sondern die wertvolleren Schritte.<\/p>","date_published":"c","date_modified":"Y-m-d\\TH:i:sP"},{"id":"https:\/\/nvsbl.cm\/notes\/die-eigene-wirksamkeit","url":"https:\/\/nvsbl.cm\/notes\/die-eigene-wirksamkeit","title":"Die eigene Wirksamkeit","content_html":"<p>Management \u00fcberf\u00fchrt Arbeit in Leistung. Steigt die Leistung, haben Sie wirksam gemanagt. Wenn ich von Ihrer Wirksamkeit als Manager spreche, meine ich zwei Aspekte jenseits der Modeerscheinungen, die Management plagen.<\/p>\n<ol>\n<li><a href=\"https:\/\/nvsbl.cm\/notes\/die-wirksamkeit-anderer-jenseits-von-heldentum\">Der Wirksamkeit der Personen, die durch Ihre Entscheidungen Wirksamkeit erlangen.<\/a><\/li>\n<li>Ihre pers\u00f6nliche Wirksamkeit. (Dieser Artikel.)<\/li>\n<\/ol>\n<h2>Ihre Wirksamkeit<\/h2>\n<figure class=\"figure\"><div class=\"image-wrapper\"><img alt=\"Grafische Darstellung dreier Menschen, einer l\u00e4uft einer einer gro\u00dfen Kugel, zwei  Menschen tragen schwer an je einer.\" loading=\"lazy\" src=\"https:\/\/nvsbl.cm\/media\/pages\/notes\/die-eigene-wirksamkeit\/22ff5b1663-1695706609\/eigene-wirksamkeit.jpg\"><\/div><figcaption>Wirksamkeit erkennt man an der F\u00e4higkeit, sich nicht unn\u00f6tig mit Aufgaben zu belasten.<\/figcaption><\/figure>\n<blockquote>\n<p>Sie sind in Ihrer Rolle wirksam, wenn Sie den Spagat zwischen Selbstorganisation und Command&amp;Control meistern, und Entscheidungen situativ treffen k\u00f6nnen\/lassen.<\/p>\n<\/blockquote>\n<p>So der Ausblick aus dem letzten Artikel der Serie. Schnell rekapituliert: Ihre Aufgabe besteht darin, Rahmenbedingungen f\u00fcr bestm\u00f6gliche Entscheidungen und Informationsfl\u00fcsse zu schaffen. Um St\u00f6rfunk einzud\u00e4mmen, m\u00fcssen Sie notfalls Kontrolle \u00fcber Teile der Organisation \u00fcbernehmen k\u00f6nnen. Sie werden vom Entscheider zum Infrastruktur-Anbieter. Bisher haben wir diese Entscheidungs- und Kommunikationsinfrastruktur aus Sicht derer betrachtet, die sie benutzen. Nun stellen wir Sie in den Blickpunkt.<\/p>\n<p>In der Command&amp;Control-Welt werden Sie in erster Linie an Ihren Entscheidungen \u2013 und erst zweitrangig an deren Resultaten[^Gutes Management hat sich schon immer durch maximal erreichbare Ergebnisse ausgezeichnet. An den Grundaufgaben eines Managers hat sich dementsprechend auch nichts ver\u00e4ndert. Heute gelangen schlechtere Manager schneller an ihre Grenzen, und bessere Manager stechen schneller heraus. Es scheint auch einen Trend weg von kurzfristigen Maximalerfolgen hin zu l\u00e4ngerfristig erfolgreicherem Handeln zu geben.] \u2013 gemessen. Zumeist von denen, die in der <a href=\"\/notes\/hierarchie-in-unternehmen\">Hierarchie<\/a> \u00fcber Ihnen stehen. In einer selbstorganisierten Welt treffen Sie diese Entscheidungen nicht, k\u00f6nnen also nicht an ihnen gemessen werden. Hier werden Sie anhand der Ergebnisse derer bewertet, die Ihre Rahmenarbeit nutzen. Je besser das Gesamtergebnis, desto gr\u00f6\u00dfer Ihre Wirksamkeit.<\/p>\n<p>Um das bestm\u00f6gliche Ergebnis der in Ihrem Verantwortungsbereich arbeitenenden Menschen zu erreichen, muss die erw\u00e4hnte Entscheidungs- und Kommunikationsinfrastruktur dauerhaft widerstandsf\u00e4hig bleiben.<\/p>\n<h2>Wirkungsbreite \u2013 Aufmerksamkeit verteilen<\/h2>\n<p>Management-Infrastruktur in diesem Sinne eignen sich nicht f\u00fcr die gleichen Ma\u00dfnahmen, mit denen zum Beispiel der Zustand von Stra\u00dfen <a href=\"https:\/\/w.itst.org\/share\/5fcf7daa9a3716.52635607\">\u00fcberpr\u00fcft<\/a> wird. Was Sie stattdessen braucht es ein flexibles, mehrschichtiges Netz, dass Ihnen Hinweise gibt, wohin Sie gerade schauen sollten.<\/p>\n<blockquote>\n<p>Entscheidend f\u00fcr Ihren Erfolg [\u2026] sind Ihre Beziehungen zu anderen Menschen.<\/p>\n<\/blockquote>\n<p>Bleiben wir bei dem Bild der Stra\u00dfenwacht. Neben Kontrollfahrten k\u00f6nnen sich die Kolleginnen und Kollegen dort auf technische Hilfsmitteln wie Kameras oder IoT-Sensoren verlassen. F\u00fcr Sie gilt das nicht. Ihr Netz ist ein rein menschliches <a href=\"\/notes\/ohne-gehts-nicht\">Beziehungsnetz<\/a>.<\/p>\n<p>Gute Beziehungen, damit sind nicht Seilschaften gemeint, sondern gutes Auskommen mit, gute Verh\u00e4ltnisse zu Ihnen direkt und indirekt zugeordnete Menschen, die Kollegschaft auf gleicher Ebene, Ihnen direkt und indirekt vorgesetzte Menschen, sowie Kunden und Partnern au\u00dferhalb des Unternehmens. Diese Menschen stehen f\u00fcr Inhalte, Politik, Projekte, Teams, Produkte, Macht und Erwartungen.<\/p>\n<p>Es gibt kein ideales Netz, das f\u00fcr jeden gleich relevant ist. Nach welchem Prinzip das Netz Signale \u00fcbertragen soll, ist aber klar: Je gr\u00f6\u00dfer die Auswirkung, und je h\u00f6her die Wahrscheinlichkeit f\u00fcr extremen (Miss-)Erfolg, desto st\u00e4rker muss das Netz vibrieren. Denn nat\u00fcrlich k\u00f6nnen Sie nicht \u00fcberall zur gleichen Zeit sein, und Sie k\u00f6nnen auch nicht jedes Signal selbst analysieren. Das ist der Grund, warum <a href=\"\/notes\/die-wirksamkeit-anderer-jenseits-von-heldentum\">Delegation<\/a> nicht ausreicht. Gestatten Sie sich selbst, nicht alles zu wissen oder wissen zu m\u00fcssen. Es gen\u00fcgt zu wissen, wer es wei\u00df.<\/p>\n<p>Ihr Netz sendet Ihnen st\u00e4ndig Signale. Jedes Signal verlangt nach Ihrer Aufmerksamkeit. Doch worauf sofort reagieren? Auf so wenig wie m\u00f6glich. So haben Sie immer Kapazit\u00e4ten f\u00fcr die st\u00e4rksten Vibrationen, und bleiben in der Lage, <a href=\"\/notes\/nein-sagen-um-ja-sagen-zu-koennen\">agieren zu k\u00f6nnen<\/a>.<\/p>","date_published":"c","date_modified":"Y-m-d\\TH:i:sP"}]}