Episoden

ZA129 Warum agiles Projektmanagement keine Lösung ist?

11.07.2017 16 Minuten



On Air in dieser Episode

avatar Maik Pfingsten

Zusammenfassung

Ich liebe agiles Projektmanagement. Seit 2005 als Troubleshooter nutze ich auch agile Methoden im Projektmanagement. Aber mir ist etwas aufgefallen. Momentan wird alles mit AGIL totgeschlagen, was nicht bei drei auf dem Baum ist. Da kam die Anfrage dem PM-Camp Berlin gerade recht. Das Thema dieses Jahr ist Vielfalt. Und so widme ich dieser Episode den Thema Vielfalt im Projektmanagement.

So wirst du in der Episode erfahren, warum agiles Projektmanagement manchmal keine Lösung ist und wie du am Besten bewerten kannst, welche der vielfältigen Möglichkeiten du gerade am Besten benutzt.

Hinweise aus der Episode

Das PM-Camp Berlin findet statt vom 7.-9. September 2017. Alle weiteren Informationen und Tickets findest du unter:

berlin.pm-camp.org

Auto-Transcript

Dieses Transcript ist mit einem AI-Algorithmus automatisch erstellt worden und dient dem Test und der Weiterentwicklung des AI-Systems.

[0:00] Hallo und herzlich willkommen beim ZukunftsArchitekten. Der Projektmanagement Podcast für Macher und Game Changer. Am Mikrofon ist wieder Maik Pfingsten. Als Troubleshooter a.D. gebe ich euch Tipps und Impulse aus der Praxis damit ihr eure Projekte auf die nächste Ebene heben könnt.

[0:16] Ja ich liebe agiles Projektmanagement und bin seit 2005 auch als Troubleshooter unterwegs gewesen habe wahnsinnig viele agile Methoden schon damals im Einsatz gehabt bin sehr stark verletzt mit der Linie Zähne schon damals gewesen können.

[0:31] Und mir ist aktuell was aufgefallen was mir schon länger auf dem auf dem Herzen liegt ein Thema, zwar wird momentan alles mit, agil totgeschlagen was nicht bei drei auf dem Baum ist und da kam dann mir eine Anfrage vom Projektmanagement Pampers im Pencam in Berlin Garde Rechte und das Thema dieses Jahr ist eben das Thema Vielfalt und so wird mich diese Episode eben dem Thema Vielfalt im Projektmanagement und nebenbei das BM Camp in Berlin ist extrem empfehlenswert ich bin sehr gerne dort und wenn du dein Tresse hast,

ich habe hier einen Shorts natürlich den Ding zqm Camp so dass sie dich da weiter informieren kannst und dir auch dort dein Ticket besorgen hattest ja Vivien was willst du in der Episode heute erfahren Warum agiles Projektmanagement manchmal keine Lösung ist und wie du am besten bewerten kannst welche der vielfältigen Möglichkeiten du gerade am besten benutzt.

[1:28] Ich mal auf das erste Thema ein der Produktentstehungsprozess wenn wir heute von Software reden.

Dann denken die meisten immer so an Microsoft Office Internet Cloud, mein Mac oder mein mein PC irgendwelche Apps auf dem iPhone oder Web und so weiter und so weiter aber der Witz ist,

über 80% des hoffe die um euch herum ist ist, in embedded Systemen das heißt in eurer Waschmaschine Heizungssteuerung dem Stromzähler der Ampel der Solaranlage und Windrad Auto Flugzeug Fernseher Musikanlage Router Mobiltelefon was nicht alles um einen herum ist.

Was ist embedded software und ist in der Regel gekennzeichnet dadurch dass es mechatronische Geräte mechatronische Systeme sind das heißt es gibt in irgendeiner Form Mechanik.

Vielleicht einfach nur Gehäuse oder ganz aufwendige Mechanik es gibt in irgendeiner Form Elektronik und es gibt definitiv auch embedded software in diesem System.

[2:28] Und das können kleine Sachen sein die ich eben schon sagt vielleicht internet-of-things Dinge aber auch hinüber medizinische Systeme in einem Krankenhaus oder eben halt große Embedded-Systeme in einem Auto in der Bahn oder,

eben auch im Luft und Raumfahrt Bereich.

Und ganz ganz wichtig ist dabei und das ist etwas was du auch häufig gar nicht so bewusst ist gerade in klein und mittelständischen Umfeld wo gerade Fläche embedded einzuhalten das ganze Thema Maschinenbau.

Besoffe ist häufig sicherheitsrelevant ja das heißt sie ist ja in der Regel an physikalische Prozesse gebunden das heißt sie bildet physikalische Prozesse in irgendeiner Form ab und steuert sie und damit verbunden gibt es,

eine durchaus,

größere Zahl von Systemen die am-ende-des-tages Gefahr für Leib und Leben darstellen wenn sie nicht richtig funktionieren ja das ganze läuft unter dem Großen,

Überschrift functional safety alle die embedded software in ihren Systemen habe und ist völlig egal welche Branche haben,

dieses Thema embedded safety auf dem Tisch ob sie es wissen oder nicht das bedeutet sie sind haftbar wenn sie sich da nicht drum gekümmert haben weil diese Systeme in der Regel auch in irgendeiner Form dem,

Menschen,

gefährlich werden können wir sie nicht vernünftig gemacht worden sind und was ganz typisch ist bei dieser ganzen sicherheitsrelevanten Geschichte ist so Software embedded software Komponenten Module aus dem Palace hoffe haben gerne auch mal locker eine Lebensdauer von 15 Jahren.

[3:59] Mehr.

Was heißt es gibt definitiv noch Software dem Auto heute rumfährt die ich mal 2001 als junger Softwareingenieur gekotet hat da bin ich sehr sicher dass diese Woche noch fährt.

[4:13] Und ganz wichtig ist wenn ich jetzt so ein mechatronisches Produkt Sonnensystem sind embedded system entwickeln will dann hat,

so ein Produkt verschiedene Phasen durch die es läuft und die Phasen können unterschiedlich sein unterschied unterschiedlich sein in ihrer Länge aber vor allem auch unterschiedlich sein in dem Namen je nachdem wo du unterwegs bist mit deinem Unternehmen.

Mit deiner Branche also hinsichtlich,

mich jetzt nicht an den Begriffen auf ich habe als Mensch und Speaker verschiedenste Unternehmen und verschiedenste orangene neu gesehen und jede warum ich jedes Unternehmen hat natürlich seine eigene Sprache seine eigenen Begriffe am Ende ist es aber die gleiche Sache und das Interessante ist ich habe eigenes Zahnarzt gegründet und bin auch als Angel Investor bei Startups mit,

dabei und hat sie begleitet.

Und ich kenne die auch als Investor diese Phasen da heißen sie dann häufig nur anders aber am Ende ist es immer das gleiche was wasserbruck Entstehungsprozesse angeht und ich nutze da einfach mal die Begriffe aus der Automobil Entwicklung da finde ich sie ganz passend da gibt’s so drei wesentliche Bereiche das eine ist Forschung,

das Weite ist Vorentwicklung und das dritte ist Serienentwicklung und versteckter eigentlich hinter.

[5:24] Forschung die Aufgabe ist es Ideen zu generieren und.

