blog-harvester's soup

Gestern hatten wir Zeit, Kinokarten und gemütliche Plätze im Sergio Leone Saal des Filmtheaters Schauburg. Es lief der Film Ziemlich beste Freunde.

Ein einfach schöner und lustiger Film. Und während ich mir gerade so überlege was ich hier weiter schreiben könnte, trudelt ein Artikel mit genau dem selben Thema im Feedreader ein.

So mache ich es kurz und verweise ganz pragmatisch auf den Beitrag von Rappel mit dem (un)überraschend gleichnamigen Titel: Ziemlich beste Freunde.

Das obige Bild stammt von der offiziellen Filmwebseite (Extras → Wallpaper).

After quite some time off I went to the Scrumtisch Berlin. The event was incredibly well visited - roughly 50 people filled the upper floor at Cafe Hundertwasser. Today’s event was organised such that participants first collected discussion topics, prioritised them together and then discussed the top three items in a timebox of 15 minutes each.

Topics collected were:

• Best tricks to make teams self organised (20 votes)
• What is QA doing fulltime in a team (13 votes)
• Ops and planning in a team (15 votes)
• PO disappears and takes backlog and vision with him - what now? (7 votes)
• Working with non-Software teams (17 votes)
• Pimp up my retrospective (12 votes)
• Multiple teams on one projects and vice versa (4 votes)
• IBM doing Scrum/ massive Scrum (9 votes)
• Feature knowledge vs market knowledge - what is more important in a PO if you have to choose due to people constraints (9 votes)
• How to convince a team to do more (3 votes)
• Why is agile good (10 votes)

Compared to previous meetings quite some topics repeat. About half of the attendees were there for the first time - so it seems there is a common set of questions people usually run into when rolling out Scrum.

Self organising teams

Seems like this is one of the most common questions run into when rolling out Scrum - how to really get to self organising teams. The question can be answered from two positions: What are the pre-requisites it takes to enable teams to become self organising? How to actually transform teams that are used to a command and control structure and are reluctant to transform?

The discussion, mainly led by Andrea Provaglio, CSM trainer focussed mainly on the first part of the question. Even when limiting discussion that way, the answer will still depend heavily on the organisation structure, number of management levels, team sizes.

Marion made the topic a bit more concrete: Given the flexible vacation planning approach of Netflix, her question was whether that sort of loose approach could work in a typical German company (after all we have 30 instead of <20 vacation days, we have fixed holidays, she as a C?O of course wants to avoid customers being left alone when the whole team is on vacation.) Andrea re-phrased agility a bit here. His proposal was to not allow people to take their time off just anytime but to give them the freedom to figure out when to take time off. He identified five principles for leadership:

• Clearly setting a goal (in that case: Everyone needs to have a vacation plan at a given date.)
• Provide the team with all resources, information and with the environment they need to accomplish their task.
• Define constraints (”there must be at least one guy in the office on any given working day”)
• Check back regularly
• Make yourself available to answer any questions

The discussion on teams reluctant to adopt self organisation was separated out and deferred. His point was mainly about enabling and encouraging self organisation. Enforcing self organisation however is not possible.

Scrum in non-Software teams

Though phrased very broadly the topic quickly turned into a “how to do Scrum for hardware” discussion. Main problem here is that the further down you go the longer design generally takes. Even just routing lines on one decently sized circuit board can take several weeks. Mainly three possible ways out of the problem emerged from the discussion:

• Loosening the definition of done - “potentially shipable” may not mean sellable or even really shipable. I don’t think one should go down that slippery path. Only by actually shipping can I get the feedback I need to improve my design. So instead of loosening the definition of done we should instead start thinking about ways to get faster feedback, reduce risk and introduce shorter iterations.
• Another way is to look for ways to reduce iteration length, even though we might not get down to software release cycles, and align releases such that integration can happen earlier.
• The third way out could be to realize that maybe Scrum does not quite fit that way of working and use a different process instead that still provides the transparency and fast feedback that is needed (think Kanban).

Overall the most important result of the discussion was that within 15min discussion the issues cannot be solved. After all the solution will depend on what exactly you are working on, who your suppliers are and what your team looks like. Most important is to recognize that there is a problem and to work on removing that impediment - most important is to identify issues and to improve your process.

Operations and planning in Scrum

The last question discussed involved operations and Scrum planning: Given a team that does software development but is interrupted frequently with production issues - how should they work in a Scrum environment.

