Thursday, December 29, 2011

Hiking in Switzerland for hikers with knees symptoms

There are many among us, who are sportive and like hiking in the mountains, but are somewhat disabled because of having knee symptoms.

A good solution is to walk uphill and skip the downhill part of the hike. I tell you: Switzerland is the way to go. There are many cablecars and trains going up (and down) all the mountains here. With some good ideas there are many options of hard hikes without the need to go downhill. Since I relocated to Switzerland many of my friends asked for tours like this.

Following are some proposals. The tours are for sportive people who are able to hike for 3 to 5 hours and are able to go uphill several hundered meters altitude. The tours are selected in a way that you skip the downhill. That saves your bones. But: the tours are not for untrained people or beginners.

I would like to give you GPS tracks, cards, links an all other stuff right here. Unluckily my time is limited. If you really are interested call my up in skype (rainergrau) or sent me an email asking for more information to "rainer dot grau at zuehlke dot com".

Walensee hike, 3h hiking, 4.5h on tour
  • take the car to Murg at the border of the Walensee
  • park at the railway station
  • take to boat crossing the lake to Quinten
  • hike along the lake and then up to Walenstadtberg
  • take the bus to go down to Walenstadt
  • take the train back to Murg

View to Walensee hiking between Quinten and Walenstadtberg
Fronalpstock hike, 3h hike, 5h on tour
  • take the car via Schwyz and go on for about 4km direction Muothatal (not Ibergeregg and not Brunnen)
  • there is a rack railway station called "Stoos", park there and take the train up to Stoos, a small village half way up to the top of the mountains
  • Start the hike from Stoos up to the peak called Chlingenstock
  • hike along the rim from peak to peak to the last one in that row called Fronalpstock
  • take the cable car down to Stoos from Fronalpstock and then the rack railway back to the car
View from Fronalpstock down to Lake Vierwaldstätter and Brunnen

On the small path leading from Chlingenstock to Fronalpstock
Hike von Weggis up to Rigi Kaltbad, 4h hike, 5h on tour, 1400 meter altitude
  • take the car to the cable car station in Weggis on the north border of the lake Vierwaldstätter. Park there.
  • start your hike right here all the way up to Rigi Kaltbad via the so called Felsentor trail
  • terrific tour with fantastic views and very nice trails, some of them as single trails
  • at Rigi Kaltbad there are many restaurants and shops for recreation
  • take the cable car back down to your car

Eggberge hike, 4.5h hike, 5.5h on tour, 1200 meter altitude
  • Take the car to Flüelen (at the south end of the lake Vierwaldtstätter), follow the road to Altdort ond go on direction Klausenpass.
  • Passing Altdorf, 3km direction Klausenpass, already up the hill, a cable car station with a small parking area is on the left side called Brügg / Bürgelen.
  • Park your car there.
  • start your long hike up the hill direction Schwand / Eggberge
  • When you reach the plateau there are many small inns and taverns, original Swiss with original Swiss charming service
  • As well terrific views in an outstanding region
  • There are two different cable car stations on the plateau. Doesn't matter which to take, both lead down to the car park where your car is

Alternative to Eggberge, 4h hike, 5h on tour, only a few meters up and down
  • Park your car on the same location as above
  • This time take one of the cable cars up the hill. Each cable car has a middle station where you have to change to go up to hill. Go up to the hill to the plateau.
  • Start your hike there direction Klausenpass (east). This hike is just fun, all the way a bit up and down, never that hard, but about 4 hours to go.
  • The hike ends where the hiking path hits the road coming from Altdorf to Klausenpass 2km before you reach the top of the pass.
  • There is a bus station. Take the bus down to Altdorf. It goes about once an hour until about 6pm.
  • Next alternative: go by bike. The cable car will transport your MTB up the hill. Instead of hiking go for biking. The trail is easy, so the normal average bike will manage it.
  • With a bike you can of course go the last 2km to Klausenpass and of course cruise down the road to your car.


View from Schwand direction Klausenpass, only 3.5h left to hike
Rickenbach to Klewenalp hike, 3.5h - 5h hike, 4.5h - 6h on tour, 1000 meter altitude
  • Take the car to Beckenried on the south border of the Vierwaldstätter See, park at the cable car station
  • your hike starts here going up the hill either to Klewenalp or direction Stockhütte
  • Down from Klewenalp the cable car directly goes to your car park
  • From Stockhütte a different cable car goes down to Emmetten. There you have to change to the bus to go down to the cable car station in Beckenried