Neues auszuprobieren das heißt das Ziel ist hier ganz allein. Zu bringen und zu entscheiden sprich ich habe einem Ergebnis irgendwo eine Studie oder ein Konzept oder Demonstrator und der wesentliche Meilenstein der die Phase Forschung in der Produktentwicklung abschließt ist eben die Frage,

will ich investieren in diese Idee oder nicht und das bringt uns dann zur nächsten Phase und zwar,

der Freund Wicklung und zwar die Aufgabe des Heels diese Idee die aus der Forschung kommt weiterzuentwickeln,

kann ich das überhaupt einen Kunden verkaufen will das überhaupt irgendjemand haben und das Ergebnis in der Vorentwicklung ist ein sogenanntes MPP minema Waibel product die Kollegen und Hörer die hieraus.

Außenbereich ist da Dub und Eltern kommen kennen vielleicht den Begriff das nennt sich dann meistens,

irgendeiner Form anders inmitten in anderen branchenkarte Maschinenbau aber es gibt in irgendeiner Form 1 1 ist ein ein ein ein Produkt einen System soll ich jetzt mal irgendwas in der Hand was irgendwie so gerade eben minimal die funktionierten darstellt dass es für den Kunden kaufbar wäre,

also das ziel ist es hier als Meilenstein,

macht es Sinn des MPP auf dem Markt zu bringen also ich habe durch das MPP die Möglichkeit schon mal zu zu zu erarbeiten.

[6:55] Das ganze auch für einen Grund funktioniert.

Und ich kann damit Kunden auch durchaus rumfahren lassen die wissen natürlich dass es ein MPP ist aber ich kann es schonmal im Einsatz bringen.

[7:06] Dann absolut klar will ich das wirklich dann aus diesem,

Phase aus diesem Zustand des minimal Waibel products eben halt in ein Serienprodukt bringen und damit in den Marken das schließt quasi als Meilenstein ganz typischerweise die Vorentwicklung ab.

Und geht dann in die Serienentwicklung das bedeutet hier ist die Kernaufgabe der Serienentwicklung Reifegrad erhöhen und vor allem produktionsfähigkeit Herstell,

ja das bedeutet das Ziel ist hier das Produkt oder das System,

serientauglich zu machen das ist nämlich nicht in der Schachtel bei dir auf dem Tisch ankommt und schon beim außen aufmachen der Schachtel auseinanderfällt sondern dass es in hohen Stückzahlen reproduzierbar,

rechtfertigbar ist und vor allem auch all die ganzen Sachen,

functional safety Lebensdauer Qualität und so weiter und so weiter eben halt auch alles erfüllt.

[7:57] Sprich im Ergebnis kann der Kunde kaufen ohne das direkt auseinanderfällt und diese dritte Phase Serienentwicklung.

Schließt typischerweise mit dem Meilenstein Start der Produktion ab.

[8:10] Wie sieht das ist ein Automobile Wirkung schon vor 17 Jahren so gewesen als ich immer Software-Ingenieur war gab es schon dieses Konzept und es ist ganz typisch für das was wir heute auch kennen so rund ums startup.

Was ist die Phase Forschung,

Gründer investieren selbst ich habe als gründeridee ja und investiere jetzt vor allem meistens sehr viel Zeit ein bisschen Geld um meine Idee überhaupt mal ein Stückchen davon zu schieben und dann wenn ich irgendwann im Punkt nach jetzt das ist es ich glaub,

da will ich investieren ich glaube das könnte auch für andere interessant sein dann komme ich,

vergleichbar in die Phase der Vorentwicklung ja das heißt jetzt kommen Angel Investoren mit an Bord sind hoch Risikokapitalgeber oftmals auch in so einer Nebenrolle Mentorin weil sie selber viel Erfahrung haben und,

helfen,

diesen Startup diesen Gründerteam ein Menü Weibel products for anzuschieben mit dem ich auf einer Messe das zeigen kann mit dem ich einen Kunden rangehen kann und überhaupt mal diese diese diese Kunden.

Davon überzeugen bzw Borken Kontakt zu bringen zu sehen wie reagieren Sie dann drauf und wenn das gut funktioniert hat kommt die dritte Phase Serienentwicklung,

analog im Startup sind dass sie sieht Investoren jetzt steigen große große sieht Investoren ein die eben ganz bewusst eben das ganze Thema mit Unterstützung groß machen,

mit dem Ziel Serien Tauglichkeit und damit auch Geld verdienen zu ermöglichen.

Und du siehst das ist ziemlich analog er hat zu dem was ich eben erzählt habe und das fühlt mich so zu dem nächsten Punkt Vielfalt im Projektmanagement.

[9:48] Es gibt kein one-size-fits-all also das ist etwas was ich immer wieder erlebe ich so ja es gibt so eine Lösung die Funktion immer und überall keinem Projektmanagement gibt’s das definitiv nicht wir haben,

unterschiedliche Phasen in unserem Produktentstehungsprozess in den Lebenszyklen unserer Produkte das bedeutet wir brauchen auch für die jeweiligen Phasen durch unterschiedliche,

Möglichkeiten der Steuerung von so einem Heu,

ja und wir haben sogar ganz kurze Beispiele Forschung typische Ansatz in der Forschung ist Design Thinking,

weil das Ergebnis ist Konzept oder Demonstrator typische Ansatz in der Vorentwicklung ist Age ice cream.

Schwerpunktmäßig einzusetzen weil das Ergebnis ist in mppm animal Waibel product in der Serienentwicklung ist ein ganz typischer Ansatz auch schon über 15 Jahre gelebt und hoch iteratives V-Modell.

Weil das Ziel ist hier Serien Tauglichkeit herzustellen die Dichtung muss stehen bleiben der,

die Spitze vom Kirchturm darf nicht mehr runterfallen wenn stürmt ja das ist ein ganz anderes Ziel ganz andere Anspruch dementsprechend auch gibt es verschiedene Projektmanagement Ansätze die wunderbar funktionieren in dem jeweiligen Kontext und das bringt mich,

zu meinen 3 Tipps eben wie kannst du mit dieser Vielfalt im Projektmanagement umgehen,

gib mir mal eins an der Stelle die Frage stellte die Frage was brauchst du wie gesagt es gibt unterschiedliche Phasen.

[11:18] Es gibt vor allem aber auch eben kein schwarz-weiß in diesem ganzen Projektmanagement Kontext ja das heißt es gibt verschiedene,

Ansätze unterschiedliche Ansätze und zwischen diesen Ansätzen gibt’s auch keine scharfe Abgrenzung das heißt auch wenn ich jetzt gerade in der Serienentwicklung bin mit dem hoch interaktive V-Modell mein Projekt Steuer.

Kann es durchaus sein dass es Sinn macht gewisse Dinge z.b. aus dem agilen Kontext zu nehmen,

oder aus dem die Seite ging noch mal was raus zu zu nehmen und noch mein Problem damit zu lösen also das heißt nicht dass ich jetzt PC irgendwo in meinem silodrome da unterwegs bin und ich mache da nur das schon da nur das nein es gibt keine scharfen Abgrenzung wichtig ist hier die Frage zu stellen dass mein Tipp Nummer 1 was brauchst du,

gib Nummer 2 hole dir erfahrene Meister das heißt ich habe in meinen mittlerweile 17 Jahren.

