Working with SCRUM is quite straight forward as long as you are inside the origanization that owns the project. But once you are an external supplier and sell the implementation of a certain piece of software to a customer, the game changes. As a supplier, the perfect scenario would be to be paid by the hour. In this case the customer can supply the product owner and freely define and prioritize requirements for each sprint. The project risk (including the risk of having chosen the wrong supplier) is then completely on the customer side. 

This is where the purchase department of large companies kicks in: They want to buy software like a car: "Tell me the features, give me a price, let us lower the price a bit, then you deliver on time, we check the deliverable. If everything is ok, we pay". Since 30 years, software develpment never worked this way, and since almost the same time, people think they just need to try harder next time.

This game is ok for the supplier as long as they put enough buffer into the budget and into the time plan and prevent scope creep during the project. The bid needs to be so high that in the best case the supplier gets something on top of his usual daily rates for taking the risk. In worst case, his margin will go down... In such a project environment you cannot let the customer define prioritization of the Tasks to implement because the project is then not about delivering the best possible solution anymore. It is about fulfilling the contract. The product owner (speaking Scrum again) needs to be inside the suppliers organization. The customer is only a stake holder. The potential of agile is very limited in such an environment.

A solution that appears more suitable for both sides is described in an article by Bernd Österreich (sorry, german) and at InfoQ as "Agile Fix Price". The idea is basically to make a normal offer with normal estimation (broken down to individual requirments), then you make a Special Contract that says:

- We implement all the required functionality (link to Requirments-Spec) for XYZ EUR (or US-$)

- We work with an Agile Method (for example: SCRUM), customer supplies the Product Owner

- In parallel to the agile develpment process, we deploy a bean counter who always checks the implemented functionality against the original requirments. Each deviation is written down in form of a Change Request

- Change Requests can be additional work or less work compared to the original offer. They are estimated in person hours

- Shortly after each planning session, the list of change requests is updated and (very important:) discussed with and approved by the customer

- Once a CR is approved, the customer can decide if the want to extend the budget (and timeline if needed) or if they want to leave out other functionality of comparable effort.

It seems like this method is a good compromise between supplier and customer stakes. The "dark side" of this approach is that the "bean counting" and discussing the detected changes with the customer take a lot of time. This is hard work that nobody wants to do. It is still extremely important to prevent scope creep while keeping as much flexibility as possible in the development process.

Our rules of thumb are that the "beancounter" job takes about 1-1.5 days per 2-weeks sprint. The discussion with the customer is about 45 minutes per sprint.

The beancounter needs that much time because she needs to be able to stand an argument with the customer over each detail in the CR. Otherwise, the customer will be very upset to be confronted with unreflected CRs that turn out to be part of the original requirements during discussion. The needed time depends a lot on the quality of the requirements and on the structure of the calculation documentation.

It is further very important that the customer understands and supports the reasons for this aproach and sees that:

- supplier cannot take the risk of working more if there is no chance of working less than expected

- customer wants to have benefit from agile, so they need to pay the price of additional communication effort with SCRUM

- customer wants to have fix price, so they need to pay for the additional "bean counting" overhead in the project

If this is clear, and if the atmosphere during the meetings is one of a bazaar more than of a cathedral (to quote an old open source  article) the agile fix price can be the least annoying of all options to do agile project work...

Wer weiß schon, was die Zukunft bringt? Das MIT natürlich! Und die veröffentlichen gerade die Top-10 Technologien der nächsten 5 Jahre. Zwischen so schönen alltagstauglichen Dingen wie cellulolytic enzymes und atomic magnetometers tauchen da auch offline Web applications auf. Ist das nicht kalter Kaffee? Oder wirklich ein Trend, der sich abzeichnet? Die Anstrengung, mit der Adobe sein AIR in den Markt drückt und auch einige Blog-Einträge der letzten Zeit scheinen die These des MIT zu unterstützen. Und PHP Anwendungen nebst Datenbank und Webserver in einem Selbstlaufenden EXE File (das man noch nichtmal installieren muß) sind durchaus heute schon möglich. Mal beobachten. Mein Favorite der MIT Top-10 ist übrigens: wireless power...

Seit ungefähr 120 Jahren weiß die Softwarebranche es, seit ungefähr 4 Jahren die PHP Branche und seit 3 Jahren ich und meine werten Kollegen: Testen ist wichtig. Und weil das so wichtig ist, möchte man es gern oft machen. Und wenn man keinen Azubi oder Prakti zur Verfügung hat, den man mit solchen Aufgaben beglücken kann, muss man das automatisieren. Dafür gibt es hervorragende Tools wie zum Beispiel PHPUnit, Cruise-Control und Selenium. Die haben wir inzwischen alle in einer Buildix Instanz installiert, konfiguriert und so eingerichtet, dass neben einigen Source-Code-Qualitäts-Prüfroutinen auch regelmäßig Unit-Tests und Selenium Tests durchlaufen. Letztere sogar automatisch auf allen Browsern und Betriebssystemen, die wir dem Kunden zugesichert haben. All das ist nun eingerichtet und unser ganzer Stolz. Allein es fehlt an Tests. Es ist eine durchaus ehrenvolle Entwickleraufgabe, solche zu schreiben. Aber leider auch eine, die keinen "Working Code" produziert, also kein konkret anstehendes Problem löst. Was in all den schönen Büchern von Cunningham, Beck und co. leider nicht drin steht ist nämlich, wie man effektiv dafür sorgt, dass die Entwickler sich dafür Zeit nehmen, sinnvolle Tests zu schreiben. Nachdem auch der Hartmann'sche GEADN - Ansatz wegen Patentschutz nicht zum Einsatz kommen kann, hat ein Kollege von mir nun eine Anleihe bei einem bekannten Motivationstrainer und Team-Coach ausgeliehen. Letzterer setzt sich in seinem Blog-Eintrag "Motivation" sehr berufen mit diesem Thema auseinander und empfiehlt das Tapezieren von Wänden mit motivierenden Plakaten (siehe links). Das rollen wir heute mal flächendeckend aus und hoffen auf Besserung...