Hike from Schwyz to Mostelegg, 4.5h hike, 5.5h to go, 1100 meter altitude
  • Take the car and park in the center of the village Schwyz. Do not park at the railway station. The railway station is 2km down in the vally from Schwyz center
  • Start your hike in Schwyz direction Hagenegg or Mostelegg. Search for the yellow hiking signs in Schwyz. Best position to start and find the signs is at the central bus station. All hiking paths are signed there.
  • If you go for Hagenegg you end at a small mountain taverne with a nice terasse right under the massive of the so called "Kleiner Mythen" a very impressing peak there.
  • At this taverne you enjoy a teriffic view over lake Vierwaldtstätter
  • Starting at Hagenegg go direction Mostelegg
  • If you go for Mostelegg from Schwyz you are already there :)) (Mostelegg is in between Hagenegg and the target of the hike)
  • Go direction Mostelberg via Herrenboden
  • At Mostelberg there is a station with a few tavernes, child animation, a large slide.
  • Take the cable car down the hill to Sattel
  • In Sattel at the cable car station is a bus station going back to Schwyz (14 Minutes).
  • Between Mostelegg and Mostelberg, View down to Lake Lauerzer, Schwyz (we hiked by bike)
Take your time. Come to Switzerland and enjoy terrific hikes and trails. Conserve your knees and meniscus. You will love that - in the last century - the English railway constructors and rich Lords tried to construct a cable car or train on nearly each peak, hill and mountain.

You will love Switzerland. You will find a sometimes interesting and different view on hospitality in the taverns and small restaurants far away from the shopping centers. You will learn to love that as well... I love it.

Agile RE Blog 9: Erkenntnisse

Vier Thesen zum agilen Requirements Engineering
Als Zusammenfassung möchte ich hier vier Thesen zum agilen Requirements Engineering aufstellen, begründen und gerne diskutieren:
Erste These: Es gibt kein agiles Requirements Engineering für sich alleine. Alle Disziplinen sind gleich agil oder nicht agil, also Requirements Engineering, Design, Entwickeln, Testen, die Architektur, Management in der Form des Lean management, einfach alles.
Zweite These: Der möglich Grad an Agilität hängt von Randbedingungen und Kultur der Organisation ab. Das bedeutet, dass bei Vorliegen bestimmter Randbedingungen die Vorteile der Agilität oder des Lean Thinking durch die Nachteile überschattet werden.
Dritte These: Wenn eine Organisation, oder ein Teil einer Organisation agil / lean ist, wird dieser Teil erheblich effektiver und effizienter, also produktiver, arbeiten als wenn er Dokumenten-lastig und Informationsgetrieben arbeitet – vorausgesetzt natürlich die Randbedingungen lassen das zu (These zwei).
Vierte These: Es existieren zwei Ebenen des Requirements Engineerings in Unternehmen: das operative Requirements Engineering auf Projektebene und das taktische Requirements Engineering auf Produktebene. Das operative Requirements Engineering auf Projektebene kann immer agil Arbeiten ohne dass zwingend die Produktebene agil ist. Das Unternehmen muss jedoch zwingend auf Projektebene agile arbeiten, wenn es auf Produktebene ebenfalls agil arbeiten will.
(Anmerkung): In den Expertengemeinden von Requirements Engineers und Business Analysten gibt es Religionskriege, was eigentlich ein Requirements Engineer ist und was ein Business Analyst. Vielleicht könnten diese Kontextebenen verwendet werden, um die Berufsbilder zu prägen... das ist nur ein Vorschlag (Ende Anmerkung)

Ich denke die erste These ist aus dem bisherigen Talk deutlich geworden. Agilität bedeutet Effizienz in der Wissensarbeit und das bedingt ein anderes Arbeitsmodell, das zwingend alle Disziplinen mit einbezieht.
Die zweite These wird anhand der Extreme klar. Um komplett agil zu arbeiten, über alle Ebenen hinweg, operativ im Projekt, taktisch auf Produktebene und eventuell sogar strategisch, sind permanent zusammen arbeitende Teams notwendig. Diese müssen gut miteinander verzahnt arbeiten und dies sehr diszipliniert und selbst organisiert. Das Management muss permanent in die Teams, in die Zusammenarbeit der Teams und in das Thema Selbstdisziplin investieren. Selbstdisziplin wiederum ist eine Eigenschaft eines im Kontext gut ausgebildeten und motivierten Mitarbeiters.
Sind wir in Organisationen, in denen ein Produkt einfach einmal zwei, drei Jahre liegen bleibt, so hat ein agiles Vorgehen ein Problem zu überwinden. Typisch stirbt ein ruhendes Produkt, wenn das Team sich aufgelöst hat. Eine weitere wichtige Aufgabe des Managements muss es somit sein beständig eine verständliche Vision der Zukunft am Leben zu halten und hoch motivierte Teams beständig in einer Selbsterneuerung zu halten und jedes Produkt beständig zu pflegen. Alternativ kann auch vorab in der Produktstrategie damit umgegangen werden. Eventuell ist es günstiger das Wissen einen Team bewusst zu verlieren und später, nach n Jahren, wieder aufzubauen, als permanent in ein Team zu investieren, nur damit das Wissen (ungenutzt) vorhanden bleibt. Keine leichte Aufgabe hier richtig zu entscheiden. Bei bestimmten Randbedingungen oder bei einer vorhandenen Historie ist agiles / lean Handeln eventuell einfach nicht möglich.
Tatsache ist: Nur in seltenen Fällen bewältigen es bestehende große Organisation (500, 1000, … Mitarbeiter) die Veränderung, den Change in dieses Arbeitsmodell durchzuführen und komplett agil zu werden, um Ihre Produkte oder Services zu erstellen.
Einschränkende Randbedingungen in Organisationen
Die bestehende Kultur und Struktur eines Unternehmens enthalten einschränkende Randbedingungen, die bestimmen ob ein agiles Vorgehen möglich sein kann und Erfolge bringen wird. Typische Randbedingungen sind:
  • Vorgabe der Ziele Top Down ohne Visionsbildung und Buy-In von Peers, d.h. ein klassischer Top-Down Strategieprozess ohne Einbindung von Kunden und Wissensträgern im eigenen Unternehmen.
  • Das Fabrikbild der Produktion als Leitbild um Wissensarbeit zu gestalten. Dies einhergehend mit einer Fehlinterpretation, was durch Standardisierung und Spezialisierung möglich ist.
  • Unflexible Budgetierung
  • Das Wissen auf taktischer Ebene ist organisatorisch und personell völlig getrennt vom Wissen auf operativer Ebene (der viel besprochene Bruch zwischen Business und IT)
  • Der Kunde (auch der interne) ist ein externer und nur punktuell einbezogener Stakeholder
  • Eine sich zu schnell und beständig aus unternehmens- oder personalpolitischen Gründen verändernde Organisation mit Wechsel von Wissensträgern.
