“Planning is the death of any project” http://bit.ly/bFYkAW Just an entertainment story, but fun nonetheless

I’m certainly proud to produce something that is considered fun. Yet my little story actually has some serious background. Of course the simple task of making coffee doesn’t justify elaborate project planning. But which task does? As we have seen, simple tasks don’t.

So how about complex tasks? Tasks that depend on circumstances in many ways, like e.g. balancing a stick on a finger, or playing table tennis. It would surely simplify the task, if we knew exactly when to make which movement. But we can’t plan this kind of thing, because the tiniest deviation from the intendend movement at some point in time will greatly change the required action some time later.

The coach teaching me project management had a great example of a project needing very accurate planning: When you build a nuclear reactor, the core will get encapsulated in a huge steel chamber. There are only very few cranes huge enough to move this thing. And they need a rail track to get to the building site, as well as a foundation for the crane to stand on. Rent of this crane is expensive as hell and you have to fix the dates years in advance. Everything that was needed for this crane and the needed structure, was planned with great care, to make sure everything was in place.

Few of us build nuclear reactors. For all others check these rules as a guide for the amount of planning justified:

• How plannable is it anyway? Don’t try to plan the unplannable. Get it out of the way instead. This is what many agile approaches do, when they implement the most risky stuff first.
• Do you have fixed dependencies between tasks? A plan becomes more helpfull, when you have many dependencies between tasks, possible with long ramp up or preperation time. As with the crane: The task of moving the steel shell wasn’t  very long, but the preperation had to start years ahead. Without a plan it gets easy to kill a deadline long before it comes into sight.
• What is the damage done, when you don’t stick to the plan. In some projects, the only damage done is that somebody has to adjust all the plans. In that case, you might just as well scrap the plan.

A cup of coffee

Are you able to make a pot of coffee? I guess you are. At least until you try to plan it. Here is the first version of a plan to make coffee:

• put a filter in the coffee machine
• put coffee in the filter
• put water in the coffee machine
• switch the coffee machine on
• wait until done

But wait, there are tons of things that could go wrong with that plan. So let’s make the plan a little more complete:

1. ask everybody in shouting distance if he or she want some coffee
2. find out if there is a filter available for the coffee machine, if not go buy some. If this takes longer then 5 minutes, restart at 1.
3. put the filter in the coffee machine.
4. calculate the amount coffee needed for the number of persons determined in the last occurrence of step 1
5. find out if there is enough ground coffee available. If not check if enough coffee beans are available and a mill to grind them. If not ask a neighbor if she has enough resources. If not buy some. If this takes longer then 5 minutes, restart at 1.
6. if you have coffee beans grind them.
7. put the ground coffee in the filter.
8. calculate the correct amount of water for the number of people
9. put that amount of water in the machine
10. make sure the coffee machines power plug is plugged in
11. switch the coffee machine on
12. find the manual for the coffee machine and find out how to determine that the coffee machine is actually done. If you can’t find the manual, download it from the Internet. If you can’t find it, buy a new coffee machine and restart at 1.
13. wait for the described symptoms to appear
14. proceed with the instructions from the manual

Now that is awfully complicated. I’d guess there is a lot of stuff that could go wrong, so we need a Quality Assurance Process. So every step should get done by two independent persons, both well trained in coffee making. The result of each step should get reviewed by a third person. Coffee making is only allowed to proceed when the results of the process of both cooks is within the allowed tolerance of the target values. Target values and acceptable tolerances are to be defined during the project inception phase by a committee of experts.

That looks very promising, but since there are so many people involved there is some risk of problems, so we better setup a project management office for monitoring progress. And while we are at it we get some lawyer involved to proof read contracts made with neighbors or shops selling coffee and filter. Also a chemist might be useful for testing water, coffee, filter and air for pollutions and harmful substances.

In the mean time I’ll grab a cup of tea. Let me see what I’ll need …

Hourglass

One of the most difficult tasks in a software development project is estimating the size of the project. Unfortunatly very often  you have to do it at the very beginning of a project, when you have the least information. The result at the end is very often a large difference between the original estimate and the actual time and money needed.

If the difference is positive as often as it is negative this is kind of OK. But in some teams estimates are too low almost all the time! The obvious strategy often employed is to add a certain percentage to the estimate. But of course that is just fixing the symptoms, because most of the  time nobody knows the reason. So in this article I am going to show a couple of possible reasons for bad estimates, how to identify these and also a possible fix.

These are the kinds of reasons I identified so far:

