Autoren
In der neuen Interviewreihe „7 interessante Antworten von…“ möchte ich Ihnen Persönlichkeiten vorstellen, die in den Bereichen Projektmanagement und Agile Softwareentwicklung zu Hause sind. Sie berichten darüber, welche Erfahrungen sie in ihren Projekten gemacht haben, was sie aus der einen oder anderen Situation gelernt haben und welche Tipps sie angehenden ProjektmanagerInnen oder Scrum Master mitgeben möchten.
Wir starten die Reihe mit Ralf Wirdemann [42], dem Autor des Buches Scrum mit User Stories sowie vieler Fachartikel zum Thema Agile Softwareentwicklung. Ralf ist seit 8 Jahren als Projektmanager und Agiler Coach (CSM, CSP) aktiv und unterstützte schon viele Unternehmen bei der Implementierung von Scrum.
… mehr
- Kategorie: Interview
- Schlagworte: Agile, Agile Softwareentwicklung, Erfahrungen, Interview, Meinungen, Scrum
Das bei XING (www.xing.com) agil gearbeitet wird, ist meines Erachtens kein Geheimnis mehr. In der aktuellen Ausgabe des Fachmagazins OBJEKTsprektrum gibt es einen mehrseitigen Artikel zum Einsatz von Kanban bei XING.
Meine Kollegin Susanne Reppin sowie Ralf Wirdemann (Autor des Buches Scrum mit User Stories) beschreiben in dem Artikel, warum sie sich für den Einsatz von Kanban enschieden haben. Der gesamte Artikel steht als PDF Download auf dem XING Blog zur Verfügung.
Die gesamte Ausgabe widmet sich dem Thema Lean Development & Kanban. Ich habe die Zeitschrift kurz überflogen und finde sie sehr interessant. Es sind unter anderem Beiträge von Stefan Rook (www.stefanroock.de), Dr. Eberhard Huber (www.pentaeder.de) oder Arne Roock (www.it-agile.de) in der Ausgabe zu finden.
- Kategorie: Agile Softwareentwicklung| Zusammenarbeit
- Schlagworte: Agile, Kanban, Lean, Softwareentwicklung, XING
In meinem Blogbeitrag Erbsenschätzerei hatte ich vor ein paar Wochen eine Möglichkeit vorgestellt, den Teilnehmern eines Workshops die Wisdom of Crowds zu verdeutlichen, indem man sie erst individuell und dann als Gruppe die Anzahl von Erbsen in einem Glas schätzen lässt. In der Zwischenzeit habe ich sowohl mein aktuelles Scrumteam schätzen lassen als auch einige Leserzuschriften mit Schätzungen bekommen. Die Ergebnisse stelle ich in diesem Artikel vor.
Fangen wir mit dem Ergebnis des Teams an. Im Vergleich zu den Lesern des Blogs hatte das Team den Vorteil, das Erbsenglas anfassen und herumreichen zu können. Bestimmt gab es auch ein paar Schlaules, die schnell und unauffällig mal die Erbsen am Boden des Glases gezählt und hochgerechnet haben. … mehr
- Kategorie: Agile Softwareentwicklung| Management| Projektmanagement| Scrum| Studien & Umfragen| Umfrage| Zusammenarbeit
- Schlagworte: Agil, Agile, Estimation, Feedback, Games, Gruppe, Management, Methode, Projektmanagement, Schätzungen, Scrum, Spiele, Training, Zusammenarbeit
- New Site for Agile Managers and Team Leaders: http://www.management30.com/ #
- 78 things Jean Tabaka had learned as an agile coach: http://awe.sm/527ZZ #agile #
- Retrospektiven gestalten: http://awe.sm/527Zy #agile #meetings #team #
- Scrum in verteilten Teams: http://awe.sm/527an #scrum #team #
- Scrum – Keeping It Simple: http://bit.ly/cSEP3e #scrum #
- Kanban: Definition of Lead Time and Cycle Time: http://bit.ly/97AK7c #kanban #
- Deming’s 14 Points and Quality Project Leadership: http://bit.ly/bdGgjf #pmde #
- Deciphering Burndown Charts: http://bit.ly/d3Q2bc #
- Projektmanager brauchen Führungsfähigkeiten: http://awe.sm/52DHM #pmde #pmot #
- An Agile Architectural Epic Kanban System: http://awe.sm/52DHT #kanban #agile #model #
- The bliss of usability studies: http://awe.sm/52DHZ #agile #ux #testing #
- Kicking Off the Project Team: http://awe.sm/52DHc #pmde #pmot #
- Continuous Integration is great, but what about Continuous Delivery? http://awe.sm/52DHn #agile #presentation #
Heute einmal etwas ganz anderes. Naja, irgendwie passt es auch, da es sich um ein tolles Projekt handelt. Zudem schätze ich den Projektleiter sehr. Auf dem Blog von Jochen Mai (www.karrierebibel.de) bin ich auf das Projekt von David Lynch gestoßen: Interview Project.
Kennt Ihr das? Ihr sitzt mit einem Kollegen beim Mittagessen und tauscht Euch über Eure Projekte aus. Der Kollege erzählt, dass sein Projekt zwar irgendwie läuft, aber halt auch nur irgendwie. Die Luft ist raus, der anfängliche Enthusiasmus ist täglicher Routine gewichen und der Project Sponsor taucht auch nur noch sporadisch zu den Reviews auf. Das Team fragt sich, wofür es den Zirkus überhaupt noch macht, wird lustlos und unmotiviert, Meetings starten verspätet … Der Kollege überlegt, wie er dem Ganzen wieder etwas Schwung geben kann, wie der den alten Power-Zustand wiederherstellen kann.
Die Literatur bietet natürlich Hilfe. Da ist von gruppendynamischen Prozessen die Rede, Analysen sollen gemacht werden, Teamevents werden die Welt und das Projekt retten … aber ist das Team das Problem? Und kann man das Handlungsfeld nicht zunächst auch einfacher angehen? Als Anhänger des KISS-Prinzips, stelle ich dem Kollegen in so einem Fall gern eine einfache Frage:
- Kategorie: Management| Projektmanagement| Zusammenarbeit
- Schlagworte: Agile, Kommunikation, Management, Organisation, Produktivität, Projekt, Projektmanagement, Team, Zusammenarbeit
Interessanter Artikel sowie schöne Präsentation zum Thema integriertes Projektmanagement von Stefan Hagen (www.pm-blog.com). Stefan wirbt für einen neuen Methodenansatz, der traditionelle Managementmethoden mit neuen (agilen) Methoden und Werkzeugen verbindet.
“… das bedeutet eben NICHT, dass traditionelle Ansätze und Methoden nun keine Gültigkeit mehr haben, und alle Projekte nur noch agil geführt werden sollten. Vielmehr sollten wir ein möglichst breites Methodenverständnis haben, um so die richtigen Werkzeuge und Vorgehensweisen zur richtigen Zeit anzuwenden.” [Stefan Hagen]
Integriertes Projektmanagement
- Kategorie: Management| Projektmanagement
- Schlagworte: Methoden, Projektmanagement
- Testing Small Stories: http://awe.sm/51r27 #agile #test #
- Organizational Objections To Agile Process: http://awe.sm/51r2C #
- Open Source Scrum Software: http://www.opensourcescrum.com/ #agile #tools #
- 10 things Kelly Waters hates about agile development: http://awe.sm/51r2w #
- 100 Project Management Blogs/Websites: http://awe.sm/51r3J #pmde #pmot #
- From Concept to Product Backlog: http://bit.ly/9exXKr #userstories #agile #po #
- Eine Vision haben: http://bit.ly/9IOcyV #apple #
- Effizient Meetings gestalten: http://awe.sm/51ut6 #
- Warum Pairpgrogramming? Darum: http://awe.sm/51y1P #pairprgramming #agile #softwaredevelopment #
- Technische Schulden überwachen: http://awe.sm/51y1W #technicaldebt #
- Interessanter Artikel: Are we agile yet? http://awe.sm/51y1u #agile #
- Skaliert Agile Softwareentwicklung? http://awe.sm/51y1z #agile #scale #
- Getting Started With Agile… One of Five: http://awe.sm/51ykN #agile #
Häufig werden (Projekt)Manager mit Dirigenten verglichen bzw. als solche bezeichnet. Sie leiten ihr Ensamble und versuchen mit Hilfe von Standards und Tools ein erfolgreiches Gesamtkunstwerk zu schaffen. Jeder (Projekt)Manager agiert hier anders: der eine kontrolliert mehr, der andere weniger. Manche schaffen Freiräume, manche setzen starre Grenzen.
“Taktschlagen kann man in fünf bis zehn Minuten lernen, alles andere aber macht jeder Dirigent anders.“ [Daniel Harding]
Bei Thomas Weller (www.thomasweller.de) bin ich auf einen tollen TED Vortrag aufmerksam geworden. Die Idee des Vortrags und der Vortragsstil sind grandios. Der Vortrag ist schon einige Jahre alt, aber die 20 Minuten lohnen sich wirklich.
Doing without Doing
Passend zum Thema habe ich diese Aufnahme von Deutschlandradio Kultur mit dem Titel Richtig Führen – Manager üben sich im Dirigieren eines Orchesters gefunden.
- Kategorie: Management
- Schlagworte: Dirigent, Führung, Kontrolle, Leitung, Management, Projektmanager, Team
- Agile Product Owner Adoption – Why’s it so hard? http://awe.sm/51JTx #agile #
- Product Owners in Practice: http://awe.sm/51JUN #agile #po #
- Team Members More Productive: http://awe.sm/51K3C #team #agile #
- 10 Eigenschaften erfolgreicher Projektteams (Teile 1-6): http://awe.sm/51OXz #team #pmde #pmot #
- Professional ScrumMaster (certified by bor!sgloger): http://bit.ly/9eFFNQ #
- 5 Reasons Why Agile Development Must Be Driven from the Top: http://bit.ly/bNR3L7 #agile #
- Über die agile Arbeit der Sys-Admins bei XING: http://awe.sm/51S6E #agile #kanban #xing #
- Agile – A Way of Life and Pragmatic Use of Authority: http://awe.sm/51Spi #agile #
- 3 Legs to Standing Up an Agile Project: http://awe.sm/51aeH #agile #
- Dedicated Product Teams: http://awe.sm/51aea #agile #team #po #product #
- 5 Gründe, die PMP Prüfung zu verhauen: http://awe.sm/51afb #pmde #pmp #exam #
- Using Cucumber for BDD and Agile Acceptance Testing: http://awe.sm/51afz #
- Kommunikation im Projekt: http://awe.sm/51f2l #pmde #agile #
- 4 Simple Principles of Getting to Completion: http://awe.sm/51f4i #gtd #
Im letzten Jahr hatte ich das große Vergnügen, an einem Vortrag von Peter Taylor teilzunehmen. Peter sagt von sich selbst, dass er ein Lazy Projectmanager sei. Diese provokante Bezeichnung macht natürlich neugierig. Nun haben wir vermutlich alle in der Schule gelernt, dass das englische Wort “lazy” auf deutsch “faul” bedeutet. bab.la Wörterbuch übersetzt “lazy” mit “faul”, “langsam”, “träge” und “lustig”. Keine dieser Übersetzungen wird aber einem Lazy Projectmanager gerecht.
Peter bringt das Beispiel des preußischen Generalfeldmarschalls Helmuth Karl Bernhard Graf von Moltke (*1800 – †1891), der seine Offiziere in vier Kategorien eingeteilt hat:
Kategorie A: dumm und faul
Kategorie B: intelligent und tatkräftig
Kategorie C: dumm und tatkräftig
Kategorie D: intelligent und faul
- Kategorie: Allgemein| Management| Projektmanagement
- Schlagworte: Leadership, Management, Organisation, Projekt, Projektmanagement
Vor einiger Zeit habe ich darüber berichtet, dass wir in unserem laufenden Projekt über die Definition of Done (DoD) gesprochen haben, um diese zu überprüfen und zu erneuern. Dabei kam von den Teammitgliedern der Vorschlag, Cucumber (www.cukes.info) als Teil der DoD einzusetzen. Ein großartiger Gedanke, wie sich herausstellte.
BDD – Ein kurzer Exkurs
Behavior Driven Development (BDD) ist eine Form des agilen Entwickelns, welches es den Softwareentwicklern und Testern eines Teams sowie dem Business Verantwortlichen (oder Stakeholdern) ermöglicht, auf einer Ebene zu kommunizieren. Das bedeutet, die Testfälle werden so geschrieben, dass die Stakeholder sie lesen können – in “Plain Text”. Es wird dabei nicht wie in der testgetriebenen Entwicklung (TDD) ein Testfall definiert, sondern eine Erwartung. Diese kann bspw. ein Akzeptanzkriterium für ein Backlog Item darstellen. Man kann somit sagen, dass eine ausführbare Spezifikation des zu entwickelnden Features geschrieben wird.
Einen kurzen Überblick zu BDD und den Einsatz von Cucumber gibt diese nette Präsentation:
Was es uns bringt
Mal davon abgesehen, dass es dem Team Spaß macht mit Cucumber zu arbeiten und die Implementierung sehr schmerzfrei verlief, führt es dazu das:
- das Team schneller und sicherer entwickelt
- alle Beteiligten mehr miteinander kommunizieren
- alle verstehen, welche Erwartungen/Anforderungen bestehen
- ein besseres Verständnis über das gewünschte Ergebnis entsteht
- die Nebenwirkungen von Code-Änderungen offensichtlicher sind bzw. zeitnaher entdeckt werden
- besserer Code geschrieben wird (siehe auch das eher technische Video Good Test, Better Code – From Unit Testing to Behavior-Driven Development)
- die Testumgebung für andere Projekte nutzbar gemacht werden kann
Weitere Tools für den Einsatz von BDD finden Sie hier.
- Kategorie: Agile Softwareentwicklung| Scrum| Zusammenarbeit
- Schlagworte: BDD, Cucumber, Cuke, Entwicklung, QA, Software, Software Craftsmanship, TDD, Test, Testing
Im Januar wurde mein Antrag auf Zertifizierung zum Certified Scrum Practitioner (CSP) durch die Scrum Alliance angenommen. Wie wird man Certified Scrum Practitioner und was bedeutet das eigentlich?
Certified Scrum Practitioner
Wie im nebenstehenden Chart zu sehen ist, bildet die Zertifizierung zum Scrum Master (CSM) oder Product Owner (CSPO) den Auftakt für die Zertifizierungsreihe der SA. Aufbauend auf diese Zertifikate kann man mit dem Scrum Practitioner nachweisen, dass man im letzten Jahr Scrum eingesetzt hat. Danach folgen die Zertifikate zum Scrum Coach (CSC) und Scrum Trainer (CST).
Was muss ich tun, um CSP zu werden?
Die Voraussetzung um den Antrag stellen zu können, ist die Tätigkeit als CSM oder CSPO in einem Scrum Projekt. Das Antragsformular kann auf der Scrum Alliance Website heruntergeladen werden. Es beinhaltet 14 spezifische Fragen zu einem Scrum Projekt, an dem man innerhalb des letzten Jahres aktiv teilgenommen hat und 6 Fragen über Scrum generell. Dieser Antrag wird dann per Email an die Scrum Alliance geschickt. Nach einigen Wochen erhält man die Antwort, bezahlt die Gebühr von $250 und darf für zwei Jahre den Titel tragen.
Und was heißt das jetzt?
Im Grund nicht viel. Die CSM und CSPO Zertifikate sind reine Nachweise eines Trainings. Das CSP Zertifikat ist eine Bescheinigung über das Sammeln von praktischen Erfahrungen in einem Scrum Projekt. Es sagt demnach nicht wirklich etwas über die Qualität, den Wissensstand und das Können des Halters aus. Der CSP Titel befähigt den Inhaber nach einigen weiteren Jahren an Erfahrungen im agilen Umfeld, inkl. bestimmter Voraussetzungen, sich den Titel des Scrum Coaches oder Scrum Trainers zu erarbeiten.
Mike Cottmeyer hat vor einigen Tagen die Sinnhaftigkeit der Zertifizierung der Scrum Alliance angezweifelt und eine nicht ganz uninteressante Diskussion angestoßen.
Nichtsdestotrotz bin ich froh über das Geschaffte und werde auf jeden Fall weitermachen. Weiter Lesen, weiter Schreiben und weiter Erfahrungen sammeln.
- Kategorie: Agile Softwareentwicklung| Scrum| Zertifizierung
- Schlagworte: Agil, Agile, Certified Scrum Practitioner, CSC, CSM, CSP, CSPO, CST, SA, Scrum, Scrum Alliance, Scrum Coach, Scrum Master, Scrum Trainer, Zertifikat, Zertifizierung
Durch Zufall bin ich vor einiger Zeit, bei einem Gespräch mit einem Entwickler aus einem meiner aktuellen Scrum Teams, darauf aufmerksam geworden, dass er freizeitlich Herz Meditationen praktiziert. Tja, so wie Sie jetzt wahrscheinlich gucken, habe ich sicherlich auch ausgeschaut – aber es macht Spaß, das Innere Lachen zu praktizieren.
Aus dem Gespräch ergab sich die Idee, einmal pro Woche eine Herz Meditation für die Mitglieder des Teams anzubieten. Nun sitzen wir seit einiger Zeit einmal wöchentlich am Morgen in einer kleinen Runde und meditieren gemeinsam. Selbstverständlich ist die Teilnahme freiwillig. Praktisch läuft diese fünfzehnminütige Session nach folgendem Schema ab:
- Alle setzen sich aufrecht und bequem hin und schließen die Augen
- Dabei ist die Atmung ruhig und entspannt
- Durch Anweisung geht man den Körper von oben nach unten durch, um die Körperpartien zu entspannen
- Man ist aufgefordert sein innerstes Zentrum zu spüren
- Danach lacht man diesem innersten Zentrum selber zu, jeder für sich
- Dann können die Augen wieder langsam geöffnet werden und
- der Arbeitstag kann beginnen
Auch ich kann meine Vorurteile gegen esoterische Methoden nicht verschweigen, wollte mich aber einfach mal überraschen lassen. Nicht nur das ich es ganz angenehm empfinde, diese Zeit gezielt einzusetzen, um vor dem anstehenden Arbeitstag noch einmal zu entspannen, viel wichtiger finde ich, dass wir es als Gemeinschaft – als Scrum Team – tun.
Es schweißt zusammen, da man zuerst eine Hemmschwelle überwinden muss, weil man zusammen lacht, Zeit miteinander verbringt und sich austauscht.
- Kategorie: Agile Softwareentwicklung| Zusammenarbeit
- Schlagworte: Kommunikation, Lachen, Meditation, Scrum, Team, Vertrauen, Zusammenarbeit
Copyright ® 2010 - Projekt-log.de - Anmelden
Letzte Kommentare