5 Ideas what to to with your done tickets

When I talk about Kanban, I sometimes get asked: „What shall we do with all the tickets after they are done?“ Two years ago my answer was: „If the task is really done, just throw the ticket away.“ But during the past couple of months I’ve learned that there are many useful things you can do with the done tickets. Here are my top 5.

Note: I’ve faked all the pictures shown in this article, but I’ve seen all of the described scenarios in real life.

1: The leaf approach

Leave all tickets in the done column until they fall off the wall – like leaves fall off the trees in fall (this, of course, only works if you use sticky notes, otherwise you might be waiting for a long time:-) The adventage is that it has a motivating effect, because it shows to the team and everyone passing by how much the team gets done.

2: Separate by weekdays

How much do you get done on which weekday? Are there paterns? If these questions are interesting for you, you can simply divide the done column into five swim lanes – one for every day of the week. At the end of the week (or the beginning of the new week) you hold a quick retrospective: How are the done tickets distributed amongst the weekdays? Why is that? Meetings? Incidents? And do we see patterns regarding which type of work is usually finished on what day of the week? After you have talked about this, take a picture and then throw the tickets away (or use them in any other way you find useful).

Note: I think I‘ve read about this technique in a blog post before I suggested it to one of my clients who now applies it. If you know the original reference, please let me know.

Update: Now I found out that it was this post by Jesco von Voss I saw this technique before.

3: Use them for generating your charts

If you’ve ever played GetKanban, you know that updating charts is not as much effort as we might think. Often it only means plotting one data point for every ticket you get done. So what if we wouldn‘t plot points but use our done tickets as dots instead? This ist not only more fun, but it also provides us with additional information, because we still have all the information written on the ticket available. Use this charts for your daily work, for feedback meetings, for forecasting and for discussing with your stakeholders.

Here’s an example of a Time Distribution Chart (aka Spectral Analysis Chart). 

Of course a Run Chart (mostly named „Cotrol Chart“ although we don’t use control limits) is also possible and not much effort, either.

And here’s a suggestion for a Burn Up Chart built with sticky notes. I’m also thinking about using Cumulative Flow Diagrams this way. I think it would look really cool. The only disadvantage would be that you have to clone tickets avery day (because you don’t take tickets from „testing“, „developing“ etc. off the wall before they are done).

4: Make improvement opportunities visible

Imagine you are working in a big company. Your team is supposed to build features, but in fact you are doing bug fixes and enhancements for other teams most of the time. You feel that this is a problem, but it’s mostly a gut feel. So why not collect the done tickets for a longer period of time, so that you will see how the mix of Features, Bug Fixes and Enhancements is? This picture might be an eye opener for your team and your stakeholders:

After you have visualized that, you can go even one step further. Another problem is that your team has interdependencies with other teams. This leads to the situation where you get your tickets done, but after that they will not be deployed for weeks or even months because of these dependencies and the complicated deployment process. You have talked about with other teams and your boss but they seem not really to understand how bad this situation really is. So you change your done column into a time line with the next planned release as the end date. Now you get a really good picture how much costs (cost of delay) your company generates, bacause valuable features have to wait for weeks before the will be deployed. And this picture shows another truth: Of course you could work on becoming more efficient in your team. But this is probably only a tempest in the teapot. The real big leaver here is to reduce the wait time before deployment! And why does the mix of features change over time? Why do we have so many pink tickets just before the release?

Click to enlarge

5: Box them

When I visited one if my clients for the first time, I saw they had a box next to their board in which they collected all the done tickets. I asked: „What do you do with all the tickets?“ The answer was one of the coolest things I‘ve ever heard. „We ship them to our competitor.“ Until today I’m not sure if they were kidding or not.

Summary

• There are many ways to use your done tickets. Which technique is appropriate for you? There is only one way to find out: Try. If it does not provide you with any value, try something different! What I‘ve learned is that done tickets can be used for better understanding your team‘s/organization‘s demand as well as its capability. You can use them as a learning tool, and it can be a great tool for showing improvement opportunities. And last but not least: It should be motivating. 

One disadvantage of some of the techniques I‘ve described in this post is that they require a lot of space. So it might not be possible to simply copy them. But I‘m sure you will find a way to emerge new techniques that fit your context.

Do you find this useful? Do you have any other examples what to do with done tickets? Please share them!

