Im Projektgeschäft gibt es verschiedene Wege, zum Ziel zu kommen. Vorausgesetzt, man kennt das Ziel. Viele große Unternehmen sind im Grunde ihres Herzens noch immer sehr klassisch aufgestellt, versuchen allerdings mehr und mehr, in die agile Welt hineinzuschnuppern. “Scrum hilft beim schnellen Scheitern” weiter lesen »
Archiv für die Kategorie „Projektmanagement“
Scrum hilft beim schnellen Scheitern
Dienstag, 14. Februar 2012Das agile Logbuch: ein Werkzeug für agile Teams
Donnerstag, 19. Januar 2012
Das agile Logbuch ist ein Werkzeug für die Mitglieder agiler Teams, um ihre Erlebnisse, Erfahrungen und Erkenntnisse während einer Iteration zu protokollieren. Es dient auch der Selbst- und Fremdreflexion mit dem Ziel, durch persönliche Weiterentwicklung die Teamarbeit zu verbessern. In der Retrospektive kann das Logbuch als Gedankenstütze dienen. Und es hilft dem agilen Coach, den Team-Status kontinuierlich zu ermitteln.
Wir haben das agile Logbuch unter eine Creative-Commons-Lizenz gestellt. Zu beziehen ist es über die URL
www.holisticon.de/AgilesLogbuch
“Das agile Logbuch: ein Werkzeug für agile Teams” weiter lesen »
Transparenz mit Transparenz – transparent.
Montag, 16. Januar 2012[Transparenz] (lat. transparens ‚durchscheinend‘), auch Durchsichtigkeit, adj.: transparent, durchsichtig
Quelle: http://de.wikipedia.org/
Scrum schafft Transparenz. Das wird nur zu schnell immer wieder deutlich.
Wird in einem Team, einer Abteilung oder einem Unternehmen Scrum eingeführt (und man hält sich am Anfang strikt an die Regeln), dann werden bisher verborgene oder verschwiegene Probleme schnell sichtbar. Dabei ist Scrum nicht der Auslöser der Probleme – im Gegenteil: Scrum in seiner schlichten Präzision befördert sie lediglich unbarmherzig ans Licht.
Damit einher geht eine andere Form der Transparenz, eine Offenheit innerhalb des Teams, die Probleme beim Namen zu nennen. Neben diesem Wert gibt es noch weitere vier – Mut, Respekt, Fokus und Commitment – die zusammen das Wertesystem von Scrum bilden. Es lohnt sich, hin und wieder über diese einfachen und scheinbar so selbstverständlichen Werte zu reflektieren. Inwieweit haben wir sie verinnerlicht? In welchem Maße bestimmen sie unseren Umgang miteinander, mit dem Kunden und unsere Kommunikationskultur?
Am Ende soll all das in den Hintergrund treten, transparent werden, und sich um die Arbeit des Teams wie ein äußerer Rahmen legen. Dieser Rahmen zieht Grenzen, die im besten Falle gar nicht mehr spürbar sind, weil sie angenommen wurden und zum Bestandteil des inneren Umweltmodells des Teams geworden sind.
Wenn davon gesprochen wird, dass ein guter ScrumMaster sich selbst überflüssig macht, dann ist das in diesem Sinne gemeint. Der ScrumMaster sorgt dafür, dass der Prozess gelebt wird, ohne dass er im Vordergrund steht, sondern unsichtbar über allem liegt. Dann kann sich der Fokus ungehindert auf die fachlichen Aufgaben richten und Scrum gibt Orientierung, sanfte Leitplanken und geschützten Raum.
Letztlich also tatsächlich: Transparenz mit Transparenz – transparent.
Hamburger Scrumtisch – die Termine 2012
Dienstag, 10. Januar 2012Die Xing-Gruppe “Scrum User Gr
oup Hamburg” trifft sich im Jahr 2012 alle zwei Monate, um agile Themen in einer entspannten Atmosphäre unter Gleichgesinnten zu diskutieren. Holisticon als einer der Sponsoren und Ausrichter dieses sogenannten “Scrumtisches” ermöglicht es auch in diesem Jahr wieder, die Hamburger Handwerkskammer als gediegene Lokation bei Getränken und einem kleinen Imbiss kostenlos zur Verfügung zu stellen.
Der Termin ist jeweils alle zwei Monate der zweite Donnerstag des Monats.
Macht dann also:
- 09. Februar
- 12. April
- 14. Juni
- 09. August
- 11. Oktober
- 13. Dezember
Weitere Informationen finden sich hier.
Aus dem Leben einer User Story
Freitag, 9. Dezember 2011Die User Story als Mittel zu Beschreibung von Anforderungen hat sich in der agilen Welt inzwischen etabliert. Sie ist schlank, hat auf einer Storycard Platz und wird z.B nach dem Muster Als [Rolle] will ich [Feature] um [Motivation] aufgeschrieben.
Sie beschreibt somit auf einfache Weise eine Funktionalität aus der Sicht des Benutzers, der sie sich wünscht. Um das allseitige Verständnis zu erhöhen, wird auch noch die Motivation – also was will der Benutzer damit erreichen bzw. anstellen – mitgegeben.
Das ist wirklich schlank und rank im Vergleich zu ausführlichen, detaillierten Anforderungsbeschreibungen und man fragt sich vielleicht, wie das gut gehen soll? “Aus dem Leben einer User Story” weiter lesen »
Product Owner, der agile König
Dienstag, 6. Dezember 2011In Scrum gibt es nur sehr wenige Rollen, in der ursprünglichen Fassung nur drei: das Team, den Product Owner und den ScrumMaster. Wenn wir in unseren Trainings die Rollen erklären, sind viele Teilnehmer eher verwirrt, wenn wir über die Wichtigkeit der einzelnen Rollen sprechen: “Product Owner, der agile König” weiter lesen »
Software-QS-Tag 2011: Test und QS agil
Donnerstag, 1. Dezember 2011
Am 2. und 3. November fand in Nürnberg der Software-QS-Tag statt. Seit 19 Jahren werden auf dieser Konferenz aktuelle Themen rund um Software-Qualitätssicherung und -Test diskutiert. Dieses Jahr hat das Programmkomitee ein Thema aufgegriffen, das in vielen Softwareprojekten mittlerweile angekommen ist und dort tiefgreifende Veränderungen bewirkt. Die Rede ist von agilen Vorgehensweisen, von denen das Projektmanagement-Framework “Scrum” der mit Abstand prominenteste Vertreter ist. “Software-QS-Tag 2011: Test und QS agil” weiter lesen »
BPM und Scrum – Erfahrungen aus der Praxis
Donnerstag, 10. November 2011In der jüngeren Vergangenheit stoße ich immer wieder auf Diskussionen – sei es nun intern mit meinen Kollegen oder beim Stöbern an einschlägigen Stellen im Netz – ob und wie BPM und Scrum gemeinsam zu Einsatz kommen können und wenn ja, wie. Ich nehme das an dieser Stelle zum Anlass, einige Erfahrungen aus der Praxis darzustellen.
Der Dämpfer zuerst
Ein Blick in das agile Manifest fördert zunächst Ernüchterung zutage:
„Individuals and interactions over processes and tools”
Na toll, das klingt auf den ersten Blick wenig erfolgversprechend. Aber schauen wir hinter die Kulissen und machen uns ein eigenes Bild. “BPM und Scrum – Erfahrungen aus der Praxis” weiter lesen »
Von Chefköchen, LÜK-Kästen und Sportbooten, oder: wie wir besser bessere Software bauen können (Teil 2)
Montag, 7. November 2011Im ersten Teil dieser Artikelserie habe ich David Snowdens Aussage “We [the IT professionals] focus on recipes, not chefs” analysiert und festgestellt, dass beim Verfolgen des “Rezept-Ansatzes” aus meiner Sicht zwei wesentliche Aspekte vergessen werden:
- Es genügt nicht, die Rezepte auswendig zu lernen (genau das tun die Unternehmen, wenn sie ihre Mitarbeiter schulen und zertifizieren lassen). Man muss zunächst Erfahrungen sammeln, bevor man in der entsprechenden Domäne tätig wird. Eigentlich nichts Neues – und trotzdem wird dieses uralte Grundkonzept des Lernens in der IT-Welt nur selten beherzigt.
- Die Existenz der Rezeptsammlungen allein reicht nicht aus. Die Rezepte (oft auch “Best Practices” genannt) müssen immer an die aktuellen Gegebenheiten des Unternehmens- und Projektumfelds angepasst werden.
Den ersten Aspekt habe ich im ersten Teil ausführlich beschrieben und am Beispiel meiner Sportbootführerscheinprüfung illustriert. Jetzt möchte ich mich mit der Frage beschäftigen, warum das sklavische Befolgen der Rezepte nicht immer zum gewünschten (oder besten) Ergebnis führt. “Von Chefköchen, LÜK-Kästen und Sportbooten, oder: wie wir besser bessere Software bauen können (Teil 2)” weiter lesen »
Von Chefköchen, LÜK-Kästen und Sportbooten, oder: wie wir besser bessere Software bauen können (Teil 1)
Donnerstag, 27. Oktober 2011In seiner Keynote auf der ALE2011-Konferenz beklagte David Snowden einen Trend, der seiner Meinung nach auch in der IT-Welt zu beobachten ist. Diesen Trend beschreibt er metaphorisch mit den Worten “We [the IT professionals] focus on recipes, not chefs”. Ein Rezept allein ist noch lange kein Garant für ein gutes Essen – von einem außergewöhnlichen Essen ganz zu schweigen. Das gibt’s nur vom Koch. Nicht etwa, weil der die Rezepte auswendig kennt, sondern weil er über jahrelange Erfahrung verfügt und schon Vieles ausprobiert hat. Ein Chefkoch braucht keine Musterküche, wie sie auf den Fotos der Hochglanzkochbücher zu sehen sind. Er braucht auch nicht exakt die Zutaten, die im Rezept (der “Spezifikation”) genannt sind. Dank seines Erfahrungsschatzes kann er Zutaten substituieren, ergänzen oder weglassen. Das Gericht schmeckt dann vielleicht anders, aber vermutlich ebenso gut (oder besser). “Von Chefköchen, LÜK-Kästen und Sportbooten, oder: wie wir besser bessere Software bauen können (Teil 1)” weiter lesen »