[12:09] So oft erlebt wie irgendeine Sau durchs Dorf getrieben worden ist und hinter dieser Sau her rannten Scharlatan Berater.

[12:19] Ist das tut mir im Herzen weh weil es am Ende keine nach vorne bringt,

ich habe mittlerweile mir die ganzen plakao Frage für diese Geschichte gerade mit Scharlatan Beratern angewöhnt,

wie viel Projekte haben sie mit dem vorgehenden selbst erfolgreich umgesetzt operativ.

So das heißt für mich ist es ganz wichtig Projektmanagement ist am Ende ein Handwerk,

dieses Handwerk kann ich lernen und dieses Handwerk kann ich an Händen und ich,

finde es aus meiner persönlichen Erfahrung wahnsinnig wichtig wenn ich mein Wissen weiter gebe als Meister in meinem Handwerk da muss ich dieses Handwerk auch selber ausgeübt haben.

Ja das bedeutet in diesem Fall kann den Mentor dabei oft vielmehr helfen beispielsweise Rennfahrer.

[13:08] Junge Rennfahrer will erfolgreich in der Formel 1 werden weil könnt jetzt natürlich hingehen und sich ein Berater nehmen Coach nehmen.

Eine wichtige Rolle stehen ich will das nicht abwertend ja aber.

[13:19] Diese Berater diese Coaches müssen selber niemals erfolgreiche Rennfahrer gewesen sein in Zweifel gar nicht also können sie ganz schlecht seinem Auto fahren,

braucht sie brauchen diese Fähigkeit nicht um ihren Job als Berater oder Coach gutzumachen das ist mein Mentor anders Mentor war selber erfolgreicher Rennfahrer und gib dieses Wissen an den jungen Rennfahrer weiter so ganz andere Holle.

Ich habe die Erfahrung des hilft bei wie viel viel mehr und hol dir erfahrene Meister erfahrene Mentoren am Wort bau dir diese Mentoren im eigenen Unternehmen auf du hast sie in der Regel da und es gibt da Leute die da genau in diese Rolle gehen können,

und tippe Nummer drei ganz entscheidend aus meiner eigenen Sicht heraus auch immer wieder wenn ich andere Firmen sehe.

Lerne selber verlaufen die Welt dreht sich weiter auch im Projektmanagement auch wenn einige Sachen die sich heute mit ganz fencing Modebegriffe NBL,

sind schon vor 17 Jahren hatten wir hatten damals kein Begriff dafür.

[14:19] Ist es so dass ich die Welt weiterdreht und es kommen neue Themen neue Möglichkeiten neue Methoden im Projektmanagement und dementsprechend.

Empfehle ich sehr lese viel,

ja schau dass du überlesen z.b. sehr viel Input hast und gehe auf und Konferenzen beispielsweise wie das PM Camp.

Ruderverein neue Ideen,

herumprobieren diese Möglichkeiten aus gerade das entwickelt dein Unternehmen weiter indem du diese Möglichkeiten ausnutzt und und ausprobierst und vor allem.

Ganz wichtig schmeiße Dinge weg die nicht funktionieren.

[14:54] Ist es völlig egal aus welchem Kontext ist kommt Office Design Thinking ist egal Scrum oder hoch attraktives V-Modell oder wieso neudeutsch heißt vintage pro,

Management ja so klassisches Projektmanagement ist es völlig egal schau was du davon nutzen kannst.

Wie du damit konkret in deinem Unternehmen deine Probleme,

anpacken kannst deinen Themen weiter verbessern kannst und schmeiße vor allen Dingen weg.de nicht funktionieren warum sollst du es nein setzen nur weils die Methode sagt weil es die Gurus und soll die Gurus von den Dächer schreien,

denn am Ende ist S1 du übernimmst die Verantwortung und entscheidest was wirklich hilft das mein Tipp Nummer 3 lerne selber,

zu laufen.

Gut zum Abschluss zur heutigen Episode es gibt gerade im Projektmanagement und in verschiedenen Ansätzen kein besser oder schlechter aus der FIFA dem Projektmanagement die richtige.

Auszuwählen ist echt eine Kunst und wie Markus Leitner ist so schön in seinem Blogpost geschrieben hat wie viel Agilität und wenn ja wozu ist ein wesentlicher Punkt den ich immer wieder super finde er hat dort gesagt ist Wasser bei 0 Grad,

oder bei 100 Grad besser genau diese Frage steckt dahinter.

[16:10] Ja suchst du neue Impulse für dein Unternehmen dann sind vielleicht meine TUI speaking geht’s genau das Richtige für dich nein Vortrag deiner Wahl gebe ich deinem Team hilfreiche Impuls und ihr könnt mir anschließend ein Loch in den Bauch fragen wenn du Interesse hast sprich mich einfach an das war die heutige Episode des zukunftsarchitekten der Po,

ich bin Schmidt Podcast für Entscheider ich bin Maik Pfingsten und danke dir fürs Zuhören ich wünsche dir eine schöne Zeit lach viel und habe viel Spaß was immer du gerade machst und zu sage ich tschüss und bis,

zum nächsten Mal.

ZA127 Warum Projekte scheitern

04.07.2017 34 Minuten



On Air in dieser Episode

avatar Maik Pfingsten

Zusammenfassung

In dieser Episode schaue ich auf die Ursachen, warum Projekte scheitern und zeige, wie du als Unternehmer frühzeitig die Weichen auf Erfolg stellen kannst.

Projekte, die in der Schieflache hängen kosten Zeit, Geld und Nerven. Das muss nicht sein. Ich zeige dir die Top 3 Ursachen, warum Projekte scheitern und du erfährst, woran du erkennst, ob ein Projekt schief hängt. Ich gebe dir eine überraschend einfache Möglichkeit in die Hand, wie du damit umgehen kannst.

ZA125 Die typischen Fehler beim Product Backlog

27.06.2017 31 Minuten



On Air in dieser Episode

avatar Maik Pfingsten
avatar Michael Mahlberg

Zusammenfassung

Was ist eigentlich ein Product Backlog? Ich bin auf der Forschungsreise und habe mit dazu mit Michael Mahlberg einen ausgewiesenen Experten aus der agilen Szene ins Studio geholt.

So wirst du in der Episode wirst du erfahren ob ein Product Backlogs für dich Sinn macht, was die typischen Fehler sind und was in ein Product Backlog wirklich rein gehört.

Transcript

[0:02] Hallo und herzlich willkommen beim ZukunftsArchitekten. Der Projektmanagement Podcast für Macher und Game Changer. Am Mikrofon ist wieder Maik Pfingsten. Als Troubleshooter a.D. gebe ich euch Tipps und Impulse aus der Praxis damit ihr eure Projekte auf die nächste Ebene heben könnt.

ja was ist eigentlich ein, Product Backlog und ist das Regal mit Requirements Management oder ist das eine To-Do-Liste wie sie klassischen Projektmanagement kennen und vor allem wie kann ich es eigentlich nutzen und so wirst du diese Episode erfahren ob ein Product Backlog für dich Sinn macht was die größten Fehler in der Praxis typischerweise sind und vor allem was da, wirklich hinein gehört ja und so dachte ich mir bevor ich jetzt alleine über dieses Thema,