P.S. Mike Cohn has just tweeted another possibility for using your done tickets: decorate your Christmas tree ;-) 

Ist Little’s Law keine lineare Beziehung?

Wer sich intensiver mit Kanban beschäftigt, kommt um Little’s Law nicht herum. Diese Formel sieht einfach aus, hat es aber in sich. Immer wenn ich glaube, ich hätte verstanden, woraum genau es geht und wie man Little’s Law sinnvoll einsetzt, kommen bei mir neue Fragen auf. Deshalb ist ein ein riesiger Glücksfall, dass ich dieses Jahr in Boston Frank Vega kennen gelernt habe. Frank ist nicht nur ein unglaublich netter Mensch, sondern er ist ursprünglich auch Mathematiker. Und in unserer Community ist er sicherlich einer der größten Experten zu Little’s Law und dem ganzen Bereich der Warteschlangen-Theorie. Aus einer Frage, die ich Frank per Mail gestellt hatte, ist ein Blog Post entstenden, der für mich definitiv zu den besten Post gehört, die 2012 geschrieben wurden. Deshalb habe ich Frank gefragt, ob ich seinen Post (eigentlich ist es mehr ein Fachartikel als ein Blog Post) ins Deutsche übersetzen darf. Und er hat es erlaubt :-)

Hier findet man den ursprünglichen, englischen Post von Frank

Hier also der übersetzte Text von Frank:

“Unter dem Strich lässt sich festhalten: Der größte Hebel, um Produkte schneller auszuliefern, besteht darin, sich auf die wichtigen Produkte zu fokussieren und die unwichtigen aufzugeben.“
Here’s the bottom line: the number one driver for shipping products quicker is by focusing on the important ones and killing the unimportant ones.”
“Jetzt denken Sie vielleicht: ´Das mag ja alles stimmen, aber können wir nicht auch diue durchschnittliche Fertigstellungsfrequenz (completion rate) erhöhen?´  Im Prinzip haben Sie Recht, aber der Effekt davon ist viel geringer, als wenn wir den TIP (things-in-process), also die Menge an parallelen Dingen, reduzieren. Das liegt daran, dass es sehr schwieirg ist, die durchschnittliche Fertigstellungsfrequenz zu erhöhen, denn diese ist häufig eine Funktion aus verfügbaren Ressourcen, sich ständig vermehrenden Anforderungen, Anforderungen und Veränderungen des Marktes usw.“
 You might be thinking: ‘True, but couldn’t we also increase the average completion rate’? You’re right, but the impact of doing that is much lower than reducing the TIP (things-in-process) — that is, influencing the average completion rate is rather difficult and is often a function of available resources, scope creep, market demands and changes, etc.”
- Pete Abilla, Nov 2006, Little’s Law for Product Development

Vor ein paar Wochen hat Arne Roock, ein Mitstreiter im Bereich Kanban/Lean-Agile, mir diese Frage zum Zusammenhang zwischen Little’s Law und Auslastung gestellt: „Die Warteschlangentheorie sagt uns, dass die Geschwindigkeit von Netzwerken drastisch (nicht-linear) abnimmt, sobald die Auslastung über 80% ansteigt. Gleichzeitig folgt aus Little’s Law (ein stabiles System vorausgesetzt), dass sich die Durchlaufzeit linear verlängert, in dem Maße wie wir den WIP (work-in-progress) erhöhen (was eine Erhöhung der Auslastung bedeutet). Aber müsste uns Little’s Law nicht eigentlich voraussagen, dass die Durchlaufzeit ab einem bestimmten Zeitpunkt (in etwas ab 80% Auslastung) exponenziell ansteigt?“ Aus dieser Frage entwickelte sich ein E-Mail-Austausch über Little’s Law und warum in der Softwareentwicklung ein erhöhter WIP zu einem exponenziellen Wachstum der Durchlaufzeit führen kann. In diesem Artikel gebe ich einige Gedanken aus unserer E-Mail-Diskussion wieder und spinne diese weiter. Ich könnte mir vorstellen, dass auch Andere sich über diese Fragen Gedanken gemacht haben. Falls ja, wird dieser Artikel hoffentlich nützlich sein.

Little‘s Law: In aller Kürze

Zuerst sollten wir alle auf demselben Stand sein und uns die Grundlagen zu Little’s Law ansehen. 