Super Hero Estimates: Often estimates are done by a very experienced developer (Super Hero). When they estimate a task they imagine themselves doing it. But while the esimate might be correct for the Super Hero in the project more average developers work on the task. And since they aren’t Super Heros they need longer.

You can identify this kind of situation by letting different people do the estimates. Including average developers. If the estimate of the Super Hero is constantly below that of the others, the fix becomes obvious: Use the estimate of the other developers. Don’t exclude the Super Hero from estimating though. Experienced developers a good at identifying things others tend to forget.

Wrong Team: This one is similar to the Super Hero Estimate, in that the estimate is correct for a team of good (possibly excellent) developers. It differs though, because in this scenario, this is the actual team that should do the project. But for one reason or the other the project gets staffed with a different team. Maybe developers that aren’t that good. Or maybe just a team that doesn’t no the domain, the framework or the programming language that well.

In order to identify this situation, talk to the people doing the estimates. Let them specifiy the assumption they had in mind when they made the estimate, and compare it to what actually happend in the project.

If this is actually the problem you have two choices: The first is: stop switching teams. This doesn’t work most of the time, since you don’t switch them just for fun, right? So you are stuck with the second option: Even when you plan to use your top team, make the estimates on the assumption that an average team will do the job. Be honest to yourself about what an average team is.

Guessing in the dark: Often the information available about the project at hand is just not sufficient for a reliable estimate. There is only a vague description available.

In order to identify this as the underlying problem, break the project down into tasks, which you estimate. For each task put down the assumptions you are making: what technology are you using, how complex is the logic to implement. During the project check if your assumptions hold or if there are a lot of changes. This is also most of the solution to the problem. Make the description of your assumption part of your estimate. If the assumptions are wrong, the customer may correct those, resulting in a new more reliable estimate. I he changes his mind later on, you have a clean basis for a change management process, which ensures, that changes are possible, but that the one requesting the change is also paying for it.

Forgetting stuff: This one looks very similiar to the previous. Stuff doesn’t get included in the estimate. But this time it’s not because the people doing the estimate don’t know about it, but because they forget about it.

Using the same strategy as for Guessing in the dark should make this kind of mistake obvious. As a remidy, let multiple people do estimates, and compare the results. You should do this based on the broken down tasks, so missing tasks in the different estimates become obvious.

Ball of Mud Projects: When projects base on a specific code base take too long each and every time, a reason might be that tasks keep getting more complex then anticipated. A typical reason for that would be an overly complex and convoluted code base, where nobody really can predict the effects a given code change may have.

In such a project I’d expect a lot 80% syndrome, few test and many swearing developers. Do a code analysis of the code base, with a concentration on architecture and dependency management. If you find a lot of crap, there is just one solution: Clean it up and pay your technical debt. I.e. invest time and money to improve the architecture. I also recommend implementing tests, that prevent the architecture from starting to rot again.

Multitasking: People are bad at multi tasking. So you can’t put your top developer for 20% in five different projects and expect her to work just as efficient as normal. Once you start thinking about it, it should be really obvious if you have the problem or not. And the same should be true for the solution.

Mythical Man Month: Conceptional very similar is the Mythical Man Month effect. Check if your estimates get processed like this: “Frank says he would need 6 months. We need to get done within 1 month, so let’s put 6 developers in the project.” If this is the case you are missing on all the overhead that a bigger team causes. In order to get a handle on that kind of problem read the book Mythical Man Month. I do think that book is overrated, but the chapter about the actual mythical man month is right to the point.

This problem is almost guaranteed to hit you when you do a project that is a magnitude larger then your normal project. You will underestimate by a large amount, if you do not factor in the exponential behaviour of communication over head.

Lazy Developer: Of course there is always the possibility that the developers just aren’t working hard enough. In my experience, most of the time, this isn’t a problem. But I guess is it does happen. Symptoms could be lots of open browser tabs, on sites that have no relation to the work at hand, acompanied by hectic wiondow/tab switching, when the boss drops by. If this is a problem with one developer, it might be that the developer has the power to change it. But if many developers spend their time procrastinating it is most probably a management problem. Procrastination is not fun. Getting stuff done is. So if everybody is procrastinating something in the environment is probably highly demotivating. Find out what it is and get it out of the way.

Andererseits hat die klassische Netzplantechink durchaus etwas für sich. Der Argumentation: Wenn A von B abhängt, kann ich erst mit A beginnen, wenn B abgeschlossen ist, leuchtet ein. Und so mancher Vertreter der Agilen Methoden verwechselt wohl agil mit chaotisch.

