setzwein-blog - Latest Comments

Re: Kanban im Weihnachtsgeschäft

dchl — Thu, 22 Dec 2011 11:46:21 -0000

Spannend!

Re: Scrum motiviert Ihr Team! Sicher?

dchl — Wed, 26 Oct 2011 12:53:18 -0000

Sehr schön dargelegt, Herr Hansen – Respekt!

Re: Scrum nicht nur für Software ?!

Thomas Lieder — Sat, 24 Sep 2011 14:53:06 -0000

Hallo Herr Diedrich,

Sie haben sicherlich recht, ein iteratives Vorgehen sicherlich im Prinzip auch mit "echten" Gegenständen, und damit auch im Baugewerbe, möglich. Die schrittweise Annäherung an ein Ziel impliziert aber auch das ständige Be- und Überarbeiten des bereits Erreichten. Und an diesem Punkt wird es außerhalb der Welt der immateriellen Güter schwierig: Wie soll man ein Haus realisieren, bei dem kurz vor dem Richtfest dem Bauherrn einfällt, dass er doch noch einen Keller haben möchte. Software und andere "weiche" Güter erlauben hier einen - meiner Meinung nach - deutlich größeren Änderungsspielraum.

Viele Grüße,
Thomas Lieder

Re: Über Petzen, Unschuldslämmer und Beleidigte Leberwürste: Sandkastenspiele im Unternehmen

Detlef Engelbrecht — Fri, 19 Aug 2011 05:45:55 -0000

Ein Deja Vu der besonderen Art :-)

Re: Scrum nicht nur für Software ?!

I. Diedrich — Fri, 15 Jul 2011 13:57:36 -0000

Hallo Thomas Lieder
Das iteratives Annähern als das zentrale Merkmal für scrum scheint mir stimmig.
Stutzig macht es mich, dass sie dies nur bei immateriellen Gütern sehen. Es stimmt, dass z.B. im Baugewerbe u.a. aufgrund des hohen Zeitdrucks iteratives Annähern kaum anzutreffen ist. Dies ist aber nicht eine prinzipielle Grenze im Baugewerbe bzw. in physischen Projekten.

Es ist durchaus möglich, ein Haus langsam wachsen zu lassen. Also sich gemeinsam mit dem Kunden iterativ annähern. Ähnlich wie ein Künstler, seine physische Skulptur immer wieder ummodeliert bis sie stimmt.
Mir ist klar, dass dieser Gedanke eher weltfremd erscheint. Mir ist aber auch wichtig, dass die Möglichkeiten der neuen Perspektive tatsächlich ausgelotet werden.
Viele Grüße
I. Diedrich

Re: Gewissensmanagement

Paul Reinbacher — Fri, 11 Mar 2011 05:58:36 -0000

Sg. Frau Dr. Setzwein, ich schließe mich gerne Ihren Wünschen, "man würde das 'Gewissen' viel häufiger zum Thema machen" an, und habe bereits versucht, meine Überlegungen zum Thema "Gewissensmanagement" hier zusammenzufassen, wie Sie möglicherweise bereits festgestellt haben: http://www.amazon.de/dp/353116... bin aber weiterhin an dem Thema dran und freue mich, weiterhin von Ihnen zu hören/lesen ...
Für den Moment, schöne Grüße aus dem einigermaßen frühlingshaften Wien,
Paul Reinbacher

Re: Product Owner und Projektmanager

Thomas Lieder — Fri, 18 Feb 2011 03:01:22 -0000

Es geht hier - wie so häufig - um Kommunikation.
Es bleibt ja unbestritten, dass in einer idealen Welt die Rolle Product Owner mit allen ihren Aufgaben von genau einer Person ausgefüllt werden kann. Leider habe ich dies so noch nicht erlebt. Es bleibt also die Aufgabe, den - meist fachlich sehr guten - Product Owner zu unterstützen. In dieser Situation ist es nicht hilfreich, nebem dem Product Owner einen Projektmanager zu installieren.
Es wird eine neue Rolle etabliert und damit das Konzept von Scrum in Frage gestellt. Anstatt also das eigentlich Problem zu lösen, schafft man eine Reihe neuer. Wenn also der Product Owner Unterstützung bekommen soll, löst man dies am besten, indem der Rolle mehrere Personen zuweist. Diese können sich die Aufgaben teilen, ohne dass es zu Diskussionen um Scrum als solches kommt.

Re: Product Owner und Projektmanager

Christian B. — Thu, 17 Feb 2011 06:23:48 -0000

Mmmmh... klingt für mich nach "Wir haben einen Product Owner & einen Projektmanager, und nennen sie beide Product Owner"... Wo ist der Unterschied? Denn doch auch Projektmanager und Produkt Owner kann man unterschiedliche Aufgabenbereiche zuweisen, und beide müssen erfolgreich zusammenarbeiten.
Sorry, aber für mich sieht das nach "Mogelpackung" aus.

Re: Wertschöpfung durch Wertschätzung