rätselrater hole ich mir doch in absoluten Experten zum Thema Lean und Agil mit hier in den Podcast ist seit dem letzten Jahrtausend in diesem Kontext unterwegs mittlerweile schon fast Stamm Inventar ein Podcast ist jetzt die vierte Episode mit dem wo wir uns austauschen zu den verschiedensten Themen, er begleitet Projekte und Produkte im ganzen Kontext Agile und und parallel auch, begleitet Unternehmer Organisation,

immer dann wenn es um Prozesse geht und mich mich hier im Podcast in der Show als Gast zu haben Michael Mahlberg.

Hallo Maik schön wieder hier zu sein ja genau ich hatte ja die letzten noch mal 9 Monate, einen intensiveren wissenschaftlichen.

[1:35] Kontext und Konsens und Konflikt mit dem Product Backlog als als ein Teil der mannigfaltigen Möglichkeiten im agilen Kontext Sachen zu,

betreiben soll ich jetzt mal sehr gemeint und ich will einfach mal einsteigen mit dir was ist ein Product Backlog aus deiner Erfahrung aus deiner Sicht,

das sind wir gleich drei Fragen auf einmal ich glaube populär gemacht wurde der Begriff durch Scrum damals,

und.

Damals war das auch mit damals meine ich tatsächlich so ein bisschen sogar die Zeit bevor adaleta hieß also vor 2001 komm ist er deutlich älter,

Bernd damals war es sehr sehr klar definiert was das ist und irgendwann zu gucken woher kommt der Begriff überhaupt,

Warum Bettler.

Energien Zähne hat sich dieser Begriff inzwischen für Liste von Dingen die Verantwortung verstehen verallgemeinert aber man sich den Wortursprung anguckt stellt man fest das heißt was anderes.

Wenn er uns im englischen das angucken mehr Möpse dictionary dann steht da.

Zu Bett lag an der Kumulation of tasks an performed also eine.

Sammlung von Aufgaben die noch nicht erledigt wurden macht uns noch ein bisschen gemeiner und guckt in die Übersetzung das stehende solche Übersetzung wie Rückstand oder Nachholbedarf.

[3:05] Das heißt.

[3:09] Der eigentliche Ursprung dieses Wortes ist keineswegs etwas Gutes sondern eher okay das sind die Dinge die wir noch nicht geschafft habe.

Was ja in meiner Welt eine Liste offener Punkte nah kommt z.b. z.b. okay jetzt hat gefragt nach dem Product Backlog.

Und das tolle speclog ist halt eine Liste von Sachen die noch nicht getan wurden auf einem.

Ganz bestimmten ablations Niveau auf einem ganz bestimmten Uhrzeit Zions Level und das entscheidende dabei ist dass wir im fördert beck-blog Sachen sammeln.

Die innerhalb fester iterationszyklen abgearbeitet werden sollen hier auch wieder aus das garnwelt stammt der ursprüngliche Gedanke war.

Wir haben eine Menge von Anforderungen die im Moment theoretisch bekannt sind und wir wissen wir haben.

Bestimmte Zyklen den wir sie abarbeiten und wir haben einen kleinen Teil davon den nächsten Zyklus.

Üblicherweise des Prince der damals noch 30 Tage lang war eine heute meistens 14 Tage lang essen.

Abgearbeitet werden kann und da drunter Sachen die ungenaue sind nur noch die alten Spezifikationen und realen Beschreibung von dem was Blacklock ist angucken dann ist es tatsächlich eine Liste von Dingen.

[4:41] Die noch in der Software oder ein Produkt es geht gar nicht nur um Softwareprodukt umgesetzt werden sollen in unterschiedlicher Granularität unterschiedlicher Feinheit und.

Diese Liste ist völlig unabhängig davon ob da diese User Stories drin sind ob das.

Ja noch alles Use-Cases Features oder auch Bugs und in Hand mit requests oder sonst was sind das sagt der Begriff paclog nicht.

Limbecker stehen immer User Stories turtleback da steht immer User Stories ist einfach zu kurz gesprungen die Leute die das schon ein paar Jahre länger macht springt eigentlich von Korat iCloud items.

Und dieser Vorderdeckel Items können halt durchaus.

Aus unterschiedlichen Bereichen standen sind ziemlich verbreitet und den großen Vorteil haben dass sie.

[5:39] Requirement die Anforderung aus Sicht des Users beschreiben.

Aber auch User Stories NT ein missverstandenes Ding das heutzutage ganz oft darunter verstanden wird ist das.

Zygarde Tonformat zeigte Halbton Format weil ein Mic counters weil ursprünglich geschrieben hat,

und das besteht halt aus den drei Bereichen wer möchte dieses,

diese Fähigkeit ist es James und welche systemfähigkeit geht ist und dann sogar den alten Sachen von Cohen gar nicht so.

Weit in Vordergrund gestellt aber fulminant wichtig.

Warum zu welchem Zweck die Klasse, die klassische Formel dafür ist als ein Art des Benutzers.

Möchte ich Verhalten Systems so dass ein bestimmter geschätzt wird erzählt hat.

Das ist die heute am häufigsten anzutreffende Form.

Von Berg von Vereine von Fallout beadlock tatsächlich ist es aber durchaus gute Praxis auch alle anderen Anforderungen wieso auftauchen mit in das toiletbag Lok einzutippen.

Und es gibt sogar noch ganz viel zu sagen z.b. wer darüber die Hoheit hat das ist sehr sehr klar geregelt in Scrum das ist in anderen Prozessen nicht so klar geregelt.

Das ist halt Verhandlungssache gucken wir uns die kann man Welt an das.

[7:09] Ganz klar geregelt wir müssen es nur explizit machen nicht.

Wer das macht dick geworden das kann man ja kein process Framework ist sondern das kann man in Freiburg etwas Prozesssteuerung Prozessverbesserung ermöglicht.

Unturned wir uns Aral XP Feature Driven Development dsdm angucken die ganzen alten in Anführungsstrichen agieren Prozesse die haben davon leicht unterschiedliches Verständnis.

Wenn sofern das Quadrat Beckett muss man dann eigentlich wirklich im Kontext Denise definiert wurde betrachten das Scrum.

Okay und ich warte jetzt gerade schon von ganzen Themen Anforderungen und das ist ja auch so dicker Ursprung gewesen warum ich da auf die Reise gegangen bin eben.

Ich kenne das Lastenheft sag mal meiner klassischen Welt die Lasten aus Sicht des Auftraggebers die Anforderungen wünsche dir damit formuliert und.

Immer häufiger.

Komme ich eben halt an dem Punkt dass Leute mir zurück spielen Java wir brauchen kein lassen affair mir jetzt ein Kodak Back Lock wo ich immer so das Gefühl habe es noch da wird so Äpfel mit Birnen verglichen werden oder ob du nur,

gesagt wird wir brauchen keinen.

20 Seiten Dokument wir machen jetzt ein PDF also sprich ob man sich nicht eigentlich nur über die unterschiedliche Form unterhält was macht denn für dich das Lastenheft aus.

[8:41] Also ein entscheidender. Für mich ist Lastenheft der richtige Detaillierungsgrad dass ich als Auftraggeber meine Wünsche meine Anforderung an das von mir,

zu lösende was man sich zu lösende Problem formuliere und zwar in einer Form formuliere wie gesagt hassen dass ich,

