Warum agil?

Agil ist populär, viele Grosse Unternehmen gehen agil vor: Google, Microsoft, Symantec und viele mehr. Sie alle haben agile Prinzipien adaptiert, teilweise sogar eine eigene agili-irgendwas Methode entwickelt. Erwartungsgemäss schiessen derzeit auch agile Zerifizierungsfirmen aus dem Boden, die auf der agilen Welle mitschwimmen und gegen Entgelt "Certified Agile Consultant" Titel vergeben - die Zertifizierungspraktiken sind oft zweifelhalf. Vielerorts genügt die Teilnahme eines Kurses zur Erlangung des Titels, von Zertifizierung keine Spur. Überbewerten Sie das nicht!

Professor Frederick P. Brooks, Jr., University of North Carolina USA, behauptete 1986, dass sich binnen 10 Jahren keine einzige Technologie oder Management-Methode die Produktivität, Nachhaltigkeit oder Einfachheit um den Faktor 10 erhöhen würde. In seinem Buch aus dem Jahr 1995:

"The Mythical Man-Month: Essays on Software Engineering, 20th Anniversary Edition" MA: Addison-Wesley

kommt er zum Ergebnis, dass es keinen Königsweg gibt.

Agil ist auch kein Köngisweg! Grundsätzlich sollte man agil nicht anwenden, wenn man ausschliesslich die Produktivität erhöhen möchte!

Die Vorteile von agil rühren daher, dass man anders arbeitet, und nicht schneller! Agil Arbeiten ist ein Lernzprozess für jedes Team, und dass kann 2 bis 3 Iteration dauern. Während dessen wird man langsamer sein, nicht schneller! Das Team muss agil praktizieren und lernen, ähnlich einem kleinem Kind, dem man Basketball spielen beibringt. Zunächst wird jedes Kind den Ball in die Hand nehmen, ihn für sich beanspruchen und ihn nicht mit den anderen Teilen. Es dauert seine Zeit, bis man den Kindern vermitteln kann, dass es ein Teamspiel ist und man den Ball abgeben muss.

Agil mag momentan gerade "cool" und "in" sein, aber das ist kein Grund, agil vorzugehen. Wenn man agil vorgehen möchte, dann gibt es nur eine Frage:

Wird uns agiles Vorgehen dabei helfen, erfolgreicher zu sein?

Wenn man diese Frage beantworten kann, weiss man ob agil richtig für einen ist.

In den kommenden Posts werde ich ein paar Punkte aufzeigen, die bei der Beantwortung der Frage helfen können:

• Wann ist man "erfolgreich" - wenn Deadlines erfüllt werden?
• Welche Arten von Erfolge gibt es? Welche sind für agil wichtig?
• Wie sieht eine Organisation aus, die agiles Vorgehen nachhaltig unterstützt?
  

SpringOne 2008, Antwerpen

Auch dieses Jahr ist die namics bei der SpringOne in Antwerpen, Belgien vertreten. Die SpringOne ist einen Entwickler Konferenz, bei der sich Spring Entwickler und Spring Anwender treffen, um neue Features und Ideen von Spring Core, Spring Enterprise oder Spring in Production zu diskutieren.

Wer live dabei sein möchte: RSS- Feed, Flickr

SpringOne2008

Guidewire Case Study beim Scrumbreakfast #7

Professor Stuart Read vom IMD Lausanne hat am Scrumbreakfast #7 eine Case Study von Guidewire vorgestellt. Anders als erwartet hielt Stuart keine herkömmliche Präsentation, sondern gestaltet den Scrumbreakfast als Diskussion bzw. Workshop.

Guidewire ist ein Unternehmen, was mit Scrum aufgebaut wurde, von der ersten Stunde an. Nicht nur, dass es Sprint Team gibt, um Software zu entwickeln, nein - Guidewire ist eine komplett agil aufgebaute Organisationsstruktur. Die Firma reorganisiert sich jeden Monat. Teams wurden neu zusammengestellt, Funktionen und Rollen neu verteilt und interessanter weise zogen sogar die Teams mit ihrem gesamten Desktop um.

Beim Scrumbreakfast #7 traff Stuart auf eine Gruppe von Scrum Anwendern (und solche, die im Begriff sind, Scrum einzusetzen) und wollte von den praktischen Erfahrungen lernen.

