Microsoft entwickelt Agil

Im neuen Spiegel: Microsoft entwickelt agil – mit allem drum und dran: Paarprogrammierung, Testgetriebene Entwicklung, Kontinuierliche Integration, Kundeneinbeziehung! Mit Erfolg? Man wird sehen, aber bislang siehts gut aus, besser als vor dem Vista-Start allemal.

Jens Coldewey scheibt dazu: „agile Entwicklung ist jetzt nicht mehr nur Sache der Pioniere, sondern wird nach und nach zum entscheidenden Wettbewerbsvorteil“

Ja! Genau! Es gibt schon lange die Behauptung, dass der Produktivitätsunterschied in der SW-Entwicklung bis zu 20 betragen kann. Nicht 20%, sondern Faktor 20. Ein High-Performance-Team mit 5 Leuten kann also genauso viel schaffen wie eine Entwicklungsabteilung mit 100. Ich denke, durch konsequente Anwendung Agiler Prinzipien, Werten und Methoden wird die Schere zwischen High- und Lowperformern (Teams, Projekten, Firmen, Volkswirtschaften)  größer. Sichtbarer! Messbarer (in Umsatz und vor allem: Gewinn)! Mit dem Ergebnis, dass die Nischen, in denen sich viele IT-Unternehmen es sich (hierzulande?) ganz bequem eingerichtet haben und vor sich hin puzzeln, immer enger werden bis sie nach und nach austrocknen, weil die flexiblen, hochperformanten Firmen sie vom Markt fegen. Siehe Google. Vielleicht jetzt auch wieder Microsoft – und Big Blue?

Doch jammern gilt nicht – was für eine Chance!!!

PS: Zum Thema Akzeptanz von agiler Entwicklung: there is a big pink Elephant (from Redmond) in the room…

Schritt für Schritt statt Masterplan – warum agile Prinzipien besser passen

Bin gerade über die Aspiration Adaption Theory gestolpert. Vereinfacht ausgedrückt sieht es wohl so aus, dass Menschen immer bzw. bevorzugt heuristisch vorgehen. Treten also Probleme auf, deren sichere Lösung nicht bekannt ist, wird anhand von sog. Daumenregeln oder nach Bauchgefühl entschieden. Es werden eben keine ausgefeilten Kosten-Nutzen-Lösungen angestellt, und wenn doch, so vermute ich, dass der Mensch, der sie anstellt, solange daran herumrechnet, bis das Ergebnis mit seiner persönlichen Heuristik, die schon längst zu einem Ergebnis gekommen ist (also seinem Bauchgefühl), übereinstimmt. Diese Entscheidung nach Kosten-Nutzen-Analyse ist ja auch ein Fundament der Homo-Oeconomicus-Theorie, die Gunter Dueck in seinem letzten vorletzten Buch so schön polemisch widerlegt hat.

So, und was hat das jetzt mit Agilem Projektmanagement zu tun? Alle Projektbeteiligten (Stakeholder) sind Menschen (oder?). Wenn alle letztlich in jeder Situation des Projekts heuristisch vorgehen (auch wenn viele natürlich was anderes behaupten), kann es jederzeit zu einer Änderung der Projektziele bzw. Rahmenbedingungen kommen. Klassisches Projektmanagement geht aber strikt von der Annahme aus, dass am Anfang des Projekts (in der Analyse/Zielfindungsphase) die Projektziele und Rahmenbedingungen nach quantitativen Methoden FESTgelegt werden. Danach werden durch Aufsetzen eines Change-Managements die Kosten für Änderungen daran massiv erhöht (um sie zu minimieren) : am Anfang des Projekts darf man sich noch alles Mögliche wünschen, ist das Projekt aber einmal bis zum Ende durchgeplant, kostet jede Kleinigkeit Unsummen.

Agile Prinzipien hingegen heißen Änderungen willkommen und richten den Arbeitsprozess dahingehend aus, Änderungen mit möglichst geringen Prozesskosten aufnehmen zu können. Nur innerhalb eines Sprints (der ja kurz sein soll, max. 4 Wochen) dürfen Anforderungen nicht geändert werden (notfalls wird der Sprint halt gestoppt), danach ist für den nächsten Sprint alles wieder offen!

1:0 für Agilität!

Kalendereintrag: TDWI-Roundtable, SCRUMtisch und BI-Networking im Juli

Am 2.7. plane ich, zum ersten Mal zum TDWI-Roundtable in Hamburg zu gehen. Thema ist: Business Intelligence in der Krise. Wobei sicher nicht BI in der Krise steckt, sondern vielmehr die Rolle von BI in der allgegenwärtigen Finanz- und Wirtschaftskrise diskutiert werden soll. Oder andesrum?