500 Flug Ebenen nicht zu niedrig Sitze zu weit rein geht dass ich halt nicht das Problem dass ich eine Lösung anfange zu dokumentieren nein gesagt und du musst genau diese,

Quellcode Zeile umsetzen als requirement.

Dann eine sinnvolle Struktur die nachvollziehbar ist ein ganz wesentliches Element weil ich darüber viel mit Schablonen arbeiten kann.

Hersteller aber im anderen Kontext auch als als Lisa.

Mich immer wieder finde ja die wir besser die das Laster strukturiertes und so einfacher ist es für den Leser den Inhalt aufzunehmen und dazu kommt eben dass ich auch eine eine Schablone.

Bequemes Ingenieurin Ansätze reimatic Einsätze eh nicht wie du gerade beschrieben hast das Schablonen User Stories wobei diese Schablone auch ganz Clans Weg erzeugt wo ich eben.

[9:56] Interpretierbarkeit.

Maximal versuche rauszunehmen wir sind da ziemlich ähnlich unterwegs für Juristen die versuchen mit juristischen Texten auf die Interpretierbarkeit aus der klassische Problem wenn ich Statement habe.

Es ist immer interprété was wissen wir als Mensch wenn ich aber diese Schablone nutzen requirements contact also das System muss.

Bei Information SAP Impuls.

[10:25] Aktivität auslösen als globales Beispiel habe ich verschiedene Sachen wie gravitätisch muss es das soll es das kann es dass das Objekt des klar benannt der Trick aus Kabeln an die Aktivität ist klar genannt.

Wie sieht’s mal ganz schrecklich ja ist ja jetzt auch kein kein wie soll ich sagen ist jetzt auch kein Unterhaltungsroman so ein Lastenheft und es geht ja um ein,

technisches Dokument aber durch diese Vereinzelung der Anforderung durch diese requires, drin so weiter nehme ich möglichst viel Interpretierbarkeit raus wobei für mich das Entscheidungen lassen es gar nicht hinter die Verschriftlichung in einem.

20 seitigen.

Dokumente ist die sollten doch einfach nur Gutes lassen es ungefähr Umfang von 20 bis 30 Seiten und nicht wie die klassischen Lastenhefte beim industrie-contact von 300 bis 500 Seiten das ist definitiv zu detailliert und wahrscheinlich auch völlig,

inhaltlich sinnlos aber ein gutes professionelles Lastenheft wirklichen Wert hat.

Zweck bitte dann auch erfüllt hat diese großen Ordnung aber es ist gar nicht ist sondern es ist diese wir haben uns dadrüber.

[11:34] Ausgetauscht und Klarheit geschaffen dass ich verstanden habe was ich überhaupt mir wünsche genau jetzt redest du über einen ganz anderen Aspekt der,

agieren Umfelds extrem wichtiges wenn es darum geht wie kommen wir von einer Idee einer systemfähigkeit dazu dass man dieses Sehfähigkeit wirklich nutzen kann das hat auch gar nicht so viel mit dem Begriff peclot zu tun.

Das ist ein Problem dass wir heutzutage immer häufiger haben die mehr Leute agil machen.

Die Leute der der die Menge der Leute die agil arbeiten verdoppelt sich alle zwei bis drei Jahre Bern was bedeutet das im Umkehrschluss das bedeutet das.

Die Hälfte aller Leute die agil machen das erst zwei bis drei Jahre lang tun.

So was heißt da sitzen wir ganz viel auf kariertem Wissen auf das ist wie in anderen Branchen auch wenn die die Anwender schafft größer wird muss das wissen.

Anders verteilt werden als sind wenige Spezialisten sind und gerade um dieses ganze Thema wie kommen wir von der Idee zum.

Eigentlichen hinterher nutzbaren Ding gibt’s.

Ganz ganz viele Ansätze die haben unter anderem immer was mit der eben schon genannten Story zu tun die haben das mit der ID eines fördert Beck lautunterscheidung eines Product Backlog gegen ein.

Gegen ein Sprint Backlog zu tun die haben das damit zu tun dass innerhalb dieser eben von mir genannten User Story Schablone.

[13:10] Auch eine eine weitere Semantik enthalten ist das man User Stories zum späteren Zeitpunkt.

Ergänzt um Akzeptanzkriterien und dieser Kriterien sogar formal beschreibt und so weiter das hat aber eigentlich gar nichts mehr mit dem eigentlichen Gedanken des maclocks zu tun der eigentliche Gedanke des maclocks ist tatsächlich nur dass wir.

Unsere Dinge die wir durch das System jagen also.

Außerdem ist die Menge von Menschen und Maschinen die dafür sorgt dass am Ende etwas nutzbar sind dabei rauskommt wie die Systeme organisiert ist und ob das ein siebenmann Team ist oder.

Das 10 verschiedene Teams über die Welt verteilt sind bei der Mama hingestellt der Gedanke des pollerberg blocks ist einfach zu sagen okay.

Wir sammeln diese noch offenen Anforderung wir haben diese noch offenen Anforderungen in einer.

[14:07] Vom vorliegen.

Für den nächsten Zeitraum für den nächsten Sprint klassischerweise detailliert genug ist um damit tatsächlich zu arbeiten.

Und die meinte wir nach unten kommen desto epischer werden die Geschichten übrigens ein schönes Beispiel für das was Martin Fowler.

So schön formuliert hat als semantische Diffusion der Begriff epic bezeichnete früher mal,

eine noch ungenau definiert Jesus soll man weiß noch nicht ob das eine ist oder das 10 sind auf die klein ist oder ob die groß ist Gewitter werkzeuge.de das in einem ganz bestimmten Sinne verwenden denkt jeder heutzutage nur weil in.

Ja da epic eine Klammer.

Um mehrere User Stories ist das nur eine Möglichkeit damit umzugehen sein Epics immer diese Klammern.

Früher hat man das was Indira ein eckiges Martin genannt das ist dann auch wieder anders benannt worden später also die Sprache ist das.

Frieder deshalb kann ich auch gut verstehen dass du da ganz ganz viele Informationen zu Thema Blacklock bekommen hast vieles von dem was du jetzt aber als Eigenschaft mit Lastenheft geschildert hast ist er tatsächlich.

Etwas was Eigenschaft der Dinge in dem Bett lag sind und.

[15:33] Das Finden der richtigen Abstraktionsebene ganz klar ist dieser Unterscheidung zwischen.

Product Backlog und Sprint Backlog da haben wir komplett unterschiedliche Abstraktionsebenen.

Und wir gehen dann häufig noch weiter dann reden aber nicht mehr über eine einfache beadlock sowas sondern über sowas wie Story maps.

Wo wir tatsächlich noch in.

Noch größere abstraktions Einheiten unterscheiden und sagen dass wir einen Bereich haben der ist jetzt eine User activity der.

Kann den ganzen onboarding-prozess beschreiben so.

User Story aus dem Bereich wäre dann sowas weh als ein User möchte ich in der Lage sein.

Ja irgendwie bei dem System bekannt zu sein damit ich hinterher damit interagieren kann natürlich keine User Story keine queimadas mal umsetzen kann das ist so eine Top Level.

Aussage und das kann man sich dann überlegen wie man das in echte Stories runterbrechen kann kann im einfachsten Fall.