Stuart begann den Workshop mit der Frage, welche Personen für agile Teams eingestellt werden sollten: keine Indiviualisten, Teamplayer, Early Adaptors und Output-orientierte Personen. Darüber hinaus wurde darauf eingegangen, wie man den Recruiting Prozess gestalten könne: das Team entscheidet. Der gesamte Entscheidungs- und Organisationsprozess bei Guidewire kommt von der Basis - Bottom-up.

Dann stellte Stuart die Frage, ob man als Kunde eine Software von einem Unternehmen kaufen würde, wenn sich dessen Organisation ständig ändert. Hat man da Verrtauen? Vertrauen, das ist wohl das Kernelelement. Regelmässig liefern, was man versprochen hat - der Schlüssel zum Erfolg.

Guidewire hat in der Zwischenzeit mehr als 350 Mitarbeiter und soll an der Börse notiert werden. Erstmalig in der Erfolgsgeschichte des Unternehmens gab es nun ein Problem - fehlende Hierachie. Es gab keinen CTO, keinen CEO, keinen CFO etc. Wie führt man ein Unternehmen an die Börse, wenn es keine definierten Strukturen hat?

"Wer ist der CTO von Guidwire?"

"Ja, welchen meinen Sie, den von diesem Monat oder den vom vorherigen?"

Stuart fragte uns Teilnehmer, wie wir das Unternehmen beraten würden? Ein paar Minuten später lieferte er die Anworten:

• Die Entwickler-Teams werden in Pods von 3 bis 6 Personen organisiert.
• Jeder Pod hat einen Pod Leader, quasi einen Team Captain.
• Wird ein Team zu gross, gibt es einen Split.
  
• Jedes Team arbeitet an einem spezifischen Teil des Produkts.
• Jeder im Team ist in der Lage, an allen spezifischen Elementen des Teil-Produkts zu arbeiten.
• Die physische Umgebung wurde an dem Team angepasst, um die Kommunikation zu erhöhen - alle sitzen beieinander.
  
• Reviews von Pods werden vom Head des Produktteils durchgeführt, nicht vom Pod Leader.
• Pod Leader werden nach Kompetenz ausgewählt - er kann jeden Job, den ein anderes Teammitglied erledigen kann, auch selbst erledigen.

Guidewire, ein agil organisiertes Unternehmen, dass erfolgreich ist. Die Menschen, die dort arbeiten, würden wohl nie in einem stark hierarchisch organisierten Unternehmen arbeiten und umgekehrt auch nicht. Stuart erzählte, dass man einen CTO von der IBM bei Guidewire eingestellt habe, der das Unternehmen nach kurzer Zeit wieder verliess ...

Mein Resümee

Das Scrumbreakfest #7, organisiert von Peter, war ein interessanter Anlass, insbesondere, weil ich viele organisatorische Prinzipien und Ansätze die diskutiert wurden, bei meinem akutellen Arbeitgeber namics wiederfand. Und dabei ist mir eines klar: nach namics würde es definitiv schwer ein vergleichbares Arbeitsumfeld zu finden ...

barcampbodensee

Auf dem barcampbodensee gab es in den letzten zweit Tagen interessante Sessions, die sich mit diversen Methoden zum Entwicklen von Software beschäftigt haben.

Unter anderem wurde vorgestellt, wie man Game Software mit eXtreme Programming(XP) entwickelt. Dabei konnte man sehen, welche Elemente von XP zur Anwendung kommen, z.B. Pair Programming, User Stories und Continuous Integration.

In einer weiteren Session konnte man sich einen Überblick verschaffen, wie man mit Ruby on Rails eine Webapplikation baut und diese testet. Neben den Routinen, die Ruby on Rails bereits zum Testen mitbringt, wurde der Einsatz von Selenium zum GUI Testing gezeigt - alle automatisiert und integriert.


Mein erstes Barcamp, mein Eindruck: lohnt sich, macht Spass und man lernt viele interessante Leute und deren (teilweise verückte) Ideen kennen.

Was möchte ich tun?

Bisher habe ich das Thema Ruby on Rails mit geringer Wertschätzung immer unter "sollte ich mal irgendwann angehen" gelegt ...

Ok, jetzt ist es soweit. Ich habe mir von einem erfahrenen Ruby on Rails Kollegen Christian Felder ein Buch ausgeliehen: Agile Webdevelopment with Rails.

Get Excited