Hinweis: Ich habe beobachtet, dass Little’s Law je nach Kontext und Szenario ganz unterschiedlich formuliert und bezeichnet wird. Die nachfolgenden Varianten beziehen sich in erster Linie auf meine eigenen Anwendungen im Bereich der Softwareentwicklung

In der Regel wird Little’s Law wie folgt dargestellt:

L = λ W

Dabei gilt:

L = die durchschnittliche Anzahl an Aufgaben in einem Warteschlangen-System (Queuing System) innerhalb eines bestimmten Zeitabschnitts

λ = die durchschnittliche Anzahl an Aufgaben, die innerhalb eines definierten Zeitintervalls neu in das System gelangen (Ankunftsrate)

W = die durchschnittliche Zeit, die eine Aufgabe insgesamt im System verbringt

Durch simple Algebra lässt sich Little’s Law umformulieren. Wenn wir die Größen dann noch umbenennen, bekommen wir die Form,  die im Kontext der Softwareentwicklung häufig verwendet wird:

LT = WIP / Durchsatz

Dabei gilt:

LT = die durchschnittliche Lead Time, also die Durchlaufzeit, die eine Aufgabe benötigt, um durch den gesamten Workflow von Beginn bis zur Auslieferung zu gelangen

WIP = die durchschnittliche Anzahl an Aufgaben (Work in Progress), die gleichzeitig begonnen wurden und sich innerhalb eines definierten Zeitraums innerhalb des Workflows befinden

Durchsatz  = die durchschnittliche Anzahl an Aufgaben, die das System innerhalb eines definierten Zeitintervalls verlassen

Beachtenswert ist dabei, dass sich bei dieser Umstellung der Formel die ursprüngliche Ankunftsrate in den Durchsatz verwandelt – also die Frequenz, in der Aufgaben das System verlassen.

In der Softwareentwicklung nehmen Aufgaben typischerweise die Form von User Storys, Change Requests, Bug Fixes usw. an

Hinweis: Hier gibt es einen älteren Blog Post von mir, in dem ich den Unterschied zwischen Lead Time und Cycle Time diskutiere und auch darauf eingehe, welche Auswirkungen sich daraus für das Tracking von Zeiten vs. Tracking von Aufwänden ergeben.

Little‘s Law: Eine kurze Probefahrt

Nun wollen wir die zweite Darstellung von Little’s Law einmal hernehmen und eine kurze Probefahrt „im Klassenzimmer“ unternehmen. Im Grunde ist es ja ein einfaches Verhältnis: Wenn wir den Durchsatz (also den Nenner) konstant lassen, dann können wir leicht sehen, dass sich die Durchlaufzeit (Quotient) proportional verlängert in dem Maße, indem wir den WIP (Zähler) erhöhen. In diesem Schul-Beispiel gibt es keine Schwieirgkeiten, oder?
Aber wie tragfähig ist die Annahme wirklich, dass wir den Durchsatz konstant halten können, wenn wir den WIP erhöhen? Wir werden in Kürze auf diese Frage zurückkommen. Aber zuerst müssen wir alle Annahmen verstehen, auf denen Little’s Law fußt.

Little‘s Law: Annahmen

Es gibt nur wenige solcher Annahmen, und hier ist meine Zusammenfassung: Alle drei Parameter in Little’s Law müssen in derselben Einheit dargestellt sein; bei jedem Parameter handelt es sich um einen langfristigen Durchschnitt; und wir haben es mit einem stabilen System zu tun. Die erste dieser Annahmen ist trivial. Wenn wir den Durchsatz als Anzahl an erledigten Aufgaben pro Tag definieren, dann muss sich der WIP auf dieselben Aufgaben beziehen. Im Kontext der Softwareentwicklung beispielsweise kann der Durchsatz sich auf fertig gestellte Tasks pro Tag beziehen. Dann darf sich der WIP aber nicht auf User Storys beziehen.
Die letzten beiden Annahmen sind hingegen etwas kniffliger, denn sie nehmen je nach Kontext und Szenario etwas andere Formen an. Es ist wichtig, sich über diese unterschiedlichen Gestalten klar zu sein und sie zu verstehen. Aber eine ausführliche Diskussion kann in diesem Artikel nicht geleistet werden. Als weiterführende Literatur verweise ich hier auf Kapitel 5 des (englischen) Aufsatzes „ Little’s Law“ von Dr. Stephen C. Graves, Professor für Mechanical Engineering and Engineering Systems am M.I.T.
An dieser Stelle werde ich nur insoweit auf Details eingehen, wie sie in unserem Zusammenhang wichtig sind.

