Welche Fehler habe ich schon in den Projekten gemacht, die Sie nicht mehr machen müssen ist das Schwerpunktthema des Monats Februar. Ein Fehler, das mir schon mal passiert ist, ist, dass die Prozesse nicht konsequent genug umgestellt wurden. Ein typisches Thema ist das Thema Excel-free. Es kommt schon vor, dass ein Prozess nicht knackig genug ist, häufig zu lang ist und die Kommunikation zwischen Anwendern und Softwareentwicklern oft sehr indirekt ist und letztendlich kommt auch nicht die optimale Lösung raus. Aus diesem Grund lohnt es sich den Blick auf die sogenannten „agilen Managementmethoden“ zu werfen. Eine Methode, die in dieser Episode vorgestellt wird, heißt Scrum. Scrum ist ein Vorgehensmodell für Projekt- und Produktmanagement, das ursprünglich für Software-Technik und Software-Entwicklung entwickelt wurde. Die Scrum-Methode führt die sogenannten agilen Management-Methoden ein. Es geht vor allem um die Selbstorganisation, Selbstverpflichtung, Ermächtigung und dauerhafte, permanente Optimierung.
Weiterführende Links
Hier finden Sie die Videos und Links der im aktuellen iPad4productivity-Podcast besprochenen Konzepte, Apps und Tools:
Der Ultimative Scrum Guide 2.0
Sollten Sie auf einem anderen Weg auf diese Seite gekommen sein, können Sie sich hier für den Gratis-Hörerservice des Podcasts anmelden. Sie erhalten dann immer alle Zusatzinfos und Links zu den wöchentlich neu erscheinenden Episoden und weitere nützliche Tipps zur produktiven Nutzung des iPads.
Hier finden Sie den Gesamt-Themenplan des Podcasts inkl. der in den Episoden besprochenen Links und Trankripte zum Nachlesen.
Ich freue mich sehr über Ihr Feedback und Ihre Themenwünsche. Sie erreichen mich unter unter 030/44 0172 99 und t.jekel@jekelteam.de.
Hier das Transkript der Episode:
(Bitte wundern Sie sich nicht über die nicht schriftreife Sprache. Ich spreche die Podcast frei ein und erstelle daraus erst im Nachhinein das Transkript.
Herzlich willkommen zu einer weiteren Episode von iPad4productivity und dem Schwerpunkt diesen Monats – meine größten Fehler. Es gibt ja Fuckup Nights, wir machen Fuckup Podcasts, und sagen was sind so die Dinge, die mir persönlich irgendwo nicht ganz gut gelungen sind, und wo ich, ja, was Sie auch machen sollten, nach jedem Projekt immer gucken sollten, wie kann mans besser machen. Und Sie müssen nicht die gleichen Fehler nochmal machen, die ich schon gemacht habe. Und nachdem wir uns im letzten Monat mal angeguckt haben so ein Thema Projektende nach der letzten Erstschulung, und nachdem wir uns davor mal angeguckt haben so dieses Thema Prozesse nicht konsequent durchzudenken, gerade an dem Beispiel Excel-free.
Wenn Sie es noch nicht gehört haben, gerne nochmal reinhören. Ich gehe in dieser Episode mal ein auf die Schwächen des klassischen Projektmanagements, so mit Lastenheft, mit Pflichtenheft und mit der klassischen Wasserfalltechnik. Meine persönliche Erfahrung ist, dass das Ganze immer weniger funktioniert. Also man hat so typischerweise die langen Prozesse Lastenheft-Erstellung, dann macht man Pflichtenheft, dann realisiert man das Ganze, und ich habe es wirklich so erlebt, dann haben wir ja auch Pilotuser definiert, die haben wir reingenommen und dann haben wir eben lange, natürlich auch immer ein bisschen Feedback gegeben, natürlich auch ein bisschen getestet, aber der Weg bis wir dann wirklich mal so ein fertiges Produkt geliefert haben, war relativ lange. Und so im klassischen Fall liefert man ja eher ein fertiges Produkt und sagt so, jetzt, das war ja so deine Anforderung, jetzt guckt man nach. Und das Extremste, was ich mal erlebt habe im Projekt, da hatten wir einige Bausteine, hat das mit der klassischen Technik gut funktioniert. Also da hatten wir eine App, wo es darum ging Aufträge ins System reinzugeben und weiterzuleiten. Da waren wir relativ gut dran, da wars auch so, dass das ein Prozess war, da gabs vorher schon auch eine Windows-App und da gabs sicherlich, hat das ein bisschen geknirrscht am Anfang, aber das ging ganz gut. Ganz anders war das für den Bereich Preislisten-Erstellung, Preislisten-Bearbeitung, dafür gabs ein Excel-Tool. Und das war ein hoch komplexes Excel-Tool und das haben wir in eine App umgebaut. Und das Problem war damals, in der Projektphase gabs kaum jemanden der wusste wie dieses Tool funktioniert. Und irgendwie hat da jeder mit gearbeitet, aber jeder ein bisschen unterschiedlich. Und wir hatten einige Regionen dieses Kunden drinnen aber nicht alle. Und dann haben wir das so nach bestem Wissen und Gewissen gebaut und getestet und so weiter, und da war ich der (???), da haben die gesagt, super gemacht Herr Jekel, aber bei uns läuft das alles ganz anders. Dann habe ich die mit großen Kinderaugen angeguckt und habe gesagt, wieso läuft es ganz anders? Dann haben sie es erklärt. Da habe ich gesagt, okay, und habe das als Anforderung mit aufgenommen, da war ich in der nächsten Region, da haben die gesagt, ja so wie wir das ursprünglich gemacht haben, machen wir es nicht, aber wir machen das auch nicht so, wie die Kollegen von letzter Woche. Wir machen das nochmal anders. Und ich bin dann durch die ganze Reihe von Regionen und so die vorletzte Schulung, da hat sich das langsam reingependelt, aber letztendlich hats jeder anders gemacht. Jetzt was waren die Probleme? Zum einen waren die Probleme, die wir hatten, dass wir nicht aus jeder Region jemand drin hatten, das habe ich auch gelernt, also deswegen in solchen Projekten gucken Sie, dass Sie möglichst alle Regionen dort immer mit dabei haben, also dass sie nicht sagen, es gibt irgendwie fittere Regionen, wo Sie Leute in Projekte reinnehmen, dann lieber zwei-drei Leute mehr ins Projekt rein. Das ist das erste was ich gelernt habe. Das zweite, was ich gelernt habe ist, dass es eben wichtig ist, nicht was zu entwickeln und das fertige Produkt, auch nicht in der ersten Version zu zeigen, sondern durchaus kleine Teilbereiche von Lösungen auch zur Verfügung zu stellen und zu sagen, jetzt guckt ihr mal diesen Teil an – nur Eingabe irgendwo eines Preises, oder nur die Sortierfunktion und nur einzelne kleine Teilbereiche und diese kleinen Teilbereiche iterativ zu überarbeiten und zu sagen, hier ist deine Anforderung, guck dir an was wir jetzt realisieren und dann wird sofort wieder dieses kleine Teil eben angeguckt und freigegeben oder nicht freigegeben. Und das ist eben so eine Idee, dass man sagt, Mensch, hier einen knackigen kurzen Prozess zu haben, weil sonst ist der Prozess häufig zu lang, die Kommunikation zwischen Anwendern und Softwareentwicklern oft sehr indirekt ist und letztendlich es kommt auch nicht die optimale Lösung raus. Und krtisch ist eben, wenn so ein Projekt beendet wird und das wars dann – genau das, was wir uns letzte Woche etwas intensiver mal angeguckt haben. Aus dieser Erfahrung bin ich mittlerweile ein großer Freund von agilen Projektmanagementmethoden und vielleicht hat da der eine oder andere schon mal das Stichwort Scrum gehört. Scrum ist ursprünglich mal aus dem Bereich Rugby gekommen, hat durchaus eine sinnvolle Analogie, das man sagt, dass dieser große Haufen am Anfang, wo das ganze Team eben zusammen eben sich klammert und haut, um in eine gemeinsame Richtung zu gehen. Und das ist durchaus auch sinnvoll, denn was ist Scrum? Scrum ist ein Vorgehensmodell für Projekt- und Produktmanagement, insbesondere kennt an es daher von der Softwareentwicklung. Es wurde ursprünglich für Software-Technik und Software-Entwicklung entwickelt, ist aber davon völlig unabhängig – kann auch für andere Sachen genutzt werden. Und ich gebe Ihnen mal ein paar Stichworte, ein bisschen Einblick in das Thema Scrum. Wenn Sie sich tiefer mit dem Thema beschäftigen wollen, dann empfehle ich Ihnen einen weiteren Podcast und zwar den Podcast, den ich dazu ganz ganz klasse fand als ich angefangen habe mich mit dem Thema zu beschäftige, der heißt agil managen, hat eine rote Kachel, ist ein Podcast, den ich wirklich wirklich klasse finde, also den kann ich sehr empfehlen. Also agil managen, den Link von…, Moment, wie heißt das… Sven Wiegand heißt der Kollege, sehr sehr toller Podcast zum Thema schwerpunktmäßig Softwareentwicklung aber durchaus auch mit der Frage, wie man Agiles Management auch in andere Bereiche übertragen kann. Was gibt so agile Prinzipien, die ich toll finde. Agile Prinzipien sind einmal Ermächtigung und Selbstorganisation. Das heißt, die Idee ist, dass sich Software-Entwicklungstools oder auch Projektteams selbst organisieren und das auch dürfen. Weiteres Prinzip ist, frühere und regelmäßige Lieferung. Hier gibt es ein Stichwort „Sprint“, das heißt im Regelfall wird, und meine Erfahrung ist am besten mit 14-tägigen sogenannten Sprints zu arbeiten, wo man sich bestimmte Produktanforderungen vornimmt, diese dann umsetzt und dann eben nach 14 Tagen liefert. Dann guckt man sich es an und etwas wird freigegeben und etwas nicht freigegeben. Weiteres Prinzip „Überprüfung und Anpassung“. Und das finde ich eben ganz klasse und das fängt schon an bei der Lieferung der Produktproduktstories. Also die Idee ist, dass man nicht mit klassischen Lastenheften arbeitet, sondern mit einem Produckt-Backlock. Da sind Product-Stories drauf, das heißt das sind Geschichten wo erklärt wird, was möchte derjenige mit dieser Funktion machen, wozu, welchen Nutzen bringt das. Und wichtig ist, die Qualität muss hier auch klar sein, also eine Definition auf Ready für eine sogenannte Story. Das heißt, hier muss man eine Anforderung, eine bestimmte Qualität haben, bevor es in das Entwicklungsteam reingehen kann. Bestimmte Qualität heißt, dass beispielsweise schon Screenshots dabei sind, dass hier schon klare Feldbezeichnungen mit dabei sind, also auch hier durchaus die Anwänder stärker gefordert sind als bisher.
Ganz ganz wichtig auch das Thema Transparenz. Jeder im Team weiß, woran arbeitet jeder, und dass klare Zeitfenster festgelegt werden – sogenannte Sprints. So 1 Woche bis 6, 8 Wochen, ich empfehle immer Zweiwochen-Sprints, eine Woche ist meistens zu knapp, Zweiwochen-Sprints sind erfahrungsgemäß ganz gut, das deckt sich auch mit der Erfahrung von Sven Wiegand im „Agil Managen“-Podcasts. Und die Idee ist dann, Sie haben hauptsächlich drei Rollen, Sie haben einmal das Entwicklungsteam, das sich selbst organisiert, sich selbst führt und selbst entscheidet was sie machen, also auch im Sinne von Pull. Da macht der Chef nicht „du machst jetzt das“, sondern es gibt eben ein Pool von Aufgaben und dann sagt das Team eben was nehme ich mir von diesem Scrum-Board runter. Es gibt einen Scrum-Master und es gibt einen Product-Owner. Der Product-Owner ist derjenige, der die Produktanforderung definiert, der diese Stories dort entsprechend schreibt, der sie in das Scrum-Entwicklungsteam entsprechend reinbringt und der Scrum-Master ist derjenige, der das Entwicklungsteam steuert, moderiert die verschiedenen Meetings, der aber nicht im klassischen Sinne führt, im Sinne von „Push“, sondern ein Umfeld des „Pull“ ermöglicht, wo sich die Menschen die Aufgaben ziehen. Also es ist wirklich hoch hoch spannend das ganze Thema, weil so die agilen Werte die da umgesetzt werden sind: Focus, zu sagen wirklich auch Werte zu schaffen, ist Mood eben auch Dinge zu machen, ist Offenheit, ist Selbstverpflichtung zur dauerhaften, permamenten Optimierung, ist Respekt untereinander, also ich finde, das ist wirklich klasse und wenn Sie sagen, ein Podcast ist nicht unbedingt das Medium, sondern ich möchte gerne mal ein Buch haben, dann kann ich Ihnen sehr empfehlen den ultimativen Scrum-Guide 2.0, also das Buch heißt „Der ultimative Scrum-Guide 2.0“, ist aus dem Wibas Verlag, ist von Malte Foegen, Jörg Battenfeld, David Croome, Manuel Dorn, Caroline Gansser, Ann Kathrin Kröll, Astrid Meyser, Simon Porro und Claudia Raak. Es ist ein ganz ganz tolles Buch. Es gibt mittlerweile in der dritten Auflage. Ich packe Ihnen den Link in die Shownotes dazu, also einfach www.iPad4productivity.com mal reingehen, hier habe ich auch einen Teil der Dinge, die ich Ihnen heute erzähle mal von der Struktur, von den Begriffen her rausgenommen. Ganz empfehlenswertes Buch wirklich und der Podcast.
Was gibt es für Ereignisse in einer solchen Planung? Also hier ist es nicht so, dass man klassisch einen großen Projektplan macht, sondern eben eher kleinteiliger das Ganze macht. Das heißt hier macht man eben einen Product-Backlog-Roaming, das heißt, hier werden die Stories durchgesprochen, hier wird eben darüber diskutiert, bevor diese Sotries eben dann in eine Sprint-Planung reinkommten, werden die Stories erstmal abgestimmt. Dann gibt es ein zweites Meeting, in dem man den Aufwand den man benötigt, um bestimmte Funktionen umzusetzen, geschätzt wird und dann geht es erst in ein Sprint-Planungsmeeting ein. Und dann werden hier Stories vorgestellt, dann bricht das Team das runter auf einzelne Aktivitäten und nimmt sich diese Dinge dann vom Board und während des Sprints organisieren die sich komplett autonom. Also wirklich ein hoch spannendes Thema. Ich habe auch eine ganze Ecke gebraucht, bis ich das verstanden habe und am besten ist es wirklich mal umzusetzen. Was gibt es dann klassisch am Ende eines Sprints? Am Ende eines Sprints gibt es ein Sprint-Review, in dem besprochen wird, was ist jetzt erledigt, und dann muss der Product Owner das Ganze abnehmen – nach definierten Kriterien, oder nicht annehmen. Und es gibt noch zwei zusätzliche Elemente, die ich hoch spannend finde, die man so in der klassischen Form nicht findet. Das eine ist, nach Ende eines Sprint-Scripts gibts eine Sprint-Retrospektive. Hier ist es so, dass gesagt wird, okay, was lief gut, was macht man nächstes Mal besser. Also hier im Sinnve wirklich des Prozessoptimierens immer besser zu werden. Ich finde es klasse und das ist so am Ende des Sprints, also nach zwei Wochen, was es aber dazwischen gibt ist ein Daily Scrum. Das heißt, jeden Tag wird gesagt, was habe ich seit dem letzten Daily Scrum fertiggestellt. Und damit wird nicht gesagt, was habe ich gemacht, sondern was habe ich fertiggestellt, was wird bis zum nächsten Daily Scrum fertiggestellt und welche Hindernisse gibt es. Und das ist zum Beispiel ein Prinzip, was man auch im anderen Kontext umsetzen kann. CocaCola hat sowas beispielsweise im Rahmen seines Daily Vision Projektes in der Vertriebssteuerung und –führung gemacht. Da setzen sich die Vertriebsleute jeden morgen zusammen, 15 Minuten Meeting, kurz und knackig. Da sagen die wie viel Kühlschränke habe ich gestern aufgestellt, wie viele Kühlschränke stelle ich morgen auf. Das Ganze als Team. Auch ein agiles Managen, ein agiles Projektmanagement, was in die tägliche Vertriebsführung umgesetzt wurde. Also deswegen möchte ich Sie, weil viele sagen, ah, Scrum ist ja was für IT-Freaks und so weiter, nein, es ist ein Teilbereich von agilen Management-Methoden, die man in der ganzen Firma umsetzen kann und ich möchte Sie gerne ermutigen, sich mit dem Thema zu beschäftigen. Also ich bin auch so, dass ich je mehr Erfahrung ich sammle, desto agiler werde ich da. Natürlich die Herausforderung, die ich als externer Projektleiter habe ist, ich komme in ein Unternehmen rein, die noch nie was von agilen Management-Methoden gehört haben, dann ist das nicht so einfach, weil man immer gucken muss, okay, ein Teil der Energie braucht man um diese neue Art des Projektmanagements einzuführen, Teil der Energie braucht man, um das Projekt selber durchzuführen. Also hier gibts auch bestimmte Übergangsszenarien, da geht aber beispielsweise eben im agilen Management-Podcast der Kollege sehr sehr gut auch darauf ein, auf Übergangsszenarien beispielsweise. Ja, was gibts dann für Dinge? Ein Product Backlog ist eben eine Liste von Produkt-Anforderungen, von eben eben Product-Stories, die sehr klare Kriterien haben und das Ganze ist eben so, dass das ein Lastenheft wirklich ersetzt dadurch, dass man sehr kleine granular gut strukturierbare Stories hat, die klare Definition-of-Ready haben, also die damit sehr gut runterbrechbar sind und idealerweise hat man dann eben kleine Tasks und idealerweise dauert so ein Task dann auch einen Tag. Das heißt, dann kann sich ein Software-Entwickler eine Aufgabe vom Scrum-Board runternehmen, wo er ein Tag braucht und die dann entsprechend im nächsten Meeting abnehmen. Also die Erfahrung ist ja, es ist eine andere Art der Arbeit, aber sehr viel Selbstbestimmteres. Und das ist wirklich etwas, wo auch sehr klare Kriterien definiert werden zu sagen, wann ist eine Story fertig, wann ist auch eine Aufgabe erledigt, also im Sinne des Qualitätsmanagements. Und das ist wirklich auch eine Umsetzung von Lean-Management-Prinzipien, was man hier hat im Scrum, und so die klassischen Lean-Management-Prinzipien sind ja: Definiere Wert aus Kundensicht, also dass man wirklich auf das Schöpfen von Wert fokussiert ist, ganz auf Kundensicht, dass man eben sagt, identifiziere den Wertstrom, so wie das auch im ultimativen Scrum-Guide gut formuliert ist. Also wirklich die gesammte Wertschöpfungskette sich anzuschauen, bringe die Arbeit in Fluss, also durch ein Scrum-Board, durch eine Visualisierung, dadurch dass es durch einen solchen Prozess durchgeht, erzeuge den sogenannten Sog der Arbeit, also Pull, das heißt, dass Sie als Führungskraft nicht sagen, du machst das, sondern dass Sie eben auch bei unangenehmen Aufgaben beispielsweise fragen, wer macht das. Und das sich eben das Team das selbst nimmt. Und wir denken immer als Führungskräfte, aah, das gebe ich dem, das gebe ich dem, und letztendlich machen wir uns das Leben schwerer und die Rolle der Führungskraft, des Managements, sollte eher sein, diese Prozesse zu strukturieren, zu moderieren, einfacher zu machen, die Methodik rüberzubringen. Und ganz klar, Strebe steht nach Perfektion, wobei Perfektion nicht im Sinne von „wir können es liefern, wenn es perfekt ist“, sondern im Sinne Prozesse mittels iterativen Feedback-Schleifen zu optimieren. Also das sind so ein paar Grundideen, also ich finde das hoch spannend dieses Thema, kann also nur jeden ermutigen sich damit intensiver zu beschäftigen, nicht nur im IT-Bereich, aber gerade wenn es auch um IT-Projekte geht auch ein ganz ganz spannendes Thema.
Ich werde immer wieder gefragt, ja mit welchen Tools arbeitest du dort? Es gibt für mich zwei Tools, mit denen ich da gerne arbeite. Das eine ist Trello. Sie können das Tool sogar gratis nutzen, man kann es als Kanban-Board nutzen, es gibt aber sogar ein Trello-Addon, mit dem man AI und Scrumm umsetzen kann, oder man kann sich das selbst anpassen. Und das zweite Tool, mit dem ich sehr gerne arbeite ist Jira. Und Jira ist eigentlich ein Ticketing-System, was viele im IT-Bereich vielleich kennen. Das hieß früher Jira Mobile Agile, mittlerweile ist das eben Jira umgesetzt, es gibt sie mit der Ergänzung Confluence und damit kann man eben auch Dokumente gleich verteilen, man kann hier wunderbar diesen ganzen Prozess wie Product Backlog, Daily Scrum umsetzen. Auch das ganze Thema Reporting Tools. Also hier gibt es das sogenannte Burndown- oder Burnup-Charts, wo man sehen kann, wie viele von den Aktivitäten sind im laufenden Sprint schon erledigt worden, wie viele sind noch offen. Hier kann man auch Velocity Charts absehen, das Velocity heißt die Geschwindigkeit, wie schnell ist ein solches Team und das ist toll, weil was man nicht messen kann, kann man auch nicht managen. Und ein großes Missverständnis von agilen Methoden ist ja, dass viele sagen, juhuu, ich brauche es nicht mehr planen, ich brauche es nicht mehr steuern. Das ist es definitiv nicht. Es ist nur eine andere Art der Steuerung und natürlich muss man das auch manchmal umsetzen. Und dieses Geschwindikeitstool ist ein tolles Tool, in dem man einfach sehen kann, okay, man plant solche Stories mit sogenannten Story Points, die reflektieren die Komplexität von einzelnen Aufgaben und über ein Reporting kann man eben dann sehen, okay, wie viel Manntage brauchte ich denn im Moment ungefähr um so ein Story Point umzusetzen. Die Geschwindigkeit kann sich ändern und idealerweise ändert die sich auch, so dass Sie eben dort auch noch schneller wird. Also wen ich jetzt neugierig gemacht habe, dem empfehle ich auf alle Fälle von Sven Wiegand „Agil Managen“ als Podcast, also der ist wirklich sehr sehr klasse, dieser Podcast, da kann man also sich sehr praxisorientiert mit dem Thema nochmal neu beschäftigen.
Ich freue mich natürlich auch gerne über Input, über Feedback, über Ihre Erfahrungen und in diesem Sinne weiterhin viel Erfolg und Sie wissen ja – erst Hirn einschalten, dann Technik.
Letzte Kommentare