Irgendwas sein dass man dich gerne anmelden möchte das kann irgendwas komplexes sein.

Voreingestellter kannst dann ganz ganz viele Ausprägungen geben und das muss er gar nicht Mini was müssen sie Verhalten zu tun haben das kann auch.

Sein ich möchte in der Lage sein an einem Kiosk in der Straße eine Postkarte auszufüllen und danach dann hinterher mein Essen bestellen zu können.

[17:08] Ist eine User Story der vielleicht sogar klein genug in um innerhalb einer Iteration umgesetzt.

[17:16] Insofern viel von dem was du geschildert hast ist von den Begriff paclog in erster Näherung kann ich.

So direkt abgedeckt sondern das ist dann wirklich die Frage was mache ich da drin nachdem dieses Beispiel genannt.

Dass die Konversation zum wichtiger Aspekt ist.

Und ist schön weil ich mir gar nicht sicher ob ich das Wort Konversation in den Mund lege dass du was anderes die Unterhaltung was ich meinte es früher für diese für User Stories.

Aus altes Tonformat vorher gab’s die nämlich auch schon gab’s die schöne Beschreibung des eine User Story vereinigen dem CCC.

[18:03] Hardeck Modell eines PID des CCC entsprechen sollten das ist nicht der Chaos Computer Club sondern CCC steht für kalt.

Conversation confirmation heißt Karte.

Konversation Bestätigung und das bezeugt bescheid wie wir.

Die unterschiedlichen Detail level zeitlich sehen ganz zu Anfang ist das eine grobe Idee über die Mama geredet hat die sehr abstrakt beschrieben ist wo man gerade eine karte hat auf der der kurze Begriff steht.

Danach wenn wir in die Verfeinerung kommen sodass wir anfangen zu überlegen okay jetzt sollten wir mal wissen was damit genau gemeint ist damit wir es wirklich umsetzen können haben wir diese Konversation und erst wenn diese Konversation.

Stattgefunden hat können wir tatsächlich die Umsetzung gehen den hatte Umsetzung kann man doch noch mal die Bestätigung das jetzt richtig verstanden habe.

Und die die klassische Vorgehensweise einer das wirklich auch Beck noch Mensch mit Betracht übertragen ist dass wir.

Diese Kaltphase haben solange die Sachen relativ weit unten im Bett lag sind und wenn sie weiter nach oben kommen.

Gibt’s jetzt in den neueren Scrum Guide sogar eine explizit benannte Phase namens Reymond in denen das Back Lock verfeinert wird damit diese Konversation.

[19:35] Und dann sind halt doch Mittel um diese Konversation wiederum festzuhalten das heißt das Back login demnächst eine Zeile steht ist an der Stelle erstmal ein Platzhalter und ein Zeiger auf durchaus mehr entstehende Dokumente.

Heißt wenn ich mich mit ihm unterhalte früher war das dann so zu XP Zeiten irgendwann hat die Inhalte der Unterhaltung auf die Rückseite der Karte geschrieben genau heutzutage schreibt man das dann eher an ein entsprechendes System.

Sehr häufig in mehr oder weniger gut organisierte Vickys so dass man die Zusatzinformationen zu dem eigentlichen zu der eigentlichen Anforderungen sind es dann nämlich schon eine antwortung auch in deinem Sinne.

[20:18] Das zeigt auf eine Antwort umhin zu würde ich es jetzt vom Generation rechtes durch die Überschrift zu Anforderung und innerhalb dieser.

Normalerweise bis zu drei Nationen umfassenden.

Ist dies bis zu 3000 umfassenden Blogs ganz oben im Bett lag sind die Sachen so verfeinertes genau diese Informationen auch dahinterliegenden seist.

Das ist das was dafür sorgt das ganze bereit zur Umsetzung ist tatsächlich und.

Die Bestätigung es ist etwas das weiß ich nicht wie du das in deiner Lastenheft Welt tatsächlich ab bildest ich habe jetzt eine über These und man dir abgestimmt.

Diese Bestätigung ist hat sich der Dialog während der Umsetzungszeit es ist also im ursprünglichen Gedanken die man damit umgeht mittigen.

Antwort und keineswegs so dass man nachdem man die Unterhaltung hat und sich drauf committed hat ja das machen wir zusammen Situation.

Dann ist alles gut und dir reden erst am Ende wieder und haben die Konfirmation dann in Form des Tests nein die confirmation ist dass man unterwegs sagt Moment ich habe jetzt hier folgende offene Frage gefunden meintest du grün oder blau oder meintest du links oder rechts.

Und dann der Auftraggeber tatsächlich noch mal bestätigt oder eben halt verfeinert ja ich meinte rechts das hast du schon richtig verstanden oder ich meinte.

[21:41] Aber das haben wir auch das ist das ist manchmal so ein bisschen gerade im Bereich Projektmanagement und wenn es ums Lastenhefte geht immer dieses diese Trugschluss Lastenheft ist ein.

Statisches Element was einmal eingefroren für alle Ewigkeit gilt das ist ja aus meiner Sicht eben überhaupt nichts Zweck gemäß sondern diese zwei Wochen Geschichte und dann habe ich einen freigegebenen stand nach besten Wissen und Gewissen.

Aktueller Stand der Technik die Welt dreht sich weiter solche Fragen kommen hoch.

Dinge funktionieren nicht Einforderung ändern sich alles mögliche das heißt ich muss in dieser,

diesen Dialog Einsteigen in die Kommunikation muss Sachen klären und irgendwann komme ich mit einem Punkt wo ich eben halt nach okay jetzt muss ich ein Update mal machen von meinem Lastenheft.

Also verfeinern Sachen vielleicht rauswerfen anders machen oder so aber das haben wir auch und das kann teilweise sehr schnell vielleicht noch mal um auf deinen Anfang dann anfangen Frage zurückzukommen.

[22:45] Wenn jemand sagt wir brauchen keine Lastenheft für mehr wir haben jetzt hier weg locks das ist wirklich keine keine vergleichbare Aussage.

Weil der Bahn paclog gar nicht über die Inhalte so detailliert reden sondern MacLeod bescheid wie wir das Managen.

Wir reden darüber der den Wert der einzelnen Items hättest das macht nämlich derjenige der das Backlog verwaltet das Kontor Altona darüber wer die Kosten der einzelnen Blogeinträge schätzt oder.

Bewertet das macht es Umsetzung Steam darüber.

In welcher Reihenfolge wir wann wir die Reihenfolge wie ändern können beispielsweise nicht umsonst diese.

Hanus klingt aber sehr ernst gemeinte Formulierung ist ist eine sortierte Liste dass es gibt keine zwei Einträge mit derselben Priorität sondern fängt mit einem Eintritt angeht mit dem nächsten weiter.

Infinitum und all dieses das ist er das Management der Anforderung das.

Ist das was mit dem Begriff Becker zu dir ins Korn definiertes eigentlich beschrieben ist Mazda tatsächlich als Inhalt drin steht.

Ist eine Frage der Ausprägung und das können User Stories sein das können und Körper aufgebaut sein.

[24:07] Das können die Einträge ans Lastenheft sein meistens glaube ich so wie ich das nächste bisher gesehen habe vor euch von deinem noch nicht so viele gesehen habe aber leichten glaube ich das ja unterschiedliche Kandidaten haben.