Nach nunmehr 6 Kapiteln Studium weiss ich eines - das ist DIE Technology um einerseits schnell eine Webapplikation zu realsieren und anderseits dies agil zu tun!

Das Buch selbst ist so aufgebaut, dass man entlang einer Kunden Beziehung einen Shop implementiert. Man trifft den Kunden regemässig und arbeitet die verschiedenen Aufgaben in Interationen ab - gefällt mir sehr gut, und es ist so einfach. Ich entwickle schon seit ein paar Jahren Webapplikation im Java und .NET Umfeld und wenn ich nun nach nur 6 Kapiteln in diesem Buch mal einen Strich machen darf: Es ist so einfach! In der Java und .NET Welt muss man derart viele Handstände machen, um vergleichsweise triviale Dinge zu lösen - in Ruby ist das oft nen Einzeiler!

Der Ruby Erfinder hat mal gesagt: "I wanna be a YES-guy!" - Mit Ruby on Rails hat er mindestens das wohl erreicht!

Next:

Get Started

Story Points, Real Days und Tasks - Wie schätzt man Aufwand nach SCRUM

Eine interessante Frage, die ich kürzlich gestellt bekommen habe:

"Wird die Aufwandschätzung für eine User Story ganz normal in Stunden geschätzt und mit dem Faktor 1,33 Faktor für "real days" multipliziert oder ist der Faktor je nach Team unterschiedlich?"

In den agilen Teams, in den ich bisher gearbeitet habe, gingen wir von Story Points aus. Warum? Story Points (SP) beziffern die "Groesse" (Size). Sie haben keinen zeitlichen Aspekt. Wenn man User Stories mit SP's schätzt, kann man sie nebeneinander stellen und vergleichen:

Story A ist doppelt so "viel" wie Story "B". Story "C" ist 5 man so "viel" wie Story A.

Das ist sehr abstrakt und das ist gut so! Wichtig ist auf jeden Fall, dass die Story Points Scale endlich ist: z.B. 1-5, oder 10-100, etc. Sie sollte eine Progression ausdrücken, also nicht linear sein.

Reals Days ist eine andere Möglichkeit, User Stories zu schätzen.

Während des Sprint Planning Meeting 2, wenn das Team die Arbeit aufteilt, analsyisert und annimmt, werden die User Story in Tasks runtergebrochen und mit h versehen. Wenn man dann alle Stunden aller Team Members aufsummiert bekommt man eine geschätzten Aufwand für den kommenden Sprint. Legt man neben dran die Summe der verfügbaren Arbzeisstunden, kann man ungefähr erkennen, was dring liegt und was nicht.

• Beispiel: Sprint à 2 Wochen (10 Arbeitstage), Teamsize 3:
• Total verfügbare Arbeitszeit: 252 h (8.4h/Tag x 10 Tage x 3)
• Real Days: 180 h (6h/Tag x 10 x 3)
• Summe der Aufwandschätzung von n Task vom Team im Sprint Planning Meeting 2: 200h

In diesem Beispiel sind 20h zu viel im Sprint Backlog - es sollte etwas entfernt und ein Puffer eingeplant werden. Erfahrungsgemäss hat das Team beim Herunterbrechen der Task Dinge vergessen, die dann bei der täglichen Arbeit auffallen.

Jedes Teammitglied fügt solche Tasks während des Springs mit verbleibender Zeit (remaining time) in h ein. Der Scrum Master legt beim Daily Scrum jeweils das Sprint Burndown Chart auf und bespricht die Situation mit dem Team. Hier wird erkenntlich, ob die remaining time mit den noch verfügbaren Stunden übereinstimmt.

Das Sprint Burndown Chart ist vielleicht mal einen extra Post gut, mal sehen ...

Was meint man mit Persona?

Im Anschluss an meinen Vortrag zum Thema "Wie funktioniert agile Softwareentwicklung mit Scrum" vom 28. Mai 08 wurde ich darauf angesprochen, dass ich mich bei der Mehrzahl von Person in meiner Präsentation verschrieben habe - Personas - ein Missverständnis.

Gemeint war nicht Personen im Sinne der Mehrzahl von Person, sondern Personas im Sinne der Mehrzahl von Persona.

"Eine Persona ist ein häufig eingesetztes Modell aus dem Bereich der Mensch-Computer-Interaktion"
(Wikipedia)

Wie funktioniert agile Software Entwicklung mit SCRUM?