Little’s Law: Langfristige Durchschnitttswerte und ein stabiles System

Jetzt wird es Zeit, dass wir uns die Hände schmutzig machen und Little’s Law mitsamt seinen Annahmen einmal an einem einfachen Praxisbeispiel ausprobieren. Mein Beispiel mit den zwei Wassertanks wurde wiederum von einem anderen Beispiel inspiriert, das ich hier gefunden habe.
In den linken Tank fließt Wasser in der Menge von 8 Liter pro Stunde herein und heraus. Der Durchsatz, also die Menge an Wasser, die den Tank verlässt, bleibt konstant. Ebenso bleibt der WIP, also der Wasserstand im Tank, bleibt konstant bei 20 Litern. Weil kein Wasser am Rand des Tanks hängenbleibt, bleibt die Lead Time, die ein Wassermolekül (oder ein Liter Wasser) benötigt, um einmal durch den Tank zu fließen, ebenfalls konstant. Noch einmal zur Wiederholung: So lange wir konsistent beim Durchsatz und beim WIP  bleiben, spielt es keine Rolle, ob wir Moleküle oder Liter als Einheit nehmen – oder irgendetwas ganz Anderes, was uns gerade besser passt.

Wenn wir nun Litle’s Law anwenden, erhalten wir eine Lead Time von 2,5 Stunden (20 / 8). Wir gehen das einmal kurz durch: Wenn kein weiteres Wasser in den Tank fließen würde, dann wäre der Tank (bei gegebenem Durchsatz von 8 Litern pro Stunde) in genau 2,5 Stunden leer. Wenn wir nun genau so viel Wasser neu in den Tank füllen, wie hinausfließt, bleibt der Wasserstand konstant und es ergibt sich eine durchschnittliche Durchlaufzeit von 2,5 Stunden.
Nun erhöhen wir die Auslastung des Wassertanks. Wir lassen also so lange mehr Wasser hinein- als herausfließen, bis der neue  Wasserstand von 80 Litern erreicht ist. Danach gehen wir wieder zurück auf den vorherigen Zustand und lassen genau so viel in den Tank, wie auch hinausströmt (8 Liter / Stunde). Dabei halten wir die ganze Zeit über den Durchsatz, also die Menge an Wasser, das den Tank verlässt, konstant. Egal wie viel Wasser in den Tank fleißt, es fließt immer genau gleich viel heraus.

Hinweis: Ich konzentriere mich auf die Frage, was geschieht, wenn wir den Wip erhöhen, weil dies der Kern der Ausgangsfrage nach Little’s Law und der Auslastung eines Systems ist. Mir ist bewusst, dass es noch die verwandte Frage gibt, was geschieht, wenn wir den WIP unter eine bestimmte Menge reduzieren. Dieser Frage gehe ich jedoch in diesem Post nicht weiter nach.

In der Phase, in der mehr Wasser in den Tank gelangt als herausläuft, ist der WIP kein langfristiger Durchschnitt mehr, sondern er erhöht sich mit der Zeit. Wenn wir den WIP (=Wasserstand im Tank) erhöhen, so sagt uns Little’s Law eigentlich, dass die durchschnittliche Lead Time für die einzelnen Wassermoleküle sich verlängert. Aber ist es überhaupt zulässig, Little’s Law in der Phase anzuwenden, in der mehr Wasser in den Tank hinein- als herausfließt?
Der Durchsatz bleib zwar die ganze Zeit über konstant, in der sich der WIP erhöhte. Aber in unserem einfachen Wassertank-Beispiel haben wir erst dann wieder ein stabiles System, wenn wieder so viel Wasser in den Tank gelangt wie ihn auch wieder verlässt. Sobald das System dann wieder stabil ist, berechnet uns Little’s Law eine neue langfristige durchschnittliche Lead Time. Der neue WIP beträgt 80 Liter, der Durchsatz bleibt bei 8 Litern, also ergibt sich eine neue Lead Time von 10 Stunden. Und dieser Anstieg der Lead Time ist wiederum proportional zum Anstieg des WIP, der jetzt ja 4 mal zu groß ist wie zuvor. Man beachte, dass in den Annahmen, auf denen Little’s Law gründet, nichts über die Auslastung des Systems ausgesagt ist.