Weil häufig wenn wir einen Förderbeitrag haben was user-stories hat ihren sehr starker nutzt sehr starker Fokus auf den.

Party Benutzer Wahrnehmung und auf dem Benutzer nutzen.

Dann da ist während ich den Undercut mit dem Lastenheften häufig dass es dem Verhalten im Vordergrund steht aber das mag an Diskussionen,

Detail sein,

ja, jetzt wahrscheinlich nur eine eigene Episode zu machen aber ganz kurzes für mich ist der Nutzen den das System für den Benutzer stiftet eine relevante Maßgabe uns entscheiden ob eine Anforderung einer Lastenheft rein muss,

weil der Nutzen durch diese Anfrage stark erhöht wird oder überhaupt nicht rein darf weil mit dieser Anforderung der Nutzen kaputtgemacht würde oder ob ein neutrales dann sind meistens,

Rahmenbedingung klassisch nicht funktionale Anforderungen.

[25:16] Nicht funktionale Anforderungen weglassen und ein spannendes Thema.

Wir haben die Situation.

Dass wir Anforderung haben die wir auch dokumentieren ich meinen requirement engineering requirements management ist jetzt auch keine neue Disziplin vieles von dem was ich.

Auch so recherchiert und gefunden und darüber,

Detox gesehen habe zu dem Thema erinnert mich so an an die gute alte requirements-engineering Zeit von vor 35 Jahren da haben wir auch auf Karten Anforderungen draufgeschrieben holt er ist ja ein Sünden,

lea ist eins und eins und eins von damals und es hat sich ja diese dieses ganze,

Handwerkszeug des requirement engineering requirements Sven Schmidt hat sich aber die Firma sich ja auch weiterentwickelt faszinierend macht man dann da zu gucken was in.

In context grad gemacht wird wenn er manchmal dann dann das was vor 35 Jahren reg Wahnsinn vergiss mal ganz andere Person.

Aber manchmal ist es auch wirklich notwendig Sachen in einem Kontext neu zu entdecken das finde ich gar nicht schlimm.

Rufe zurückzufordern Bäcker was sind so die ganz typischen Probleme die du aus deiner Praxis damit immer wieder siehst.

[26:34] Die größten Probleme sind eigentlich immer die die gleichen.

[26:42] Die Leute nehmen es nicht ernst genug die Leute schreiben.

Sachen ins Product Backlog bei den sie vorher nicht abgesprochen haben was eigentlich drin steht.

[26:54] Da kann ganz viel drin stehen dann muss ich noch eingeben was man da drin stehen haben will das paclog wird zu.

Selten gemanagt und es wird dieser.

Der alte CCC Gedanke vergessen und das Vollbackup wird nur.

Alle paar Wochen je nachdem Vegetationsdauer ist angeguckt das größte Problem was ich glaube ich kenne ist das man.

Ja das Cordas paclog fertig schreibt.

Was führt mich jetzt abschließend zur letzten Frage was sind so deine drei Top-Empfehlung eben bei Portable Programme zu die Probleme gesehen.

Was würdest du sagen für den hören wenn es geht.

[27:44] Nun eine sehr schöne Frage ist die Frage wirklich.

[27:53] Auf welche Seite man anfängt wenn es nur um das fördert Becker geht würde ich wirklich als wichtigstes als erstes.

Sehen dass man sich an diese ganzen alten Regen hält das man tatsächlich eine klar sortierte Liste hat das man.

Sich drum kümmert dass der oberste Teil so klar definiert ist das die Leute die das hinterher umsetzen sollen zu diesem Zeitpunkt schon wissen was.

Damit tatsächlich gemeint ist dass man sich darüber einig lass den eigentlich drin steht der.

[28:31] Und wenn wir uns in diese Szene Grauzone.

Der Anforderung begeben finde ich ist es extrem wichtig sich darüber zu reinigen und sie hat anzuhalten dass man im vordersberg halt tatsächlich Anforderungen stehen hat Aussicht.

Des Benutzers nicht Aussicht desjenigen der das ganze bezahlt.

Sondern aus Sicht desjenigen der am Ende mit dem System arbeiten soll und.

[29:06] Das sind eigentlich so die die Hauptgänge ich glaube dass.

Was mir spontan einfällt bei der Frage ist sich an die ganzen alten Regeln halten müssen und das ist tatsächlich.

Ganz ganz wichtig speclog ist halt vor einigen etwas um.

Die Anforderung zu managen wie die Anforderung Aussehen ist noch ein ganz eigener Prozess.

[29:33] Okay bin ganz eigenes ist eine ganz eigene Abstimmung das muss man auch lernen und einfach nur Sachen.

[29:40] Bin total bekloppt stehen immer Stories ist so ein grundsätzliches Verständnis und nur weil etwas der Form als ein X Willich y damit z.

Nürnberger diese Formel entspricht hat man auch noch keine echte User Story dazu gehört halt ein bisschen mehr aber das ist wirklich ein ganz anderes Thema das Thema wie kriege ich einen Quader mit,

beschrieben mrgn Kontext für mich zusammenfassend ist das Product Backlog ein Methode ein.

Werkzeug im Grunde wo ich erstmal dieses ganze Thema.

Anforderungsmanagement wechseln kann man das Projekt Anforderung an das Produkt.

Alles erstmal kann ich da rein kippen und auch das Format wie ich es nicht ob das richtig sehe sie an die Regeln halten und eben eine gemeinsames Verständnis davon sagen was gehört rein was der Richter November Rain am Bast von den verschiedenen Sachen haben wir dann eigentlich dieser Stelle.

Herzlichen Dank Michael schön dass du dabei warst wieder Freude an Ehre und ich Tickets für dich das letzte Mal noch eine ganze Menge Themen würde mich freuen.

Auch schöne neue Studie zu sagen DANKE SCHÖN gut zusammenfassung,

Free hot Episode du musst schauen ob das Product Backlog in seiner Form die du jetzt hast wirklich für dich einen Nutzen stiftet und schau ob du nicht ein diese typischen Fehler begehst die wir besprochen habe fallen was ich dir sehr ans Herzen legen kann ist eben schau dir die Tipps an die dir.

[31:13] Michael gegeben hat du hast keine Lust dass das Budget für dein Projekt explodiert und die Termine gerissen werden,

dann wird es mit dem agilen Lastenheft auf die effektivste Möglichkeit dein Projektrisiko frühzeitig zu reduzieren du hast keine Zeit oder keine Erfahrung mein Team und ich erstellen dir ein professionelles Lastenheft innerhalb von zwei Wochen zum,

Festpreisen das Beste daran mit unserer Erfolgsgarantie gehen wir mit dir,

ins Risiko wenn du Interesse hast sprich mich einfach an das war die heutige Episode des zu uns Architekten der Projektmanagement Podcast Uhrmacher,

entweder ich bin Maik Pfingsten und danke dir fürs zuhören ich wünsche dir eine schöne Zeit nach viel und habe viel Spaß was immer du gerade machst und so sage ich tschüss und bis zum nächsten Mal.

ZA050: Scrum & Co – Agile Methoden einfach mal erklärt

07.05.2013



On Air in dieser Episode

Zusammenfassung