Agiles Arbeiten bedingt es auch die Organisation zu einem großen Teil an agilen und lean Prinzipien auszurichten. Der Poolgedanke von Spezialisten im Resourcing, wie der Pool an Requirements Engineers oder Architekten ist ein Widerspruch zum agilen Arbeiten an sich. Die Work Force im Unternehmen muss nach anderen Kriterien aufgebaut, geschult und auf Projekte verteilt werden. Projekte sind unterschiedlich zu schneiden und zu etablieren. Das ist ein erheblicher Wandel für klassische Unternehmen.
Sinnvolles Justieren des "Agilitätsgrades"
Ich habe in dem Talk die beiden Extreme vorgestellt, die komplett Dokumenten-lastige, ineffiziente aber sichere und standardisierte - fast Fabrik hafte Form auf der einen Seite und die komplett agile, hoch effiziente, aber auch mit Risiken für die Gesamtorganisation behaftete Form der Zusammenarbeit.
Ich denke jedem Menschen mit einem gesunden Menschenverstand ist klar, dass die Extreme in Reinform nur in wenigen Fällen vorhanden sein werden. Die Extreme werden an den Randbedingungen scheitern. Also werden sich reale Konstrukte irgendwo in der Mitte befinden. Wenn wir über agiles Requirements Engineering reden, dann ist es die Aufgabe des Managements sich bewusst zwischen diesen beiden Extremen zu positionieren (siehe folgende Abbildung). Es ist die Aufgabe zu entscheiden, wie auf der operativen Projektebene und auf der taktischen Produktebene gearbeitet werden soll.

Abbildung 11: Positionieren Sie Ihre Organisation bewusst zwischen den Extremen
Haben Sie sich als Vertreter oder Mitarbeiter eines Unternehmens schon einmal gefragt, WO Ihr Unternehmen zwischen den beiden Extremen steht? Nehmen Sie sich doch an der Stelle einmal ein paar Sekunden Zeit und überlegen, wo Sie ihr Unternehmen, das Sie lenken oder in dem Sie arbeiten, positionieren würden.
Haben Sie sich schon einmal gefragt WARUM Ihr Unternehmen auf dieser Position steht? Ist das Zufall, Strategie, Firmenkultur oder ein Chef der sagt "so geht's"? Was sind die Gründe?
...und vor allem dieses: Ist in Ihrem Unternehmen die Kultur überall identisch oder muss eventuell pro Bereich des Unternehmens eine andere Position zwischen Dokumentation-getriebenen Management und Wissensmanagement markiert werden?
...und immer hinterfragen: Was ist das Ziel, das mit Agilität und Lean Management verfolgt wird
Ich persönlich kenne keine komplexe Organisation mit Historie, die den Wandel zu agiler Arbeitsweise komplett durchgeführt hat, also auch ein agiles Requirements Engineering in allen Ebenen und in allen Teilen erreicht hätte. Meiner persönlichen Meinung ist das auch nicht das Ziel. Das Ziel einer Organisation sollte sein zu prüfen, ob das agile Arbeitsmodell für diesen oder jenen Teil geeignet ist und die Produktivität steigert. Ziel muss es sein mehr Effizienz bei mindestens gleicher Effektivität zu erreichen.
Ich behaupte mehr Agilität ist in vielen Teilen von Organisationen möglich und ein erheblicher Schritt bezüglich Effizienz und Effektivität. In den Worten des Business ausgedrückt ist der Gewinn „Time 2 Market“ und „Flexibilität“, also das RICHTIGE Produkt zum RICHTIGEN Zeitpunkt.