Am 9.7 findet dann der dritte SCRUMtisch in Hamburg statt. Auch hier wäre es meine erste Teilnahme.

Ob ich dann auch noch Zeit für das Trivadis BI&Networking Event (auch in … Hamburg) am 15.7. finde, wird sich zeigen.

Die Organisatoren der ersten beiden Veranstaltungen sind übrigens Opitz-Consultants, trotz der unterschiedlichen Themen – lustiger Zufall …?!

Scrum-Checkliste als Monitor

Die Einarbeitung in Agilität im Allgemeinen und SCRUM im Speziellen schreitet voran. Der erste Sprint hat begonnen, doch wie kann man feststellen, ob man auf dem richtigen Weg ist? Oder welchen Weg man bereits geschafft hat?

Natürlich: Bachgefühl! Ganz klar.

Aber schön wär’s doch, etwas greifbares zu haben/zu bekommen.

Bei Henrik Kniberg, dessen SCRUM und XP im harten Projektalltag ich mit Begeisterung gelesen habe, habe ich eine sehr umfangreiche SCRUM-Checkliste gefunden. Meine Idee ist, diese in ein Excel-Formular zu übertragen und nach/vor jedem Sprint zu dokumentieren, ob wir die Punkte beherzigt haben oder nicht. Auf diesem Wege läßt sich vielleicht eine Metrik erstellen, die die Qualität des SCRUM-Einsatzes misst. Und da in der Checkliste nicht nur Prozesseinhaltungsfragen enthalten sind, sondern auch Punkte, die eher auf den Bereich Werte und Prinzipien zielen, würde man sogar diesen sonst immer nur theoretisch beleuchteten Teil (zumindest teilweise) messen können…

Spannend!

Kalendereintrag: XP-Days 2009 und VMEA 2009

Ad 1: die XP-Days 2009 finden am 26.11. (Do, Tutorial), 27.11. (Fr, Konferenz) und 28.11. (Sa, Community Day) in Karlsruhe statt. Ich war im letzten Jahr in Hamburg auf der letzten Konferenz und schwer begeistert. Mal sehen, ob sichs einrichten lässt. (via: Bernd Schiffer)

Ad 2:  die VMEA 2009, die V-Modell Anwenderkonferenz des ANSSTAND e.V. findet am 17.11 (Di) in München statt. Schwerpunkt soll das V-Modell (XT!, nicht 97) im Spannungsfeld leichtgewichtiger und agiler Entwicklungsansätze sein. Auch hierauf bin ich gespannt, bewegt sich doch der alte, gute Tanker V-Modell so langsam in seichte, agile Gewässer…

Termine, Termine…

Linksammlung Agile Data-Warehouse – Entwicklung

Noch kein Antwort auf meine Frage zu Agiler Data-Warehouse – Entwicklung. Aber eigentlich weiß doch Google alles, oder.

Hier die relevanten Links der ersten zwei Seiten (englisch, Suchbegriff agil data-warehouse):

* Agile Data (es wird Warehouse-Papst Inmon mit seinem Buch Building the Data-Warehouse referenziert, der Artikel stammt wohl von Scott W. Ambler): Sammlung von Best Practices für Data-Warehouses und Business Intelligence

* Information Management (Lee Arnett): Sechs Architekturprinzipien, ausführlich erklärt

* Artikel aus dem BI-Jounal (Stephen Brobst, Michael McIntire, Edward Rado): Agile Data-Warehousing with integrated Sandboxing  die Autoren schlagen vor, eine „Sandbox“ im Produktivsystem (neben dem eigentlichen produktiven BI-System) einzurichten, in der die Weiterentwicklung durchgeführt wird und die die User bereits benutzen können (allein oder zusammen mit dem Produktivsystem)

* Buch „Agile Data Warehousing“ von Ralph Hughes: BI-Systeme mit Scrum und XP

* Artikel „Applying Agile Practices to Data Warehousing (Ken Collier, Jim Highsmith) vom Cutter Consortium – wobei ich im Artikel nicht ganz blicke, wo hier das DW/BI-spezifische sein soll

So, das wars. Und auf deutsch: eigentlich nix. Immerhin ist mein oben verlinkter Post mit (laut WordPress, Stand heute) 10 Aufrufen schon auf Platz 3!

Wahrscheinlich muss ich mal die (für mich) interessanten Fragen/Probleme herausdestillieren, die sich im Zusammenhang von Data-Warehousing und Agilität stellen.

Fortsetzung folgt…Hinweise erbeten!

Update: Eben den Blogeintrag von Daniel Fagerstrom gefunden: trifft nach kurzem überfliegen anscheinend am ehesten meine Fragen und Probleme. Mal intensiv lesen!

Agile Data-Warehouse-Entwicklung

Agile Softwareentwicklung?! Na klar, da war doch was…