There are multiple facets to that problem: When it comes to deciding whether to deal with something immediately or not it makes sense to weigh size of the issue against amount of work it takes to resolve it. “Getting things done” states that the minimum size of an issue to deal with instantly is 2min of work. Issue with that is that the assumption of GTD was that issues flow into and inbox that is dealt is when there is time. In production environments however these issues usually trickle in instantly interrupting developers over and over again incurring a huge cost due to task switching.

One way out might be to have an event queue and assign developers (on a rotating basis) to deal with the issues and leave time for others to work in a focused way. Make sure to rotate frequently instead of by sprint - otherwise you run into the problem of making the team unstable thus delivering no stable amount of business value each sprint.

Another obvious way is to account for frequent interruptions and include a buffer for those in your plan. The most important benefit of that approach is to make the cost of this working mode clearly visible to management - leaving the decision how to deal with it up to them.

Other simple fixes include introducing some level of indirection between the actual developer and the customer raising the issue, documenting solutions as well as incoming issues for better visibility, introducing a single point of contact capable of prioritising.

Coming back to vanilla Scrum however there is one interesting observation to be made: The main contract with iterations is for developers to be able to work in a focused way. Instead of having their tasks switched each day they are promised a fixed period of time to solve a given set of stories. In the end a sprint is a compromise between what management may need (change their mind on what is important frequently) and what developers need (working on a set of defined tasks not interrupted by re-priorisation). If the assumption of focus does not longer hold true, Scrum might be the wrong model. If what needs to be done changes daily, Kanban again might be the better option. Still making sure that the cost of task switching is visible is vitally important.

To sum up a very interesting Scrumtisch - in particular as agile methods really seem to become more and more common also in Berlin. Speaking of challenges: As user groups grow sometimes their character changes as well, in particular when built around participation and discussion. It will be interesting to watch Scrumtisch deal with that growth. Maybe at some point splitting the audience and having separate breakout sessions might make sense. Admittedly I’d also love to know more on the background of the audience: How many are actually using Scrum in the trenches vs. teaching Scrum as coaches? How long have they been using Scrum? In what kind of organisation? Maybe a topic for next time.

Ich bin eben über einen Tweet von @pixelgraphix über einen weiteren Farbtest Color – A color matching game gestolpert. Gegenüber dem Color IQ Test, spielt bei diesem hier auch ein gewisser zeitlicher Druck eine Rolle.

Ziel ist es in den Bereichen Hue, Saturation, Complementary, Analogous, Ternary und Quaternary die vorgegebene Farbkombination in der Mitte, im äußeren Farbkreis durch Mausbewegung möglichst genau zu treffen.

Meine Punktzahl betrug im ersten (kennenlernen) Versuch 7.0 und zweiten Versuch nun etwas höhere 8.2 Punkte.

• Color – A color matching game

Wer traut sich wieder?

Last week I spent several days in Chicago mainly to attend a few meetings at the local Nokia/Navteq office. Though the schedule was pretty packed, a few hours remained to explore the then frosty and windy city:

As usual I wondered whether there are any Apache people close by. So before flying in I checked our committers map. As there were a few people in that general area I sent a brief heads-up to the greatly under-advertised, private, non-archived, committers only list party@apache.org. In case you’ve never heard about it: The main use case of that list is to provide a means for committers to arrange for meeting up with fellow Apache people and share travel details.

As a result I received a brief list of things to do in Chicago and got to attend a small but really nice meetup. Having a means to get in touch with locals can make such a difference - thanks for the warm welcome! Hopefully next time I’m there weather is as warm - would love to explore the (at least according to my travel guide book) beautiful nature of the great lakes.

“Agile and Lean have a single purpose: to continually challenge the status quo. If you’re not doing that, you’re probably an impediment to it.”

agile42.com

Judging from the way some people become overly careful when discussing agile in general and Scrum in particular in my presence I seem to slowly have built up a reputation for being a strong proponent of these methods. Given the large number of flaky implementations as well as misunderstandings it seems to have become fashionable to blame Scrum for all badness and dismiss it altogether - up to the point where developers are proud to finally having abandoned Scrum completely - so that now they

• can work in iterations,
• accept new tasks only for upcoming but not for the current iteration,
• develop in a test-driven way,
• have daily sync meetings,
• mark tasks done only when they are delivered to and accepted by the customer,
• have regular “how to improve our work” meetings,
• estimate tasks in story points and only plan for as much work per iteration as was done in the past iteration