Siegfried Kaltenecker — Tue, 21 Dec 2010 03:29:21 -0000

good point. einfach, aber stimmig - wie auch unser ergebnis aus amsterdam beweist. siehe http://p-a-m.org/2010/12/a-rec...

Re: ‘Bleib mal locker’

Elisabeth Kaeppel — Tue, 07 Dec 2010 16:42:56 -0000

Dies trifft auch im ganz normalen Leben -Familie-Teilzeitjob zu,
mein oberstes Gebot ist "locker zu bleiben" im Kopf gedacht: der Weg nach oben ...
ist immer frei (ist genug Platz für alle) und die Gewissheit eins zu sein mit allem und frei zu sein ...

Re: Scrum – Fußball oder Olympia?

Frank Wiczinowski — Tue, 23 Nov 2010 04:46:46 -0000

Geld allein schießt keine Tore, dass hat man am Wochenende wieder im Spiel St.Pauli gegen VFL Wolfsburg gesehen. St. Pauli hat mit Teamgeist und guter Taktik die mit Stars gespickten Wolfsburger klar dominiert und nur durch eine Unachtsamkeit das Gegentor zum 1:1 Ausgleich kassiert. Das Tor für St. Pauli hat kein Stürmer sondern der Abwehrspieler, Markus Thorandt geschossen. Klar am Ende der Saison wird sich zeigen ob Teamgeist und eine gute Taktik in der Endabrechnung reicht. Auf der anderen Seite wird wieder mal deutlich, dass 11 super Spezialisten und echte fußballerische Granaten noch kein gutes Team ergeben und den Erfolg garantieren.

Die Spielregeln kann man natürlich nicht ändern, dann wäre es ja kein Fußball mehr. Jeder bekommt seinen Ball und schießt Tore hört sich wie eine Zirkusnummer für den armen Torwart an. Aber über Takttick kann man natürlich gerne Diskutieren.

Die Taktik, dass jeder Spieler (Spezialist) einen eigenen Ball (Story) hat und zum Sprintende abschließt könnte funktionieren wenn die Stories völlig unabhängig voneinander und überschaubar sind. Und ob Qualitätseinbußen akzeptabel sind hängt sicher auch von der Anwendung ab. Was ist wenn die Spezialisten unterschiedlich gut oder erfahren sind? Denn nicht jeder Spezialist ist auch ein guter Spezialist.

Re: Scrum – Fußball oder Olympia?

Christian — Mon, 22 Nov 2010 11:07:15 -0000

Das Beispiel habe ich auch kürzlich auf dem Scrum-Day in Berlin gehört.

Folgende Geschichte aus meiner Praxiserfahrung: Wir haben ein Team mit Spezialisten und Individualisten. Die Strategie (wenn man es so nennen mag) ist nun, jeder Spieler hat einen Ball (=Story) und stürmt nach vorne um Tore zu schiessen. Dadurch dass dieses Team nun sieben Bälle statt einem hat, schiesst es im Ergebnis mehr Tore als die anderen Teams.

Natürlich gehen einige Bälle daneben und sie kassieren auch ein paar Treffen. Sprich, die Gesamtqualität ist schlechter. Aber der Output (=Tore=Anzahl akzeptierter Stories) ist höher als bei anderen Teams.

Was tun? Zu sagen, beim Fussball gibt es eine Regel "Nur ein Ball" ist mir nicht originell genug...

Re: Finstere Zeiten – die ewige Kluft zwischen Visionen und Umsetzung

setzwein — Wed, 10 Nov 2010 02:44:03 -0000

Hallo Oliver,

da habe ich leider auch keinen passenden Tipp für Sie zur Hand. Vielleicht gibt es eine Möglichkeit, den Film privat zu entleihen?

Viele Grüße,
Monika Setzwein

Re: Finstere Zeiten – die ewige Kluft zwischen Visionen und Umsetzung

Oliver — Tue, 09 Nov 2010 11:30:46 -0000

Hallo,
gibt es eine Möglichkeit als Privatperson diesen Film zu kaufen?
Bei filmwerk.de geht dies nicht als Privatperson.
Bei drs.de muss man im stuttgarter Raum sein...

Wäre für Hinweise sehr dankbar!
Oliver

Re: Teamziele erreichen – Wissensinseln auflösen

Thomas Lieder — Tue, 02 Nov 2010 10:23:31 -0000

Hallo Herr Wagner, Pair-Programming ist sicherlich einer der elegantesten Möglichkeiten, Wissen weiterzugeben. Aber auch hier gilt, dass die Methode nur erfolgreich ist, wenn die jeweiligen Teilnehmer ein eigenes Interesse daran haben, über den Tellerrand zu schauen und ihr Wissen zu erweitern.

Re: Teamziele erreichen – Wissensinseln auflösen

Michael Wagner — Fri, 22 Oct 2010 03:37:49 -0000

In unserem kleinen 5 Mann Team sind wir Entwicklungsseitig dazu übergegangen, verstärkt auf Pair Programming zu setzen. Das senkt zwar erst mal die Velocity, sorgt aber für einen Wissenstransfer.