Unser geschätzer Bulgare Slavey hat heute seine Diplomarbeit über unser Projektmanagement- und Resourcenplanungssystem vorgestellt. Nachdem sein Professor unseren Ansätzen anfänglich ein wenig skeptisch gegenüberstand (O-Ton: "Ich habe das am Anfang für Unfug gehalten"), konnte er sich im Verlauf der Diplomarbeit dann doch für unsere Methodik erwärmen. Jetzt ist es wissenschaftlich überprüft: So wie wir arbeitet sonst keiner. Das ist erstmal noch kein Qualitätsmerkmal. Es gibt auch keine Methodik, die diese Vorgehensweise propagiert. Auch das nicht unbedingt ein Qualitätsmerkmal. Aber wir machen seit Einführung dieser Methodik so gut wie keine Überstunden und kriegen unsere Projete trotzdem hin. Und wir haben unseren Diplomanden sowie seinen Prof. von der theoretischen Qualität unseres Ansatzes überzeugt. Scheint doch was dran zu sein. Auf jeden Fall werden wir auch weiterhin Aufgaben zum Spätest-möglichen Zeitpunkt planen und kleine Stundenjobs mit 900 Manntage-Projekten in einer Resourcenplanung mischen...

Lange Zeit habe ich ja ehrlich gesagt Javascript wo möglich vermieden. Aber inzwischen hat sich die Welt weiter gedreht und ich muss mich wegen diverser Web 2.0 Projekte jetzt doch mal ernsthaft mit dem Thema beschäftigen. Da fiel mir vor einiger Zeit ein Buch in die Hände: Advanced Ajax. Nachdem es nun auch in meinem neuen Lieblingsblog "Ajaxian" gefeatured wurde, bin ich jetzt dabei, es tatsächlich mal zu lesen. Interessant, das Javascript inzwischen eine ernsthafte Programmierplattform geworden ist. Vorbei die Zeit, als man probiert hat, bis es zufällig funktionierte. Inzwischen gibt es Unit-Tests, Contineous Integration Server, Design Patterns, Libraries, alles was der ambitionierte Informatiker braucht. Sehr reizvoll, sich mit dieser (für mich aus Informatiksicht neuen) Platform zu beschäftigen. Wobei ich mich noch nicht entschieden habe, was mir besser gefällt: Javascript oder ActionScript. Jedenfalls bin ich gerade ziemlich begeistert von JQuery und meine Kollegen arbeiten an der Umsetzung eines openAjax Hubs sowie einer Komponentenarchitektur, die Client Side Code, Server Side Code (in PHP) und HTML miteinander verknüpft. Spannende neue Welt. Da braucht bald keiner mehr was programmieren...

(deutsch) Wer hätte das gedacht, Klimaanlagen können also durch Kondenswasser echte Schäden am Mauerwerk anrichten? Insbesondere spannend, wenn man durch Abtasten der verdächtigen Komponenten maximal eine geringe Feuchtigkeit feststellt. Aber die Hausverwaltung bestand auf einer genauen Untersuchung unserer Klimaanlage. Und das obwohl nebenan Uralt-Rohre verlaufen, von der Zeit vor dem Krieg (ja, unser Office ist in einem Altbau). Irgendwie erinnert mich das an die guten alten Helpdesk-Zeiten, in denen der erste Verdacht bei Fehlfunktionen des Computers immer war: Unzureichende Erdung des Benutzers. Generationen von Datentypistinnen mußten sich mit Erdungskabeln an der Heizung festmachen und teure Büroteppiche mit der Aufschrift "antistatisch" wurden angeschafft. Nicht dass diese zweifellos Ästhetik-Schädigenden Maßnahmen irgendwas an der Stabiliät der Rechner geändert hätten. Aber wenn mans dann schonmal hat... Aber zurück zum Wasser-Problem: Nach meiner Erfahrung müssen schon viele Liter Wasser regelmäßig in so eine Außenwand fließen, damit die nachhaltig nass wird (vor allem im Stockwerk dunter). Inzwischen ist unsere Klimaanlage außer Verdacht und in unserer Besprechungsraumwand prangt ein 50x50 cm Loch, hinter dem Uralt-Rohre und Rost zu sehen sind. Man darf gespannt sein, was noch so zur Ermittlung der (offensichtlichen) Ursache getan werden muss. Vielleicht bekommen wir die Auflage Luftentfeuchter zu installieren, weil vielleicht die Raumluft zu viel kondensierende Flüssigkeit enthält? In jedem Fall bin ich immer wieder dankbar für Lektionen in Problemkomplexifizierung und den angrenzenden Wissenschaften wie Nutzerbeschuldigung oder die klassiche Mulderisierung (nach Agent Mulder aus Akte-X) von an sich einfachen Sachverhalten...

Today i was granted some insight in another kind of community. Not your every day open source conference or java show. This time it was the System-i community event (called iSociety World). It was very interesting to see so many suits and ties at a conference. No geeks coding in the lobby. No funny T-Shirts. Instead, you find people who really have made money already with their IT business and who have been running this for years now. What a great new playground for a geek like me. I had done some work with the System-i a few weeks ago and wrote a paper about PHP on System-i. This has triggered quite some feedback from IBM. Maybe not the best entry into a new community but at least i had something for a smalltalk at the conference ...