… my personal take on that: Add in regular releases and you end up with a pretty decent scrum/agile implementation, no matter what your preferred name for it may be. Just for clarification: Though very often I write about what I call Scrum, I don’t use that particular method just because it is the latest fashion. It simply is a tool that has served me well on multiple occasions and given me working guidelines when I had no idea at all what software development in a professional setting should look like.

So where does all that friction with anything Scrum, agile, lean or whatever you call it come from? Recently I came across a blog post that jillesvangurp.com nicely identified some grave issues with current Scrum adoption. Unfortunately the blog post only lists the failures without going into a deeper analysis of the actual defects causing those failures.

First of all, lets assume as working hypothesis that Scrum in itself does not solve any issues in your organisation but is a great tool to uncover deficiencies. The natural conclusion should be to use it as a tool to discover problems, but search for solutions for these problems elsewhere.

With that hypothesis, lets discern the the issues discussed in the post above and assign them to one of three defect categories.

Category one: Issues with the team

Problem: You have a team of all-junior developers, or of all-mediocre developers.

Goal: Turn them into a high performing team.

Solution: Imagine you were not using Scrum at all, what would be the ideal solution? Well the obvious route probably is to re-adjust the team, add several seniors so that you end up with the right mix of people that have experience and share a vision - juniors than can learn and adapt what works from them.

Comparing that to our hypothesis: Scrum is all for short delivery cycles. You will uncover teams that perform badly much faster than in methods with longer iteration periods. So it should be reasonably simple to figure out teams that have a dysfunctional configuration. Changing that configuration however no longer is dictated by Scrum.

Category two: Bugs introduced during Scrum roll-out

The failures discussed in the blog post include people following Scrum mechanically: Only because your developers are moving post-it notes from left to right does not mean they are doing anything agile. It’s perfectly possible to do waterfall in Scrum. Whether that helps solve any of your issues is a different matter.

Instead of mechanically going through the process what is more important is to understand the reasons and goals of each of the pieces that form Scrum. To make a rather far fetched comparison:

When introducing Scrum without a deep understanding of why each piece is done, what you end up with is people following that process without understanding the meaning of each step. They end up mimicking behaviour without knowing the real world: To some extend seeing only the shadows of good development patterns without understanding the real items producing these shadows.

As a general rule: Understand why there is a retrospective meeting, remember why you need estimations, think about why there are daily stand-ups (instead of weekly meetings, instead of daily sit-togethers, instead of hourly stand-ups). Figure out why there is a product owner, what the role of a scrum master does. Pro-Tip: As soon as you really have understood Scrum, you don’t need a checklist of all meetings to hold for a successful iteration - they will just fit in naturally. If they don’t, you are probably missing an important piece of the puzzle - rather than rely on a pre-fabricated checklist, go bug your trainer or coach with questions to better understand the purpose of all the different bits and pieces.

One very grave bug on roll-out is the general believe that Scrum is equal to a little bit of fairy dust you spread over your teams and all problems will automatically be solved afterwards. It is not - it’s not a silver bullet, it’s not fairy dust, it’s no magic - such things exist in fairy tales but have been seen nowhere in the real world. According to our working hypothesis above however Scrum does something really magical: By shortening delivery cycles it introduces short feedback loops which make it very easy to uncover problems in your organisation way faster than people are able to cover them up and hide them. Finding a solution on the other hand is still up to you.

The last roll-out issue mentioned is that of crappy certification - current certification programs are designed such that the naive organisation may believe that after two days of training their employers will magically turn into super heroes. Guess what - as with any certification training is just the very first step. Actual understanding comes with experience. Compare that to learning to drive: Only because you managed to get a drivers license does not turn you into a formula one winner. Instead that requires a whole lot of training. Same applies for any Scrum Master or Product Owner.

Category three: Organisation specifics

All other issues with Scrum mentioned in the blog post are either specific to the broken structures in the organisation under investigation or due to general Scrum mis-conceptions. Leaving these aside here.

To sum up: Scrum to me is nothing but a term to summarize good, proven development practices. I don’t care how you name them - however having any one name that is well defined makes it way easier to communicate.

On a related note, what constitutes Lean, Agile and Scrum is not a silver bullet that is applicable to each and every situation. There may well be times where there are better ways to model your development process.

Über Golem bekam ich gerade mit, dass es jetzt den Editor Vim auch für iOS gibt. Es ist eine kostenfreie universelle Version für einen iPod touch, ein iPhone oder ein iPad.

• Applidium: Vim
• Appstore Direktlink