Leute die Worte wie Agil, Iterativ und Inkrementell nutzen, aber nicht erklären können machen die Sache auch nicht besser.

Ich habe jemanden gefunden, der nicht nur diese Unterscheidungen kennt, der weiß wie man in agil geführten Projekten plant und schätzt, sondern der darüber sogar Bücher geschrieben hat. Mike Cohen. Na gut, ich habe ihn nicht persönlich kennengelernt, aber ich habe zwei seiner Bücher gelesen: “Agile Estimating and Planning” und “User Stories Applied”.

Beide Bücher kann ich empfehlen, obwohl ich nicht empfehlen würde beide Bücher hintereinander zu lesen, wie ich es getan habe. Dafür ist die Schnittmenge des Inhalts zu groß.

Genug der Werbung: Wie plant nun das agile Projektmanagement? In letzter Instanz nicht so viel anders, als das klassische Projektmanagement, wenn es richtig gemacht wird. Es wird das geplant was planbar ist, und was für eine erfolgreiche Weiterarbeit notwendig ist. Bei der klassischen Netzplantechnik ist es naheliegend alle Aktivitäten gleich detailliert zu planen, obwohl dies weder realistisch noch förderlich ist.

Mike Cohen empfiehlt getrennte Planungen für unterschiedlichen Planungshorizonte: Projekt, Release, Iteration, Tag. Dadurch wird auch gleich ein weiterer typischer Fehler von klassischem Projektmanagement vermieden: Bei Projektbeginn wird der Projektplan erstellt und dann allenfalls mit dem Projektfortschritt aktualisiert. Klar, dass der bald nichts mehr mit der Realität zu tun hat. Aber wenn der detaillierte Plan nur bis zum Feierabend reicht, dann kommt man nicht drum rum am nächsten Morgen einen neuen Plan zu machen. Das gleiche gilt für die Pläne auf Iteration und Release Ebene.

Damit wird das Möglich, was für mich ein ganz wichtiger Aspekt der agile Projektarbeit ausmacht: Embracing Change (Änderungen umarmen?) d.h. Änderungen der Ziele und Vorgaben werden nicht als Störung des Projektes betrachtet, sondern als integraler, willkommener Bestandteil des Projektgeschäftes.

Aber was passiert mit den heiß geliebten Gantt-Charts und der Netzplantechnik? Diese sind tatsächlich hinfällig. Als Ersatz für die Abhängigkeiten im Netzplan werden die Anforderungen (Stichwort: User Stories) so gewählt, dass sie möglichst unabhängig voneinander sind. An dieser Stelle wird die Sache meiner Meinung nach wirklich spannend. Warum meint die Softwarebranche ohne diese Abhängigkeiten zurecht zu kommen, obwohl andere Branchen seit Jahrzehnten darauf schwören? Weil bei (gut geschriebener) Software jeder Teil geändert werden kann, ohne dass dies nennenswerte Auswirkungen auf andere Teile hat, während dies bei klassischen produzierenden Gewerbe unmöglich ist.

Man stelle sich mal vor, bei einem fertigen Gebäude soll das Fundament ausgetauscht werden … unmöglich, unbezahlbar. Bei einem Programm die Persistenzschicht austauschen? Kein wirkliches Problem, natürlich müssen beide Varianten der Persistenzschicht entwickelt und letztendlich bezahlt werden, aber bei dem Rest des Programm sollte sich recht wenig ändern. Während das klassische Gebäude wohl komplett ab und wieder neu gebaut werden müsste. Dadurch ist es möglich die Bestandteile in beinahe beliebiger Reihenfolge zu erstellen. Im Umkehrschluss bedeutet dies aber auch, Projektanteile die nicht so flexible disponiert werden können, müssen entsprechend langfristig geplant werden. Know How in diesem Bereich ist also nicht verloren.

In allen anderen Bereichen geht es meist um eine verschobene Gewichtung: Wenn Plan und Realität auseinander gehen, wird dies eher über Anpassung der Ziele, d.h. des Projektumfangs aufgefangen, als durch Veränderung des Arbeitsvolumens. Dabei trifft der Kunde die Entscheidung was genau gestrichen oder angepasst werden sollte, anstatt wie ich es oft erlebt habe Grabenkämpfe um die Übernahmen der Kosten zu führen.