Zum Thema "Wie funktioniert agile Software-Entwicklung" werde ich am 28. Mai bei der Internet-Briefing Entwickler Konferenz einen Vortrag halten.

Neben ein bischen Theorie rund um Scrum werde ich der Frage nachgehen, wie eine agiles Team aussieht, wie man einen Sprint abwickelt und welche Tools man dazu einsetzt. Der Vortrag ist für Projektleiter, Produkt Manager, Entscheidungsträger und Entwickler ausgelegt - es ist also für jeden Betrachtungswinkel etwas dabei.

Den Vortrag "Wie funktioniert agile Software-Entwicklung mit SCRUM" kann man hier runterladen.

Orbit-iEX Zürich

Mein Arbeitgeber, die namics ist auch dieses Jahr an der Orbit-iEX Zürich mit einem Stand vertreten. Es gibt Referate zu den Top 11 Internet-Themen und einen eindrucksvollen Stand, wie ich finde! 100% namics, das ist auf jedenfalls einen Besuch wert.

Marcello Leonardi, ein Arbeitskollege mit dem ich unser erstes agiles Projekt bei der namics bestritten habe, wird bei der Orbit-iEX Zürich ein Referat über Software-Innovationsprojekte halten:

"Können Software-Innovationsprojekte gefördert, geplant und geführt werden?", Mittwoch, 21. Mai 2008, 09:15 – 10:45 Uhr, Anmeldung

Marcello und ich werden auf der Orbit-iEX Zürich am namics Stand anwesend sein. Sie können uns direkt ansprechen oder Termine am Stand in der namics Lounge vereinbaren mit uns vereinbaren.

Wir freuen uns auf viele Kontakte und interessante Gespräche.

Treffen Sie uns...

100% namics
Orbit-iEX Zürich
20.-23. Mai 08
Messe Zürich, mit der Tram 11 oder 4 vom Hauptbahnhof

Scrum Breakfast in Zürich, Guideware Case Study

This month we are honored to have a special guest to the Scrum Breakfast in Zürich: Stuart Read, Professor of Marketing at the IMD in Lausanne.

You already know Scrum. You have likely seen it at work. In this discussion, we will investigate a firm built completely on Scum. Not only does the firm use Sprint teams for every function in the company, the firm has used Scrum since its founding day. I encourage you to review the case study so we can have a focused discussion on the issues around such a complete adoption of the methodology, especially as the firm expands beyond 500 employees.

Stuart Read is Professor of Marketing at IMD. He is currently developing cases and research in the following areas:

• New ventures and innovation
• Specifically investigating expertise in the entrepreneurial domain
• Marketing of innovations with network externalities
• Non-predictive strategies that enable managers to effectively make decisions in situations of true uncertainty

His academic credentials include a Ph.D. in marketing from the University of Washington and a Bachelor's degree in computer science from Harvard University. He has nearly 20 years of industry experience, having participated in the creation of six high technology start-up firms. Four of those firms were acquired by industry leaders including Sun Microsystems and Lotus Development Corporation. Two are publicly traded. Stuart also spent 6 years with enterprise database software provider, Oracle Corporation.

The Scrum Breakfast in Zürich is a monthly exchange of information around Scrum. The breakfast offers discussion, information and hands-on experience to CIO's, executive and operational project managers. The Scrum Breakfast takes place the first Wednesday of each month. The program starts with a short presentation about on an in interesting topic around Scrum. Then follows a moderated discussion among the participants to encourage an exchange of know-how and experiences.

The talk will be held in English.

Attendance is free and our sponsor namics provides the coffee, gipfeli (croissants) and orange juice.

Date: June 4, 2008
Time: 10:00 to 12:30 (Special Case!)
Location: namics ag, konradstrasse 12, 8005 zürich