Re: Akzeptanzkriterien effektiver einsetzen

Katja Roth — Thu, 02 Sep 2010 15:14:24 -0000

Hallo Herr Görn, das ist genau richtig. Im Sprint Planning kommt es ja typischerweise zu Diskussionen. Die Ergebnisse werden dann live in Form von Akzeptanzkriterien aufgenommen.

Re: Akzeptanzkriterien effektiver einsetzen

Christoph Görn — Wed, 01 Sep 2010 04:55:53 -0000

Hallo auch, ich frag mich grad wie es praktisch abläuft wenn "Details, wie etwa Wertebereiche von Eingabefeldern erst im Sprint Planning verabschiedet" werden?! Das ist dann eher eine Diskussion während des Sprint Plannings und der PO dokumentiert dies just in time?

Re: Getting Things Done

notebook akku — Fri, 13 Aug 2010 09:17:25 -0000

Aber es hilft mit sehr einfachen und logischen Tricks die Dinge zu ordnen und gezielt abzuarbeiten. Natürlich gibt es auch eine Vielzahl von GTD Tools.

Re: Prezi – Präsentieren einmal anders

valentinheyde — Mon, 14 Jun 2010 07:55:54 -0000

Volle Zustimung! Großartig ist Prezi vor allem auch an Stellen, wo während der Präsentation - etwa wegen Publikumsinteraktion - vor oder zurück gesprungen wird. Oder der Vortragende sich spontan dazu entscheidet, einen Bereich nur zu überfliegen und nicht ins Details zu zoomen. Wirklich eine ansprechende Abwechslung. Wenn es gut umgesetzt ist.

Re: Die Projektkladde

Christian — Mon, 31 May 2010 13:53:44 -0000

Das ist eine gute Liste. Die Regeln erinnern mich an meine "25 Notizbuchregeln", die ich im Notizbuchblog veröffentlicht habe. Ich startete mit http://www.notizbuchblog.de/20... und bin vorläufig bei http://www.notizbuchblog.de/20... angelangt. Ich möchte die Regeln demnächst auch als E-Book publizieren.

Re: Akzeptanzkriterien im agilen Projektmanagement

Ralf Wirdemann — Tue, 25 May 2010 09:10:29 -0000

Hallo Katja, ich teile deine Einstellung bezüglich der Notwendigkeit und Wichtigkeit von Akzeptanzkriterien und mache leider auch häufig die Erfahrung, dass sie zu selten ernst genommen werden. Hier ist der Scrum Master / Coach gefragt, der den Product Owner an die Hand nehmen und ihn beim Schreiben der Tests unterstützen muss. Erfahrenen QA-Leute können das auch. Ich habe gute Erfahrung damit gemacht, dass QA- und Product Owner vor dem Sprint Planning gemeinsam dafür sorgen, dass die Stories des kommenden Sprints vernünftige Akzeptanzkriterien bekommen. In richtig guten Teams schreibt der Product Owner und/oder die QA dann sogar selbständig die Cucumber/JBehave-Tests.

Re: Scrum Tools – Anfassen erwünscht!

Manuel Wiedenmann — Fri, 08 Jan 2010 12:28:00 -0000

Kann mich deiner Empfehlung nur anschließen. Auch meine Erfahrung zeigt, dass die digitalen Dinge schnell in Vergessenheit geraten und niemand mehr eine wirkliche Übersicht hat.
Gerade was das Commitment angeht, finde ich alles analoge, also anfassbare viel sinnvoller.

Re: Software für Scrum

teckmx5 — Thu, 11 Jun 2009 16:44:20 -0000

Die Frage ist aus meiner Sicht nicht, ob ein Tool sinnvoll ist, denn das muss jedes Team für sich entscheiden. Denkt man an verteilte Teams, dann wir das Planning Meeting mit Excel oder einer Pinnwand schwierig. Die Frage ist vielmehr, wann der Einsatz eines Scrum Tools sinnvoll ist. Auch wenn Tools wie z. B das open Source Tool Agilo for Scrum (<a href=http://www.agile42.com/cms/pag... viele nützliche Tipp und Hilfen geben, um Scrum umzusetzen, bin ich der Meinung, das zuerst der Prozess gelebt werden muss, bevor man sich nach einem passenden Tool umsieht.
Ein Tool ist nie ein Garant für eine erfolgreiche Scrum Einführung.

Teck

Re: Planning Poker – besser schätzen

TomK32 — Mon, 10 Nov 2008 03:51:15 -0000

Ja, Poker ist nötig. Selbst wenn man die Abschätzung gemeinsam macht tendieren die Junior Devs doch dazu nur einem der erfahrenen oder auch einfach nur dem davor nachzuplappern.

Aber zu deiner Einleitung: Ein Feature über 8 Tage darf's nicht geben. Das muss man aufsplitten und dann wird auch die Zeitschätzung viel realistischer.

PS: Registrierungspflicht für's Kommentieren ist voll öde.