Löst das alle Probleme? Ganz sicher nicht. Letzten Endes geht es in Projekten um Geld und da wird es Konflikte geben. Aber ich bin überzeugt, fast alle Projekte könnten von einer kleinen oder größeren Prise ‘Agile Estimating and Planning’ profitieren, nicht nur Softwareentwicklungsprojekte. Und wenn unsere Kunden das Buch lesen würden, könnten wir sie eher davon überzeugen gemeinsam ein Projekt zu machen anstatt gegeneinander.

Der Roman wird immer wieder gelobt und gepriesen dafür, dass er Projektmanagement Know How in Form eines Romans vermittelt.

Meine Manöverkritik fällt da etwas anders aus:

Als Roman ist das Buch katastrophal schlecht. Die Charaktere haben nicht ganz soviel Profil wie eine Briefmarke. Beim Spannungsbogen hat er die Sehne vergessen und das Happy End ist einfach nur angeklebt. Die innere Logik fehlt komplett: Warum hat ein kleines armes Land Unmengen an sehr guten Softwareentwicklern, die aber alle nichts zu tun haben und das seit dem Niedergang des Ostblocks, also seit ca. einem halben Jahrzehnt zum Zeitpunkt des Erscheinens des Buches Mitte der 90er? Warum wird ein Manager, der in der Lage ist ein Team von 15000 Entwicklern so zu leiten, dass unmögliche Termine eingehalten werden, gefeuert? Die Liste von Fragen ließe sich fortsetzen bis mein Herz streikt, also weiter zum nächsten Kritikpunkt.

Fachlich schreibt Herr De Marco des öfteren einfach nur Quatsch. Eine Functionpoint Analyse von 6 Projekten mit insgesamt 20000 (in Worten zwanzigtausend) Functionpoints innerhalb eines Tages gehört dazu. Oder die Qualitätsbewertung von einzelnen Mitarbeitern nach CMMI, was so sinnvoll ist, wie die Temperatur eines Vakuums messen zu wollen (Um fair zu sein CMMI wird nicht ausdrücklich erwähnt, aber es ist recht offensichtlich gemeint).

Die Lehren die der Hauptcharakter aus seinen Erlebnissen zieht sind in vielen Fällen doch äußerst zweifelhaft, so zum Beispiel die Hymnen auf Functionpoint Analyse und das Wasserfallmodell. Bei letzterem behauptet De Marco, die Ergebnisse würden um so besser, um länger und intensiver man sich mit dem Entwurf beschäftigt.

Zu allem Überfluss ist die Übersetzung hölzern und sagen wir mal eigenwillig. Wenn “Whiteboard” als Weißtafel übersetzt wird freut man sich nur noch, dass es wenigstens nicht Weißbrett geworden ist.

Am ärgerlichsten ist jedoch, dass das Buch die gemachten Versprechen nicht hält. Es geht die ganze Zeit um ein Experiment, in dem die Wirksamkeit von verschiedenen Managementmethoden mit einander verglichen werden sollen. Aber es werden fast nie Managementmethoden miteinander verglichen! Und wenn, wird die eine von einer völlig inkompetenten Person repräsentiert, so dass das Ergebnis weder überraschend noch lehrreich ausfällt.

Aber Tom De Marco hat nicht alles falsch gemacht. Jeder der sein Buch liest und glaubt, muss zu dem Schluss kommen, dass man bei einem Problem nur einen Berater ins Haus holen muss und schon flutscht es wieder. Da Tom De Marco selbst Berater ist, ist das Buch damit wohl eine der erfolgreichsten Werbebroschüre aller Zeiten.
Wieso habe ich das Buch also bis zum Ende gelesen? Das Buch liest sich extrem schnell. Da die Geschichte unintressant ist, und die Fakten äußerst dünn, kann man es innerhalb von ca. 4 Stunden ganz gut durchlesen.

Wen ich immer noch nicht von diesem Buch abbringen konnte, dem empfehle ich gleich noch eins: Der Minuten-Manager. Das Buch enthält weniger (falsche) Informationen, die Geschichte ist ähnlich schlecht wie von “Der Termin”, aber was entscheidend ist: Man kann es in ca 0,5 bis 1 Stunde durchlesen.

Um den Leser nicht völlig ohne Lesestoff zurückzulassen hier noch eine Buch, das mir schon vor geraumer Zeit wirklich gut gefallen hat: Cryptonomicon. Leider wird man auch hier wenig über Projektmanagement lernen, dafür gibt es aber viele interessante Stunden und nebenbei sogar noch ein wenig Wissen über Verschlüsselung und Geschichte.