Mir scheint, die Vim iOS App ist für aktuelle hochauflösende Displays optimiert. Bei meinem ollen iPod touch kommen die Buchstaben in der Standardgröße nur in Bruchstücken an.

Aber gut zu wissen, dass man den Vim nun auch mit entsprechendem iOS Gadget immer am Man(n) haben kann. Die Usability und der Nutzen ist zwar etwas, vorsichtig ausgedrückt, beschränkt … aber he es ist der Vim.

Erinnerungen an die Ostsee 2010.

Dieser Beitrag ist gleichzeitig ein Test für zwei neue Features hier im Blog. Denn ich bastel gerade an einer Lösung, um zum Einen mehrere große Fotos einzubinden, bisher war nur eines möglich, und zum Anderen, dass nun auch sehr sehr breite Fotos möglich sind.
Die hier gezeigten Fotos haben eine maximale Breite von 1600px, so dass sich auf einem 22″ Monitor das Betrachten im Fullscreen durchaus lohnt. Ist das Browserfenster zu klein, passen sich die Fotos an.

Eine nicht unbedingt neue Besonderheit ist, dass die großen Fotos nur hier im Blog groß kommen. Also im Feedreader den Fullfeed lesen ist ok, aber die großen Fotos gibt es nur hier im Blog in groß zu sehen.

EDIT: Ich sehe gerade, im Feed kommen jetzt gar keine Bilder mehr. Die Änderung hat doch ungewollt Auswirkung auf den Feed. Hier muss ich noch Nachbessern.

I’ve heard of several people who are not quite sure yet whether they should visit Berlin Buzzwords or not - in particular when having to travel far and cross 9 time zones to attend. My general recommendation is to plan to spend some more days in Europe. The conference is conveniently scheduled on Monday and Tuesday which gives you one weekend before to explore the city and the whole week afterwards to go and see more either in the city or around.

In case you are wondering whether the city is a worthy destination when travelling with children - below is a list of things to do and places to go I sent to someone recently. Hope it helps with your decision as well. In general the city is pretty green, there are several locations specially amenable to a visit with kids - so treat the list below as what it is: An incomplete listing of some of the most obvious locations that might be of interest collected by someone who knows a few parents and their children. Also in case you speak German make sure to check out one of the many guide books for Berlin with children available in local book stores - Dussmann and Hugendubel generally have the largest selection though Chatwins is my preferred one for anything about travelling.

In the city

In case of good weather:

• Tierpark Berlin - make sure you visit Tierpark (not Zoo) - it’s much larger and friendlier. See also images taken by Berlin Buzzwords fotographer Philipp, general images.
• There is a huge park in walking distance of Brandenburger Tor: Tiergarten for recreation after sight seeing.
• For swimming head over to either Wannsee or Schlachtensee
• For exploring a NSA listening station head west to Teufels-berg
• On warm evenings plan for some time at Maybachufer

For bad weather:

• If your kids like tech go to Technik Museum (it features one of the first computer (the one built by Zuse that is))
• If you kids like nature go to Naturkunde Museum
• If you are interested in science - make sure to be here for the long night of science (web page may need google translate unless you speak German.)
• For a city tour check out the following scribbles - they also include some interesting parts of the bus line 100 and 200

Close to the city:

If you have some more time to spend make sure you also explore the closer surroundings:

• 80km north: rent a canoo and explore Mecklenburg
• 200km north: visit Rügen, spend some time swimming, some time to see the amazing chalk cliffs, some time to see the isle by bike
• 250km south: go hiking or rafting in Elbsandsteingebirge
• 80km south: rent a canoo and explore the canals in Spreewald

Hope to see you in Berlin in June. If you need more information or recommendations don’t hesitate to ask.

The countdown started several weeks ago - finally in the past days the date for Berlin Buzzwords was announced, the call for submissions published. It’s exciting to see that the first talk is in already. Looking forward to yours.

Compared to last year there are two changes:

1. Submissions are no longer evaluated by Jan, Simon and myself only. Due to the large number of talks submitted last year we reached out for help to be able to split the task of reviewing talks.
2. Also the conference itself grew quite a bit in the past two years. As a result it now takes several full time positions to handle not only ticketing, hosting and software development, sponsorships, venue management, travel support, but also external communication and marketing. The team of newthinking grew quite a bit and is helping substantially with tasks that before were handled by Jan, Simon and myself exclusively to keep some of our time reserved for the fun part of schedule curation. Please make sure to include info@berlinbuzzwords.de if you have questions that need a quick answer.