Ich habe eine Hörerfrage über Releaseplanung und Scrum erhalten. So habe ich mich mit Michael Mahlberg, dem absoluten Spezialisten zu agilen Methoden, wieder einmal getroffen. Wir unterhalten uns über Scrum und damit verbundenen Methoden in der Praxis. Ein Gespräch mit viel Spaß und Inhalt.

Der Inhalt dieser Episode:

  1. Was ist Scrum und wo macht es Sinn?
  2. Wie funktioniert Scrum in der Praxis?
  3. Welche Rollen gibt es im Scrum?
  4. Was sind Artefakte?
  5. Was ist ein Product und Sprint Backlog?
  6. Wie funktioniert Releaseplanung in Verbindung mit Scrum?

Themen: Scrum-Guide 2011, Agiles ManifestAgile Pyramide bzw. Dreieck, Scrum, Scrum in 5 Minuten, Scrum? Das ist doch das mit den Kreisen!, Vergleich von Scrum und KanbanAdaptive wave planning

Verweis auf weitere Episode mit Michael Mahlberg

Michael Mahlberg im Netz

Abonnieren Sie den kostenlosen Podcast und erhalten Sie zukünftig alle neuen Episoden direkt auf Ihr Smartphone:

ZA034: Podcast Retrospektive 2012 – Was war und wo geht es hin?

28.12.2012



On Air in dieser Episode

Zusammenfassung

In dieser Episode reflektiere ich mein Podcast-Jahr und erzähle über die Retrospektive, eine Methode aus dem Scrum, die ich genutzt habe um mein Podcast-Jahr zu reflektieren. Ich beschreibe, wie eine Retrospektive funktioniert, wie ich die Retrospektive angewandt habe und welche spannenden und auch für mich überraschenden Ergebnisse herausgekommen sind.

Ich sage an dieser Stelle aus vollem Herzen DANKE! an die Hörer. Danke für’s flattrn, danke für die Feedbacks, danke für die Hörertreffen. Es macht mir Spaß mit Euch zusammen eine Systems Engineering Community aufzubauen, in der wir uns vernetzen, Wissen austauschen und das Thema Systems Engineering weiter vorrantreiben. Ich freue mich schon auf ein wunderbares Jahr 2013, in dem wir gemeinsam diesen Podcast gestalten.

Der Inhalt dieser Episode:

  1. Retrospektive – Was ist das?
  2. Wie wird eine Retrospective durchgeführt?
  3. Ergebnisse der Retrospektive für den Podcast
    -> Was war in 2012?
    -> Was wird in 2013?

Themen: Der Start des Podcast, erste “verunfallte” Interview-Episoden, Entwicklung der Hörerzahlen, die Hörertreffen des Podcast, Top 10 Episoden, Veränderungen beim Podcast, BarCamp2013, weitere Podcast-Projekte, meine persönliche Entwicklung in 2013 als Speaker

Die Top 10 des Podcast:

  1. Episode ZA007: Lastenhefte vs. Pflichtenhefte
  2. Episode ZA014: Alles über wirkungsvolle Präsentationen
  3. Episode ZA008: 10 Tipps für ein effizientes Systemdesign
  4. Episode ZA018: Agile Methoden in der Praxis
  5. Episode ZA013: Geheimwaffe Reviews
  6. Episode ZA022: Agile Methoden, SPICE & Qualitätssicherung
  7. Episode ZA012: 10 Tipps zum Troubleshooting
  8. Episode ZA016: SysML in der Systementwicklung
  9. Episode ZA011: Was macht einen exellenten Systemingenieur aus?
  10. Episode ZA010: Modellbasierte Fehleranalyse

Buchtipps der Hörer:

Ich plane eine Episode mit den Buchtipps der Hörer für die Hörer, von Ingenieure für Ingenieure. Schicken Sie mir Ihre Buchtipps an feedback@zukunftsarchitekten-podcast.de

Hörertreffen 2013:

Die Hörertreffen in diesem Jahr waren für mich persönlich immer wieder ein Highlight. Ich werde auch in 2013 wieder Hörertreffen durchführen, damit wir uns vernetzen und Wissen austauschen. Wenn Sie Interesse haben ein Hörertreffen in Ihrer Region durchzuführen, dann schicken Sie mir einen Vorschlag an feedback@zukunftsarchitekten-podcast.de. Ich werde schauen, wie ich dann auf meinen Reisen durch die Republik mit dazukomme.

Die openPM Plattform:

openPM ist eine offene, frei zugängliche, unabhängige und nicht kommerzielle Plattform für Projektmanagement und alle, die an Projekten arbeiten. Ich kann diese Plattform sehr empfehlen und plane auch schon eine Episode mit den Gründern der Plattform.

Hinweise zu anderen Episode:

Abonnieren Sie den kostenlosen Podcast und erhalten Sie zukünftig alle neuen Episoden direkt auf Ihr Smartphone:

*Affilitate link

ZA028 Kanban & Co – Agile Methoden einfach mal erklärt

05.10.2012



On Air in dieser Episode

Zusammenfassung

Eine weitere spannende Episode mit Michael Mahlberg, dem absoluten Spezialisten zu agilen Methoden. Wir unterhalten uns über Kanban und damit verbundenen Methoden in der Praxis. Ein Gespräch mit viel Spaß und Inhalt.

Wir hätten mal wieder stundenlang weiter quatschen können, um es abzukürzen, planen wir noch eine dritte Episode. Wie sind Ihre Erfahrungen? Wie arbeiten Sie mit Kanban und wann war es hilfreich? Geben Sie uns Feedback.

Der Inhalt dieser Episode:

Weiterlesen

ZA019: Sprints & Weekly Builds im Systems Engineering

10.07.2012 26 Minuten



On Air in dieser Episode

Zusammenfassung

Eine kurze und knackige Episode in der ich über meine Erfahrungen mit dem Einsatz von agilen Methoden im Systems Engineering berichte. Als Troubleshooter brauche ich pragmatische und effiziente Vorgehensweisen um Projekte wieder in die Spur zu bekommen. Schon seit 2003 nutze ich dazu drei verschiedene Methoden (Releaseplanung, Sprints, Weekly Builds) und erweitere deren Einsatz kontinuierlich (Kanban). Weiterlesen

ZA006: 10 Buchtipps zum Systems Engineering

19.03.2012 9 Minuten



On Air in dieser Episode

Zusammenfassung

Heute eine kurze, dafür aber sehr wissenreiche Sendung. Seit Jahren fragen mich immer wieder Entwicklungsingenieure nach lesenswerten Büchern. Aus meiner großen Auswahl von selbst gelesenen Büchern habe ich zehn Tipps in dieser Sendung vorgestellt und meine Empfehlungen zusammengefasst. Weiterlesen

ZA005: The Critical Chain

09.03.2012 31 Minuten



On Air in dieser Episode

Zusammenfassung

Zu Gast ist Wolfram Müller. Er ist Leiter des Projektmanagement Office bei 1&1 und Mitentwickler der Methode “Critical Chain”, die er seit Jahren weiter vorran treibt. Wir unterhalten uns über die Entstehung der Critical-Chain Methode, dem Einsatz im High-Speed-Projektmanagement, der Praxiserfahrung bei 1&1 und der Lufthansa, die Verbindung zu agilen Methoden und der Verknüpfung zum System Footprint. Weiterlesen