Registration for the Scrum Breakfast via xing or via comment (won't be published). If you wish to join us for lunch, please register separately at xing.

amazee ist seit 05. Mai 08 online

Amazee verabschiedet sich mit dem heutigen Tag offiziell aus der private Beta Phase und ist nun für alle und jeden offen.

Ladies & Gentlemen, register and start your engines projects!

Für alle, die sich noch nicht mit Amazee auseinander gesetzt haben:
Amazee ist eine Plattform die es ermöglicht, weltweit Gleichgesinnte zu erreichen und Projekte zu initiieren. Welche Ziele man auch immer anstrebt, Amazee bietet die Möglichkeit, sie bekannt zu machen und gemeinsam umzusetzen. Egal ob kleine oder grosse Lebensziele.

Der Schwerpunkt liegt auf gesellschaftlicher Zusammenarbeit zwischen Privatpersonen und nicht unbedingt auf geschäftlicher Team- und Projekt-Collaboration. Bei Amazee kann man mit anderen zusammenarbeiten, mit dem Fokus auf Ziele und Projekte.

Mehr gibt es bei Amazee's Learn more...

Zeitgleich mit dem Beta-Launch lanciert Amazee einen Wettbewerb, bei dem es in den nächsten Monaten darum geht, mit seinem Projekt Aufmerksamkeit, Unterstützung und eine möglichst grosse Gefolgschaft aufzubauen.

Der Amazee-Contest findet in drei Phasen statt. Zunächst zählt das User-Rating der teilnehmenden Projekte. In Phase zwei geht es dann darum, möglichst viele Mitglieder für das eigene Projekt zu gewinnen. Schlussendlich entscheidet eine Jury, wie der Gesamtpreis unter den Top 3 Projekten aufgeteilt wird.

Die drei Sieger-Projekte werden durch Amazee mit insgesamt € 10'000 unterstützt.

You broke the build

Auf meinem Blog schreibe ich meist über methodische Punkte rund um Scrum und/oder XP. Dabei beziehe ich mich immer auf Erfahrungen, die ich in Verbindung zu diesen Themen mache. Kürzlich hatte ich ein Erfahrung, die sich so gestaltete:

Das Set
Mehrere Entwickler arbeiten an verschiedenen Standorten an einem Software-Entwicklungsprojekt. Es gibt Entwickler, die sich ausschliesslich bei der Implementierung innerhalb eines Layers befinden, z.B. Backend, Business Services oder Web Container. Oft haben die Entwickler layerübergreifend nicht die Einsicht, von wem, wo und zu welchem Zeitpunkt Methoden aufgerufen werden.

Das Problem
Veränderung! Service Interfaces stellen einen Contract dar. Ein Änderung des Contract muss also allen Beteiligten mitgeteilt werden. So gedacht und durchgeführt von einem Entwickler, der an einem Standort die Runde per Zuruf informiert, dass er ein Interface ändern werde. Die Entwickler an anderen Standorten bekommen diese Information nicht. Der besagte Entwickler ändert das Interface und checkt den Code ins Repository ein. Alle Entwickler haben beim nächsten sync mit dem Repository nicht kompilierbaren Code. Der automatisierte Build failed in der Folge und alle Entwickler werden per Email benachrichtigt.

Was ist passiert?
Ein Entwickler hat für geschlagene 3 1/2h das gesamte Entwicklerteam mit seinem Checkin lahm gelegt.

Wie umgeht man das?
Zunächst mal sei gesagt, dass genau dieses Problem oft vorkommt und das Konzept von continuous integration aus den Angeln hebt. Hiermit soll sichgerstellt werden, das alle Veränderungen an der Codebasis, die in das Repository eingecheckt werden, die Lauf- und Funktionstüchtigkeit der Software nicht stören.

Am Beispiel eines bliebigen Interfaces möchte ich zeigen, wie man das Problem umgehen kann.

Die Methode
...
public void doSomething(String a, String b);
...

soll einen neuen Parameter bekommen:

...
public void doSomething(String a, String b, String c);
...

Wenn man das alte Interface verändert, werden alle Zugriffe auf diese Methode nicht kompilierbar sein. Man kann das wie folgt umgehen:

...
/** @deprecated */
public void doSomething(String a, String b);

public void doSomething(String a, String b, String c);
...

Die Implementierungen kann dann so aussehen:

...
/** @deprecated */
public void doSomething(String a, String b) {
// FIXME call doSomething(a,b,c) instead
doSomething(a,b, "fixed (dummy) c value");
}

public void doSomething(String a, String b, String c) {
// do stuff here
}
...


Per FIXME Kommentar kann man allen Entwicklern im Code erkenntlich machen, wie sie die neue Signatur aufrufen sollen. Wenn man das eincheckt wird nach wie vor Kompilierfähigkeit garantiert.

Natürlich muss sichgestellt werden, dass die deprecated Methode irgendwann entfernt wird. Hierfür gibt es Tools, die man im Rahmen der continuous integration laufen lassen kann. Sie raportieren TODO und FIXME Tags im Code