We are looking forward to a successful community conference on all things scalable - be it search, NoSQL or data analytics. Don’t be afraid to submit highly technical talks - Berlin Buzzwords always has been a place for developers to discuss new technologies, algorithms and implementations.

If your community need more than just a day to meet - please do talk to us. We will be providing room for meetups on Wednesday after the conference. Those are handed out on a first come first serve basis.

If you are a local Berlin company and want to get Berlin Buzzwords into your offices, please talk to us - we are more than happy to get you in touch with one of the meetup organisers.

If you would like to co-locate trainings with Berlin Buzzwords - we are happy to co-promote you event. Talk to us to be included in our official schedule. In case you need any help organising your training, newthinking will be more than happy to provide their services for your event.

Looking forward to June: It’s amazing how large that event grew in the past two years - and almost scary to return back online after a flu and see how things unfolded magically.

Über einen Google+ Beitrag bin ich auf den Color IQ Test gestossen. Dabei geht es um das Erkennen von Farbunterschieden, in dem man die Farbkästchen per drag and drop entsprechend ihrer Farbwerte pro Reihe sortiert. Das erste und letzte Kästchen ist jeweils fest vorgegeben.

Ich hab es gleich mal selbst ausprobiert und bin überraschend auf einen Punktzahl von 4 gekommen. Weniger ist hier mehr und der Monitor ist kalibriert.

Es scheint als hätte ich bei 4 Farben in der letzten Reihe etwas daneben gelegen. Die Augen wurden ja auch schon genug von den ersten drei Reihen angestrengt.

Wer traut sich? Auf was kommt Ihr so?

Ich bin ja GRML-Fan, vor allem mag ich die schöne zsh- und screen Konfiguration. Was ich als angenehm empfinde, sind z.B. die farbigen Manpages. Und dank dieses Arch-Linux-Forum Posts, habe ich jetzt auch farbige Man-Pages.

Einfach folgendes in eure .bashrc/.zshrc etc eintragen:

# support colors in less export
LESS_TERMCAP_mb=$'E[01;31m'
export LESS_TERMCAP_md=$'E[01;31m'
export LESS_TERMCAP_me=$'E[0m'
export LESS_TERMCAP_se=$'E[0m'
export LESS_TERMCAP_so=$'E[01;44;33m'
export LESS_TERMCAP_ue=$'E[0m'
export LESS_TERMCAP_us=$'E[01;32m'

Ich mag ja den :hardcopy Befehl vom allroundtexteditor Vim, für Mac OS X auch als MacVim bekannt. Er veranlasst das direkte Drucken der geöffneten Datei bzw. des Fensterinhaltes an den Standarddrucker oder unter Mac OS X die Druckvorschau.

Hat man die Syntaxhervorhebung aktiviert, wird der Quellcode entsprechend des gewählten Farbschemas farbig und lesbarer dargestellt und auch so gedruckt.
So kann es aber passieren, dass ein Farbschema am Bildschirm gut aussieht, aber auf dem Ausdruck nicht so optimal ist.

Der folgende Screenshot zeigt so einen beispielhaften Ausdruck, wo die Farben der Syntaxhervorhebung für mich aber zu dunkel und unscheinbar sind:

Bei einem anderen Farbschema sieht der Ausdruck besser und von den Farben her kräftiger aus, nur leider gefallen mit die Farben dann nicht mehr im Editor selbst:

Und genau hier ist der Knackpunkt. Denn ich kann beim Vim keine Option finden, mit welcher ich für die Anzeige und den Druck verschieden Farbschemas festlegen kann.

Nach einer Recherche im Netz bin ich auf folgenden Tipp gestossen, bei dem für den Ausdruck kurz das Farbschema gewechselt wird.

Ich hab das ganze etwas an meine Bedürfnisse angepasst und folgendes in meine .vimrc mit aufgenommen:

" special hardcopy (print) color scheme
function UseMyHardcopyColors(args)
  if has("gui_running")
    " save current colors
    let save_bg=&bg
    let save_cs=g:colors_name
    " set new colors
    set bg=light
    colorscheme solarized
    " call hardcopy
    exec 'hardcopy '.a:args
    " reset colors
    exec 'set bg='.save_bg
    exec 'colorscheme '.save_cs
  else
    exec 'hardcopy '.a:args
  endif
endfunction>

" set new command Hardcopy
command! -nargs=* Hardcopy call UseMyHardcopyColors('<args>')