Little’s Law: Der Effekt von Auslastung

Stellt nun also Lillte’s Law eine „lineare“ Beziehung dar in dem Sinne, dass ein Anstieg im WIP immer zu einem proportionalen Anstieg der Lead Time führt? Um diese Anfangsfrage zu beantworten, müssen wir überlegen, inwieweit die Annahme zutrifft, dass wir den Durchsatz wirklich konstant halten können, wenn wir den WIP erhöhen.
Das Beispiel des Wassertanks ist ein sehr einfaches Szenario für den Einsatz von Little’s Law, weil darin ein schön gleichmäßiger und kontinuierlicher Workflow modelliert wird. Der Wert dieses Beispiels besteht für mich darin, sich klar zu machen, wie wichtig diese Annahme ist. Zu verstehen, warum wir in allen drei Parametern dieselben Einheiten brauchen, ist einfach. Jetzt ist hoffentlich auch klar geworden, warum wir langfristige Durchschnittswerte und ein stabiles System benötigen, wenn wir Little’s Law anwenden möchten.

Hinweis: Für mich ergibt sich aus dem bisher Gesagten, wie wichtig WIP-Limits sind. Selbst wenn wir zu Beginn nur ein einziges Limit für das gesamte System etablieren und dieses Limit zuerst absurd hoch zu sein scheint, so trägt dieses Limit dazu bei, ein System stabil zu machen und zu erhalten. Dadurch wird es möglich, dieses hilfreiche Werkzeug (Little’s Law) effektiv einzusetzen, um besser zu verstehen und zu lernen, wie wir unseren Workflow verbessern können. Und hierdurch können wir auch besser beurteilen, welche Maßnahmen wirklich zu Verbesserungen führen.
Ich bekomme häufiger gesagt, dass Leute keine „expliziten“ WIP-Limits haben, sie aber trotzdem in den meisten Fällen „erfolgreich“ ausliefern. Gleichzeitig haben sie eine beträchtliche Mange an Aufgaben gleichzeitig in Arbeit. Wenn ich dann ein bisschen tiefer grabe, stoße ich meistens auf einen (oder beide) der folgenden  Punkte.
Der erste Fall besteht darin, dass es eine Person gibt (meistens ein erfahrener und begabter Projektmanager), der mit „impliziten“ WIP-Limits arbeitet. Das bedeutet, er sorgt dafür, dass einige Aufgaben zurückgehalten werden, indem er den Umfang oder den Komfort von Features reduziert und sich darum kümmert, Erwartungen und sichtbare Risiken zu managen. Dies würde ich als „gutes“ Projektmanagement ansehen, aber ich stoße nicht häufig darauf. Im zweiten Fall von „impliziten“ Limits ist die Qualität verbesserungswürdig und das System erfordert erhebliches „Heldentum“ bei den Beteiligten, um zu funktionieren.
Ich beobachte eine ganze Reihe von Nachteilen, die sich aus dieser impliziten Art der Limitierung ergeben: Durch die schlechte (oder gar nicht vorhandene) Sichtbarkeit wird der Prozess noch subjektiver, häufig auch „politischer“; Umwege werden wahrscheinlicher; es gibt mehr Kontextwechsel; häufig werden mehr „ungeplante“ Überstunden fällig; es entstehen mehr Bugs und Hacks usw. Und ja: Auch explizite WIP-Limits werden manchmal ignoriert – mit ähnlichen Ergebnissen. Aber nachdem ich mit beiden Arten (explizite und implizite Limits) gearbeitet habe, lehrt mich meine Erfahrung, dass es besser ist, WIP-Limits (passend zur Leistungsfähigkeit des Systems) explizit festzulegen und zu visualisieren und dann durch Policies zu Verhaltensweisen zu ermutigen, durch die der Workflow im Hinblick auf diese Limits gemanaged wird. Dadurch wird sich eine effektivere (d.h. weniger subjektive) Umwelt ergeben, in der es einfacher ist, die wirklichen Ursachen für Verzögerungen und schlechte Qualität aufzudecken und dann sinnvolle Änderungen durchzuführen und hinterher zu bewerten.