Begründung der vier Thesen

Agile RE Blog 8: Von der Projektebene zur Produktebene

Bisher habe ich mich in meinem Gedanken vorwiegend auf die Ebene des Projekts bezogen. Es ist selbstverständlich, dass diese Aussagen im Sinngehalt identisch auf der Produktebene gelten.
In der folgenden Abbildung sind zwei verschieden Kontextebenen aufgeführt: Die Projektebene und die Produktebene. Projekt- und Produktebene sind jeweils ein eigener Kontext in einer Organisation.

Kontext Ebenen des RE: Produkt und Projekt
 Zwei Kontextebenen: Projekt und Produkt

Wir erinnern uns, dass gemäss der dritten Eigenschaft von Wissen, dieses nur in einem Kontext gültig ist. Das hat zur Folge, dass diese beiden Kontextebene voneinander unabhängige aber eng verknüpfte Teams in der Organisationseinheit darstellen. Das ist genau eine der Schwierigkeiten, die ich in Unternehmen erkenne. Es wird verkannt, dass in beiden Kontextebenen zwar zu einem grossen Teil die identischen Informationen vorhanden sind, jedoch ein anderes Wissen aus diesen Informationen gewonnen und benötigt wird. Jedes Team benötigt sein eigenes Wissen um die Produkteigenschaften und den Prozess.
Das im Idealfall beständig zusammen arbeitende Projektteam hat hierbei eine gute Chance den Kontext zu nützen und Effektivität und Effizienz herauszuarbeiten. Das bedeutet auf der operativen Ebene der Produktentwicklung, in den Projekten nämlich, ist agiles RE möglich und sinnvoll und hilft das „GUTE PRODUKT“ mit den „RICHTIGEN EIGENSCHAFTEN“ zu erschaffen – vorausgesetzt es wird so im Produktkontext eingebettet, dass dieses dem Projekt auch möglich ist. Schlagworte sind: On-Site Kunde, permanente - oder zumindest ausreichende - Anwesenheit der Fachperson und so weiter.

Die Kontextebene Produkt als Sorgenkind des agilen Requirements Engineerings

Im Kontext des Produkts, auf der taktischen Ebene ist dies deutlich schwerer. Die dort wirkenden Personen sind typisch nicht beständig zusammen. Der Aufbau eines gemeinsamen Wissens ist deutlich erschwert. Jeder der in diesem Kontext arbeitet, sollte sich einmal fragen wie viel Zeit pro Woche er mit seinen Peers in Kommunikation verbringt und wie viel Zeit er alleine für sich arbeitet. Was im Projekt offensichtlich ist, nämlich das gemeinsame Lösen eines komplexen Problems durch Aufbau von Wissen, das Schließen von Wissenslücken und beständige Zusammenarbeit, ist auf der Produktebene deutlich erschwert. Hier ist ein Wechsel der Arbeitsform in Richtung Agilität deutlich schwerer und noch viel enger mit Firmenkultur verbunden als auf Projektebene.

Ursachen und Konflikte
Hinzu kommt, dass die Protagonisten auf der Produktebene typisch – und ganz besonders betroffen ist davon das mittlere Management – keinen Vorteil in der agilen Arbeitsweise erkennen. Das liegt oft an der persönlichen Situation des mittleren Managements. Diese ist typisch geprägt durch Erfolgsdruck, Budgetknappheit, Arbeit an der eigenen Karriere und Überlast. Unter solchen Umständen wird kein neues Arbeitsmodell ausprobiert, da dies weitere Arbeitslast und ein nicht kalkulierbares Risiko für die eigene Karriere bedeuten kann. Nur über den Schutz eines Top Management ist dies möglich.
Wichtig ist zu erkennen, dass einzelne Personen zudem gleichzeitig in beide Kontextebenen eingebunden sind. Das ist die ideale Form um Wissen zwischen den Teams zu transportieren. Diese Personen stehen allerdings nun in einem Konflikt, wenn sie agil in dem einen Kontext arbeiten und Dokumenten-getrieben im Produktkontext.
Gravierender ist, dass diese – ich nenne es jetzt Kultur – auf der Produktebene auch ein agiles Arbeiten im Kontext des Projekts erfolgreich verhindern kann, zum Beispiel weil bestimmte Voraussetzungen nicht erfüllt werden, wie etwa Feedback durch einen On-Site Kunden.

Willkommen im realen Leben