Es folgt eine kurze Erklärung, was der obige Code macht:

1. Es wird eine Funktion namens UseMyHardcopyColors angelegt.
2. Es erfolgt eine Prüfung, ob wir uns im Terminal oder der grafischen Vim Version befinden.
3. Es werden die aktuellen Farbeinstellungen gespeichert.
4. Es werden die gewünschten Farbeinstellungen für den Druck gesetzt.
5. Es wird der :hardcopy Befehl mit möglichen Argumenten ausgeführt.
6. Es werden die ursprünglichen Farbeinstellungen wieder gesetzt.
7. Als letztes wird ein neuer Befehl :Hardcopy (mit großem ‘H’ am Anfang) angelegt, welcher die eben angelegte Funktion aufruft.

Möchte ich nun einen Quelltext mit meinem für den Druck gewünschten Farbschema drucken, wähle ich den neuen :Hardcopy Befehl. Alternativ kann ich dann immer noch den vorhanden :hardcopy Befehl, welcher sich an dem aktuellen Farbschema orientiert, nehmen.

… wenn man an PC’s schraubt. Habe einen Rechner zusammengeschraubt.
Problem 1: nur ne alte PCI GraKa gehabt. Heutzutage kann man damit nicht mal mehr das BIOS anschauen. Selbst das Bootmenü ist nicht zu sehen.
Problem 2: Es macht einen Untschied in welchem PCI Slot diese GraKa steckt: im ’2.’ warf XEN nen Fehler…

Während eine BOOT-CD zusammengebastelt werden sollte, habe ich aus Neugier mal die GraKa in den anderen PCI Slotg gesteckt und habe uns damit vermutlich etliche Minuten Arbeit und Frust gespart.

Für den klassischen iPod nano (1. Generation) bietet Apple, wegen einer möglicherweise gefährlichen defekten Akkuserie, ein Ersatzprogramm an. Sicher ist sicher hatte ich mir gedacht und meine weißen iPod nano an Apple gesandt.

Apple hat festgestellt, dass es bei Modellen des iPod nano (1. Generation) in seltenen Fällen zu einer Überhitzung der Batterie kommen kann, was ein Sicherheitsrisiko darstellt.
(apple.de)

Mit einem weinenden und lachenden Auge ist nun das versprochene Ersatzgerät eingetroffen. Ein durch die Informationen im Netz nicht ganz unerwarteter aktueller iPod nano der 6. Generation. Die Farbe des neuen ist neutral in Silber gehalten.

Ich finde er ist nicht so schick und elegant wie der alte, aber bietet mir jetzt 4x mehr, also 8GB, Speicherplatz. Selbst musste ich mich auch erstmal auf der Produktseite informieren, was der denn jetzt so alles kann bzw. nicht mehr kann.

Praktischer, als so ein doch recht großer iPod touch, ist er für Unterwegs in der Hosentasche oder zum eventuellen Joggen aber auf alle Fälle.

Höre gerade den CRE 188 mit Stefan Urbach über seine (und die) Aktivitäten von Telecomix.
Es geht um seine Anfänge bei Telecomix, Netzsperren, Zensur, Antizensur, Revolutionsinfrastruktur, Nachrichtenfilter, psychische Zusammenbrüche und Depressionen, das lebensspendende Camp 2011 und vieles mehr. Wow. Total super, inspirierend. Danke!

Am 6. Mai 2012 findet wieder die Große Dresdner Motorradausfahrt statt. Mittlerweile die 18. GDMA und Treff- und Startpunkt wird wie letztes Jahr der Elbepark Parkplatz in Dresden sein.

Wie ich eben auf deren Webseite (Blogbeitrag) gelesen habe, gibt es jetzt auch einen offiziellen Trailer:

Ein Streckenentwurf ist dort auch schon zu finden. Die Ausfahrt scheint dieses Jahr mehr in die NNW (nordnordwest) Richtung oberhalb Dresdens durch Radebeul, Weinböhla, Großenhain, Radeburg und Moritzburg zu gehen.

Ein paar Eindrücke der vergangenen GDMAs, zumindest wo ich per Motorrad oder zu Fuß dabei war, kann man sich hier im Blog, unter dem Schlüsselwort GDMA, oder in einer kleinen Fotogalerie anschauen.

Hinweis: Der Link zu Fotogalerie muss in den alten Beiträgen zur GDMA noch korrigiert werden. So lange der Hinweis hier steht hatte ich noch keine Lust bzw. Zeit dazu.