Aber es bleibt die Frage, ob wir es im Bereich der Computer-Netzwerke und in der Softwareentwicklung mit ebenso gleichförmigen und gleichmäßigen Szenarios zu tun haben wie in unserem Wasser-Beispiel? Und falls nein: Wie würden sich die Unterschiede auf Little’s Law auswirken? Bezogen auf die Softwareentwicklung kam mir sofort ein Gedanke: Wenn wir den WIP erhöhen, führt dies wahrscheinlich zu mehr Kontextwechseln (falls wir dem nicht durch explizite Regeln entgegenwirken). Und diese Kontextwechsel können bewirken, dass wir den Durchsatz nicht konstant halten können.
Dazu sehen wir uns noch einmal diese Darstellung von Little’s Law an:
LT = WIP / Durchsatz
Wenn es stimmt, dass ein erhöhter WIP zu mehr Kontextwechseln und somit zu einem niedrigeneren Durchsatz führt, dann haben wir es mit einem höheren Zähler und gleichzeitig einem niedrigeren Nenner zu tun. Wenn wir nun diese neuen Zahlen (als neue langfristige Durchschnittswerte) in Little’s Law einfügen, dann wird die Lead Time nicht mehr linear im Verhältnis zum WIP ansteigen. Noch einmal in Kurzform: Wenn wir bei einem erhöhten WIP den Durchsatz nicht konstant halten können, sondern dieser sinkt, dann werden wir beobachten, dass die Lead Time nicht-linear zum WIP ansteigt.

Zusammenfasung

Die Kernpunkte meiner E-Mail-Diskussion mit Arne lassen sich wie folgt zusammenfassen: 1) Es ist wichtig, sich darüber klar zu werden, auf welchen Annahmen Little’s Law basiert und was diese Annahmen für den jeweils betrachteten Kontext bedeuten. 2) Je nach Kontext kann sich aus Litte’s Law ergeben, dass die Lead Time linear oder eben auch nicht-linear ansteigt wenn wir den WIP erhöhen.
Wenn wir die zweite Darstellung von Little’s Law verwenden, dann müssen wir sicher gehen, dass wir es mit einem stabilen System mit langfristigen Durchschnittswerten für WIP und Durchsatz zu tun haben, bevor wir einen langfristigen Durchschnittswert für die Lead Time berechnen können. Wenn der Durchsatz konstant bleibt, während wir den WIP auf ein neues Niveau erhöhen, so wird die neue Lead Time sich proportional zum WIP erhöhen. Wenn allerdings der Anstieg des WIP mit einer Verringerung des Durchsatzes einhergeht (z.B weil es im Kontext der Softwareentwicklung zu mehr Kontextwechseln kommt), so wird die neue Lead Time im Verhältnis zum WIP nicht-proportional ansteigen.
In den nachfolgenden Tagen, nachdem ich dies hier aufgeschrieben hatte, wurde mir allerdings klar, dass es noch viel mehr zu Arnes ursprünglicher Frage zu sagen gibt. Ich hatte das Gefühl, dass wir auf den ersten Teil der Frage noch gar nicht tief genug eingegangen sind. Die dargestellten Punkte zu Little’s Law waren zwar sehr hilfreich für die Diskussion, aber sie beantworten immer noch nicht die Frage, warum in Computer-Netzwerken die Geschwindigkeit nicht-linear absinkt, sobald die Auslastung über 80% steigt. Im Nachhinein muss man wohl sagen, dass dieser Beitrag Arnes Frage gar nicht wirklich beantwortet hat. Also habe ich danach mehr und mehr darüber nachgedacht, wie und warum die drastische Absinken der Geschwindigkeiten von Computer-Netzwerken bei starker Auslastung zu erklären ist. Und noch wichtiger: Können wir daraus etwas über die Art lernen, wie wir unsere Policies erstellen und anpassen sollten, um unser System bei hohem WIP zu managen? Man kann sich denken, dass ich tiefer in dieser Frage eingestiegen bin und bereits einige interessante Dinge gelernt habe. Diese Dinge würde ich gerne aufschreiben und mit Anderen teilen. Aber dies gehört definitiv in einen zukünftigen Post

Alle Gute,
Frank

Anmerkung von mir (Arne Roock): Ja, es beantwortet meine Frage nur zum Teil. Aber das macht nichts, denn dieser Post beantwortet dafür eine ganze Reihe von Fragen von denen ich noch nicht einmal wusste, dass man sie stellen sollte! Danke, Frank! Und ich warte gespannt auf den angekündigten nächsten Post!