Nun gut, wie bereits gesagt besitzt dies rein strategisch auf oberster Organisationsstufe (leider) keine Bedeutung solange die Konkurrenz identisch arbeitet. Die Werte für Effektivität und Effizienz, also für Produktivität, werden bei sich ähnlichen Organisationen ähnlich groß oder klein sei, die damit ja auch eine ähnliche Kultur und Historie besitzen und sich typisch in einer Domäne gleichzeitig entwickelt haben. Meine persönliche Meinung: Die "new kids on the block" werden kommen und in bestehende Domänen mit einer anderen Kultur und eventuell abweichendem Geschäftsmodell einbrechen und den bestehenden Organisationen das Leben schwer bis unmöglich machen. Ist das eventuell eine neue Sicht auf den Erfolg von Unternehmen wie Apple, Google, Facebook, Doodle, ...
Interessant ist übrigens auch noch eine Messung des Instituts für Technologie in Blekinge im Rahmen des Requirements Abstraction Models dass auf Produktebene weniger als 40% des gesamten Produktwissens benötigt wird, um auf dieser Ebene erfolgreich arbeiten zu können. Es werden diese 40% vom Team jedoch in der Form von taktischem Wissens benötigt und nicht als operatives Lösungswissen wie im Projekt.
(Referenz: T. Gorschek and C. Wohlin, "Requirements Abstraction Model", Requirements Engineering Journal, Vol. 11, No. 1, pp. 79-101, 2006, zu finden unter http://gorschek.com/doc/publications.html, wie viele weitere interessante Informationen)

Arbeiten auf Basis von Visionen im Sinne von Zukunftsbildern

Meine persönliche Feststellung: Agiles Arbeiten auf der Produktebene – und damit auch agiles Requirements Engineering auf dieser Ebene – stellt eine Herausforderung dar.

Unternehmen, die darin erfolgreich sind arbeiten typisch mit einem Produktportfolio und einer Produkt Roadmap, welche mit Visionen zu Produkten arbeitet. Eine Vision sollte wie folgt sein: Ein einfach zu verstehendes und einprägsames, ideal mit Hilfe oder Einbezug von Prototypen oder Exemplaren beschriebenes, Zukunftsbild eines Produktes. Visionen sind für verschiedene Zeitpunkte in der Zukunft (3 Monate, 6 Monate, ein Jahr, 3 Jahre) mit dem Team auf der Produktebene aufzubauen und beständig zu überarbeiten. Ein zeitlich nahes Zukunftsbild kann und sollte hierbei sehr konkret sein, die 3 Jahre Vision ist bestimmt abstrakter und weniger detailliert.

Das Überarbeiten aller Visionen erfolgt mit den typischen Stakeholdern wie Marketing, Forschung, Entwicklung, Kunden, Kundendienst, jdeoch agil, permanent, in einem Kontext mit gemeinsam erarbeiteten und gepflegten Wissen.

Monday, December 12, 2011

Agile RE Blog 7: Zwei Gedankenexperimente: Reines Wissensmanagement versus total Dokumenten-lastig

Aus den bisherigen Betrachtungen können wir wesentliche Schlüsse ziehen für eine Veränderung in Richtung Agilität. Zwei Gedankenexperimente möchte ich dazu plakativ aufzeigen in Form von zwei Extremen.
Extrem 1: das Dokument-lastige Arbeitsmodell
Stellen Sie sich vor: Ein Unternehmen hat sich entschieden das komplette Wissen in Form von Informationen in Dokumentation zu bewahren. Das gilt für Prozesswissen als auch für Produktwissen. Eine entsprechende Q-Sicherung prüft die Vollständigkeit der abgelegten Informationen in beiden Bereichen. Beginnend beim Strategieprozess auf Produktebene über den Aufbau des Produktportfolios bis hin zur Definition und Ausführung von Projekten ist das komplette Wissen in Dokumenten zu bewahren.
Extrem 2: Das Team orientierte und agile Arbeitsmodell in Extremform
Wir verzichten auf jede permanente Dokumentation. Das Team setzt alleine temporäre Dokumentation für das Treiben des Prozesses ein (wohlgemerkt Produkt bezogene Dokumentation entsteht sehr wohl, etwa ein UML-Modell des Produkts, Handbücher oder – wenn von FDA gefordert – eine Traceability Matrix). Diese Prozessdokumentation hilft dem Team in der täglichen Arbeit, also Kärtchen am Scrum oder Kanban Board oder was auch immer das Team entscheidet zu nehmen. Das komplette Prozess- und möglichst viele Details des Produktwissens sind in den Köpfen der Teams und werden dort permanent weiter entwickelt. Dieses Arbeitsmodell ist natürlich hoch effizient in einem lokalen und kleinen Team, das beständig zusammen arbeitet.
Vorteile des Dokument-lastigen Arbeitsmodells
Zu jeder Zeit kann ein Mitarbeiter ersetzt werden (das hat doch Charme für das Management, oder?). Über die Dokumentation und geeignete Trainings erarbeitet sich ein neuer Mitarbeiter das Prozesswissen und das Produktwissen, um anschließend produktiv, den Standards folgend, tätig zu werden.
Abbildung 8: das Dokument-lastige Arbeitsmodell
Ein Vorteil besteht, wenn ein Produkt nicht permanent weiter entwickelt wird. Es kann zum Beispiel 2 Jahre unverändert verkauft oder eingesetzt werden. Niemand entwickelt das Produkt weiter, es wird lediglich „produziert“. Das Team, welches das Produkt entwickelt, ist also nicht mehr existent. Wird dann wieder ein Projekt aufgesetzt, wenn eine neue Version des Produkts zu erstellen ist, so sind die Informationen vorhanden, um ein neues Projektteam aufsetzen zu können.
Ein weiterer Vorteil (so zumindest oft zitiert) ist, dass ein beliebiger Teil der Fertigungskette Offshore vergebbar ist, es ist „einfach“ die Prozess- und die Produktdokumentation offshore zu transportieren. Das entspricht den oft vorgetragenen Argumenten der globalen und verteilten Teams, Flexibilität und "atmende Work Force". Ich denke dass dieser Vorteil erfreulicher Weise mittlerweile aus Kosten- und Effizienzgründen differenziert diskutiert wird.
Das Arbeitsmodell verlangt nach einer hohen Standardisierung des Arbeitsmodells. Das gilt für die Rolle des Requirements Engineers wie für jede andere Rolle auch. Sie ist klar und eindeutig mit Tätigkeiten beschrieben. Es ist klar, welche Eingangsdokumente ein Requirements Engineer bekommt und welche Ergebnisse er in Form von Dokumentation erzeugt. Es ist klar, wie er über Schulungen ausgebildet werden kann. Das Jobprofil ist klar und kann dem HRM kommuniziert werden. Oft gibt es in großen Unternehmen Pools von Jobfamilien wie den Pool an Requirements Engineers.
Nachteile des Dokument-lastigen Arbeitsmodells
Diese Vorgehensweise geht offensichtlich völlig zu Lasten der Effizienz. Die Informationen werden – zumindest auf der Prozessseite – von Personen basierend auf Basis rein expliziten Wissens dokumentiert. Dieser dokumentierte Stand der Arbeitstechnik ist zudem strukturell immer veraltet, da das Erlernen, Dokumentieren, Freigeben, Lehren und Anwenden (einschließlich eventuell einer unterstützenden Tool Chain) nun einmal Zeit zur Umsetzung benötigt und damit dem „state of the art“ hinterher hinkt.
Auf implizites Wissen eines Teams wird kein Wert gelegt, es wird in dem Extrem bewusst darauf verzichtet. Das gilt für das Team, das nach einem Projekt zerschlagen und wieder neu aufgesetzt wird. Jedes Projektteam fängt dann praktisch von Null an und muss durch Dokumentenstudium lernen, was das Vorgängerteam hinterlassen hat. Dafür kann es natürlich zu einem beliebigen Zeitpunkt installiert werden. Dieses Prinzip gilt auf Teamebene und ebenso für die Zusammenarbeit der einzelnen Disziplinen im Projekt. Der Business Analyst schiebt Dokumente zum RE, der RE zum Testmanager, weiter zum Architekten und zum Designer und so weiter. Zwischen allen diesen Personen gelten die oben besprochen Punkte der Problemlösung, des Erarbeitens impliziten Wissens und dem Aufwand Wissenslücken schließen zu müssen über Lernen. Das vollkommene Extrem wäre erreicht, wenn die Personen ein direktes Kommunikationsverbot hätten und alleine über den Austausch von Dokumentation interagieren dürften.
Die Spezialisierung der Personen auf Rollen ist ebenfalls zweischneidig. Genauso, wie ein Requirements Engineer gezielt ausgebildet werden kann, ist er aber auch nur gezielt einsetzbar. Im härtesten Fall taugt er nur für das Requirements Engineering in einem Projekt. Ich persönlich habe einmal ein konkretes Projekt in einem Großunternehmen betreut, in dem 30% einer RE-Kapazität eingesetzt wurde – in Rolle und als Person. Dazu wurde dem Projekt ein Mitarbeiter zugeordnet, der 1.5 Tage die Woche anwesend war. Ein halber Tag davon wurde im wöchentlichen Projektmeeting benötigt. Der Wirkungsgrad dieses Mitarbeiters tendierte gegen Null  – obwohl er gut war als RE. Das Projekt hat nach einem Monat auf seine Mitarbeit verzichtet und der Projektleiter hat die Rolle RE übernommen. Über die Gestaltung eines interessanten, vielseitigen und motivierenden Arbeitsplatzes für solch einen in einem Schema eingezwängten Wissensarbeiter möchte ich hier gar nicht philosophieren.
Kann das Modell funktionieren? Ja, es kann, die Praxis beweist es. Ich kenne Unternehmen, die zu diesem Extrem tendieren und erfolgreich sind. Unternehmen die so operieren müssen diese Ineffizienz lediglich wirtschaftlicher betreiben als ihre wohl ebenso ineffizienten Konkurrenten.
Konsequenzen eines agilen Arbeitsmodells in Extremform
Ein agiles Arbeitsmodell in Extremform hat deutliche Konsequenzen für die Arbeitsorganisation.  In einem Team müssen alle Fähigkeiten vorhanden sein und jeder im Team muss mehr als eine Disziplin beherrschen.  Das hat Konsequenzen für die Rolle Requirements Engineering, des Testmanagers, des Architekten und alle anderen Rollen. Es gibt sie nicht mehr, den Mister Requirements Engineer, den Chefarchitekten. Die Berufsbilder in Reinform sind verschwunden, die benötigten Disziplinen müssen jedoch vom Team professionell und ausgewogen beherrscht werden.
Jeder Entwickler muss zum Beispiel zu einem gewissen Teil das Requirements Engineering beherrschen, sonst wäre er nicht in der Lage eine User Story zu zerlegen und umzusetzen. Manche sind natürlich „besser“ als andere und ziehen sich deswegen die Tasks zu sich, welche die höhere Expertise einfordern.
Ein Profi im Requirements Engineering muss der unbedingt der Product Owner sein (ich verwende hier einmal den Scrum Jargon) oder allgemeiner gesagt: der Vertreters des Business oder des Fachbereichs oder des Kunden – ja nach Kontext des Projekts die Person, die sich für den fachlichen Inhalt des Produkts verantwortlich fühlt und diese Verantwortung nach innen und außen wahrnimmt.  Hier sehen wir auch die typische Schwierigkeit: Er muss viel im Projektteam vorhanden sein. Er muss viel außerhalb des Projektteam aktiv sein bei den Stakeholdern. Er ist Teil des gemeinsamen Problemlösungsprozesses, des Schließens von Wissenslücken und dem permanenten begleitenden Lernen. Er ist Träger von wesentlichem implizitem Wissen.
Abbildung 9: Das Team orientierte und agile Arbeitsmodell
Vorteile des Team-orientierten und agilen Arbeitsmodells
Ganz eindeutig ist die hohe Effektivität bei gleichzeitig hoher Effizienz der Vorteil eines agilen Teams. Das gemeinsam getragene Wissen vermindert die Anzahl an Defekten, da Fehlinterpretationen durch permanentes Feedback sofort offensichtlich werden und keine Defekte daraus entstehen beziehungsweise  diese sofort offensichtlich werden und adressiert werden können.
Nehmen wir an die Personen, welche das Requirements Engineering vor allem treiben, einschließlich Product Owner, bekommen beständig Feedback von Business und Stakeholdern. Dies ist der geeignete Vermittlungsweg, um eine hohe Zielerreichung der Wünsche des Business zu erreichen (Effektivität). Das im Agilen möglichst konstante Projektteam kann das Prozess- und Produktwissen aufbauen, optimieren und anwenden und erreicht durch diesen beständigen Lernprozess eine hohe Effizienz. Insgesamt bedeutet das in Summe eine individuelle und eine Team-orientierte Produktivitätssteigerung und damit Wettbewerbsvorteil.
Ein weiterer Vorteil ist das Vermeiden von Spezialistentum. Generalist wäre das falsche Wort, Mitarbeiter in agilen Projekten beherrschen jedoch typisch ein breiteres Skillset als Mitarbeiter in nach Rollen organisierten Unternehmen.
Wenn wir das so hören, dann fragen wir uns, warum arbeiten wir überhaupt noch auf eine andere Art und Weise. Gibt es auch Nachteile dieser Arbeitsorganisation. Welche sind diese?
Nachteile des Team-orientierten und agilen Arbeitsmodells
Ein Nachteil ist, dass bei einer in der Extremform gefahrenen agilen Arbeitsform typisch das Produkt stirbt, wenn das Projektteam zerfällt. Das Unternehmen muss seine Teams „lebendig“ halten, um das Produkt lebendig zu halten. Es ist ein permanenter Invest in die Teams notwendig in Form von Vision aufzeigen, Motivation erhalten, Skills aufbauen, damit diese Zusammenhalt gewahrt bleibt und die richtigen Skills vorhanden sind.
Eine wichtige Frage ist zum Beispiel:  Was ist eine gute Mischung an Disziplinen-Verständnis bei einem Projektmitarbeiter, der typisch das Requirements Engineering in einem agilen Projekt vorantreibt, also etwa ein Product Owner. Das durchaus reale Problem für ein Unternehmen lautet allgemein: Wie finde ich diesen multidisziplinären Mitarbeiter auf dem Markt und wie entwickle ich ihn weiter, wie beurteile ich seine Leistung. Dieser Typus Mitarbeiter ist „schwieriger“ zu „verwalten“ und zu „entwickeln“ als ein Spezialist.
Ein weiterer Nachteil besteht, wenn ein Produkt nicht beständig entwickelt werden muss, eine „Pause“ in der Entwicklung besteht. Wenn wir an ein Großunternehmen denken mit einer Serviceplattform wie eine Großbank oder eine Versicherung in der mehrere hundert Anwendungen diese Service-Plattform bereit stellen, so wird nicht an allen Anwendungen permanent gearbeitet werden. Tatsächlich wird nur ein Bruchteil der Anwendungen zu einem Zeitraum parallel angefasst und weiter entwickelt. Auch ist der Begriff „Produkt“ in diesen Unternehmen nicht trivial zu definieren. Das geeignete Identifizieren von Produkten und das geeignete Identifizieren von Projekten, also Produkt- und Projektportfoliomanagement sind in diesem Kontext per se komplex und anspruchsvoll und weder klassisch noch agil trivial umzusetzen.
Nicht ein Nachteil, aber als Gefahr besteht, dass sich eine komplett agil aufgebaute Organisation, in der sich die einzelnen Zellen selbst organisieren und optimieren, sich vollkommen der Standardisierung zum Beispiel in Richtung Technologien, Architektur und Tooleinsatz entzieht und aufgrund lokaler Optimierung (Gärtchendenken) sogar schädlich für die Gesamtorganisation wirken. Ich behaupte hier, ohne den Beweis zu liefern oder liefern zu können, dass dies nur eine bedingt vorhandene Gefahr ist. Nach meinen Erfahrungen unterwerfen sich WRKLICH agile Organisationen einer freiwilligen strengen gelebten Selbstdisziplin. Scheinagilen Organisationen mit ausgeprägtem Gärtchendenken fehlt Transparenz als Grundprinzip und damit die Kultur der gesunden Selbstdisziplin.

Sunday, December 4, 2011

Agile RE Blog 6: Wissen hat nur in einem Kontext Bedeutung

In meinem letzten Blog über RE im agilen Kontext habe ich darauf fokussiert, dass Anwenden von Wissen ein wichtiger Schritt in einem Lernprozess ist. Dieser Lernprozess ist zudem abhängig von dem Kontext, in dem sich eine Person befindet. Durch Interaktion in dem Kontext lernt eine Person - und natürlich alle anderen Personen im identischen Kontext.
Das Anwenden des Wissens im Kontext fördert das Erkennen und Schließen weiterer Wissenslücken, die nur durch den Aufbau von neuem Wissen zu erkennen sind – ebenfalls wieder durch Lernen in einer Lerngruppe in einem Kontext. Implizit folgt daraus, dass Wissen nur eine Bedeutung in einem sozialen Kontext hat.
Nun sind in einem Unternehmen unterschiedliche Kontextebenen vorhanden, wie schon am Anfang der Blog Serie dargestellt. Es gibt den Kontext der Projektarbeit, den Kontext des Produkts, den Kontext ein Produkt Portfolio zu managen, den Kontext die Strategie eines Unternehmens zu definieren.


Abbildung 7: Wissensarbeit bedeutet in einem Kontext vorhandene Wissenslücken schließen
Somit existieren Im Unternehmen unterschiedliche „Lerngruppen“, die Wissensarbeit betreiben. Das sind genau die Teams, die in den verschiedenen Kontextebenen arbeiten: die Projektteams, das Steering Committee, welches über die Produkt Roadmap auf taktischer Ebene entscheidet, das Management, welches sich mit der Strategie befasst, eine R&D und weitere.
Versuchen Sie doch einmal die Kontextebenen und damit auch die Lerngruppen in Ihrem Unternehmen zu identifizieren und den Kontext, in dem diese arbeiten.  Interessant ist auch, dass viele Personen im Unternehmen in mehr als einem Kontext tätig sind. Das kann zu Konflikten für diese Person führen, da eventuell die Ziele und Arbeitstechniken (auch die Kultur) in den unterschiedlichen Kontextebenen voneinander abweichen kann.
Zusammenfassung bezüglich Wissensmanagement
An dieser Stelle ist eine Zusammenfassung wichtig. Die wichtigsten Punkte bisher sind:
  • Dokumentation transportiert kein Wissen, sondern lediglich Informationen.
  • Um Informationen in Wissen zu wandeln, muss es im Kopf von Teammitgliedern sein und von dort aus angewendet werden.
  • Es ist unmöglich alles benötigte Wissen in Form von Informationen in Dokumenten abzulegen.
  •  Fehlendes Wissen wird durch Lernen und Füllen von Wissenslücken in einem gemeinsamen Kontext erarbeitet.
  •  Das Füllen von Wissenslücken ist ein iterativer Vorgang, da nur neu erworbenes Wissen weitere vorhandene Wissenslücken sichtbar macht, die es wiederum zu schließen gilt.
  •  Für das Requirements Engineering sind die zwei Kontextebenen „das Projekt“ und „das Produkt“ extrem wichtig.
Diese Aussagen gelten zudem nicht nur für die Disziplin des Requirements Engineering. Sie gelten ebenso für alle weitere Disziplinen und das Zusammenspiel der Disziplinen.