Agiles Manifest, XP, SCRUM etc.pp. Und in allen Beispielprojekten werden fleißig Kundendaten in einer 08/15-Webanwendung erstellt, bearbeitet und wieder gelöscht, Unit-Tests in JUnit gemacht und automatisierte Builds in 10 Minuten durchgeführt.

Was aber tun, wenn man (ich) ein Data-Warehouse entwicklen musswill? Agil!

Kein Java (sondern meist ein herstellerbezogenes SQL)!
Kein JUnit!
Kein Maven oder SubVersion usw. !

Keine einschlägige Fachliteratur?
Keine Weblinks?
Keine spezialisierte Usergroup?
Keine Erfahrungen?

Wenn doch – auf die Plätze, fertig, Kommentar! Danke…

Fachbuch-Radar: Scrum und XP im harten Projektalltag – von Henrik Kniberg

Untertitel: So wird Scrum bei uns gemacht. Seit kurzem ist die deutsche Übersetzung erhältlich. Online und kostenlos (Kauf der englischen Version erwünscht).

Lese ich gerade. Das Inhaltsverzeichnis ist sehr ansprechend. Die Überschriften heißen z.B. „So sieht unser Product-Backlog aus“, „So bereiten wir die Sprint-Planung vor“ – die Unterkapitel heißen: “ Warum der Product Owner teilnehmen muss“, „Wenn das Meeting kein Ende findet…“. Klingt nicht nach Theoriegeschwafel, sondern nach rauem Alltag!

Finde ich eine klasse Idee! Mal sehen, ob der Inhalt hält, was die Struktur verspricht…

[via: XING - Scrum User Group Hamburg Forum "Erfahrungsberichte"]

Fachbuch-Radar: Scrum – von Roman Pichler

Eigentlich müsste es heißen: „Fachbuch-Radar: Scrum – Agiles Projektmanagement erfolgreich einsetzen – von Roman Pichler„, aber das war mir zu lang. 

Einziger Kritikpunkt: ich kam mit der Struktur des Buches, also der inhaltlichen Gliederung, nicht gut klar. Erschien mir irgendwie eher willkürlich als logisch. Mag aber eine Frage persönlicher Präferenz sein und schmälert den Nutzen des Buches eigentlich kaum. Gut, ich musste halt ab und zu hin- und herblättern, um mir bestimmte Zusammenhänge klar zu machen. Aber sowas soll ja auch die Verweildauer der aufgenommenen Informationen im Gehirn fördern Absicht?

Aber dennnoch: ein flott zu lesendes, informatives Buch. Alles ist gut verständlich. Kein episches Ausbreiten von Theorien, eigentlich überhaupt kein Theoriezeug, sondern klarer Fokus auf die Praxis. Wie wird’s gemacht, immer aus dem Blickwinkel des Autors („so bevorzuge ich es“). Absolut lohnens- und empfehlenswert.

Ich habe mir anhand des Buches jedenfalls ein Grundgerüst eines agilen Prozesses zusammengestellt (Rollen,  Artefakte, Prozess), den ich in Zukunft ausprobieren möchte. Mehr dazu in Kürze auf diesem Kanal…

Aber wo ich jetzt darüber schreibe (und nachdenke, in dieser Reihenfolge), fällt mir ein weiteres Defizit auf: die eher rudimentäre Erläuterung der Werte und Prinzipien agiler Softwareentwicklung. Aber das ist eine Eigenheit, die ja SCRUM im Allgemeinen wohl gerne zum Vorwurf gemacht wird. So ist es wohl kein Wunder, das man auch in diesem Buch hierzu nur eher die wohlbekannten Allgemeinplätzchen findet und keine tiefergehende Auseinandersetzung. Ist vielleicht auch ein Thema für ein eigenes Buch…

Green Programming vs. Die normative Macht des Faktischen

Nicolai Josuttis schreibt in seinem Heise-Blog über die Realität. Die Rahmenbedingungen erzwingen miesen Code, der dann fertig ist, wenn er läuft, nicht wenn er gut ist. Recht hat er.

Gunter Dueck träumt von Green Programming. Auch er konstatiert die schlechte Qualität von Software und vermutet horrende Kosten für Umwelt (und Firmenbilanzen), wenn dieser Code ob seiner schlechten Performance zu langsam und damit zu lange läuft.

Tja, wem ist zu glauben – dem Realisten oder dem Idealisten. Wobei nicht die Analyse strittig ist, sondern die daraus resultierenden Maßnahmen. Lernen wir mit dem Faktischen zu leben, normieren wir uns danach? Oder schaffen wir es, die Rahmenbedingungen zu ändern?

Mehr Personal statt weniger. Mehr Zeit statt weniger. Weniger Anforderungen statt mehr. Und erhalten wir dafür tatsächlich mehr Qualität?