Agile RE Blog 2: Das Ökosystem des Projekts

Im letzten Blog haben wir den Kontext aufgebaut und das Requirements Engineering ist in dem Kontext positioniert. Es ist geklärt, welche Aufgaben Requirements Engineering hat: Taktisch die RICHTIGEN Produkt zum RICHTIGEN Zeitpunkt für Markt definieren im Produktportfolio und die detaillierte wirtschaftliche Ausarbeitung der Eigenschaften des RICHTIGEN Produkts – unter Beachten der organisatorischen und technischen Randbedingungen – in Projekten als operative Ebene der Organisation.

Nun ist noch in keinem Satz das Wort „AGIL“ vorgekommen. Es wird also Zeit sich diesem Punkt zu nähern.

Dazu möchte ich die kleinere Einheit an, das Projekt unter die Lupe nehmen. Ich gehe davon aus, dass es das Produkt schon gibt, was wohl der Regelfall sein wird. Das Projekt dient also der Überführung des bestehenden Zustandes des Produkts in den neuen Zustand des zu DIESEM ZEITPUNKT RICHTIGEN Produkts.

Bei einem Projekt handelt es sich um ein zeitlich begrenztem Ökosystem, das ein mehr oder weniger klar definiertes Ziel (eine Vision) erreichen will (in die Realität umsetzen will). Umgangssprachlich bedeutet dies: Ein Team von Leuten arbeitet an einem Produkt, welches einer oder mehreren Benutzergruppen anschließend zur Nutzung übergeben wird. Das Team, welches das Produkt erstellt, ist in einem sozialen Kontext in die Umgebung eingebunden, in der das Produkt geschaffen wird. Dieser soziale Kontext hat eine enge Wechselwirkung auf das Team und somit auch auf das Ergebnis des Teams, also dem Produkt. Mit einem Wort, das Team und die Einbettung des Teams im Kontext der Organisation (mit Kunden, mit Abteilungen wie Marketing oder Operations oder dem Chef selbst) spielt eine große Rolle für eine erfolgreiche Projektarbeit.

Nun ist es eine Aufgabe des Requirements Engineering diesen Kontext zu untersuchen und die Wechselwirkungen zwischen dem zu schaffenden Produkt und dem Kontext herauszufinden. Das hilft und die RICHTIGEN Eigenschaften im Detail zu erkennen und – über Beachten der Randbedingungen – den TCO zu erhöhen. Im Requirements Engineering werden dazu Stakeholder abgeholt, andere Informationsquellen angezapft und alles miteinander verknüpft und vernetzt und es muss damit umgegangen werden, dass sich das Ziel des Projekts (die Vision) während dem Arbeiten verändert.

Nach allgemeiner Auffassung der Forschung [Dir2011] entsprechen diese Eigenschaften (viele Stakeholder, viele Informationsquellen, viele Abhängigkeiten, moving Target) der Definition eines komplexen Problems. Abstrakt formuliert beschäftigt sich ein Projekt mit dem Lösen einer komplexen Problemstellung (siehe Abbildung 3). Dazu kann nach allgemein annerkannter Auffassung der Forschung [Dir2011] kein mechanisches Fertigungsverfahren eingesetzt werden, wie zum Beispiel zum Herstellen von Hamburgern (Brötchen, Hackfleisch, Majo, Ketchup, Gurke, Salat in definierten Arbeitsschritten zusammen pappen). Um eine komplexe Problemstellung zu lösen bedarf es Wissensarbeiter, die in einer möglichst effizienten Art und Weise zusammenarbeiten und mit Wissen arbeiten beziehungsweise sich Wissen erarbeiten.

 

Abbildung 3: Produkte über Projekte erstellen und verbessern bedeutet das Lösen eines komplexen Problems

Um das Produkt von einem Zustand in den nächsten Zustand zu überführen, wird also Wissen benötigt und es werden Fähigkeiten benötigt, das Wissen zu erarbeiten und mit dem Wissen zu arbeiten. Wesentliche Teilaspekte des Wissens sind hierbei:

1. Das Wissen um die Eigenschaften und Fähigkeiten, welche die aktuelle Version des Produkts besitzt und das Wissen um die Eigenschaften und Fähigkeiten, welche das neue Produkt in Zukunft besitzen soll è Produktwissen also
2. Das Wissen und die Fähigkeiten, wie das Produkt entwickelt wird und produktiv gesetzt wird è das Wissen, um das Vorgehensmodell, also Prozesswissen.

Mit den Eigenschaften und Fähigkeiten des Produktes an sich beschäftigt sich genau das „Hilfsmittel“ Requirements Engineering. Wesentlich für einen Projekterfolg sind jedoch ebenso die Fähigkeiten, WIE das Produkt entwickelt wird, also auch WIE das Hilfsmittel Requirements Engineering eingesetzt wird. Beide Aspekte spielen untrennbar zusammen.

Eine wesentliche Eigenschaft der Wissensarbeit zum Lösen einer komplexen Problemstellung ist, dass bei Start eines Projekts das Wissen noch nicht vollständig, oft sogar nur sehr rudimentär vorhanden ist – was genau ein Problem zu einem komplexen Problem macht. Das Projektteam besitzt in keinem Fall das volle Wissen über die Eigenschaften und Fähigkeiten des zukünftigen Produkts, sondern nur eine mehr oder weniger klar umrissene Vorstellung davon. Es ist ja gerade Aufgabe des Requirements Engineering dies im Projekt zu präzisieren. Das Projektteam besitzt jedoch genauso wenig das volle Wissen, wie das Produkt entwickelt wird, da die Stakeholder eventuell unbekannt sind (wie sollen wir also mit diesen zusammen arbeiten), ebenso wie das Testen (was können wir Automatisieren und wo brauchen wir noch den Mensch im Testen), aber auch der Vorgang des Deployments und viele andere Details. Zudem ändert sich alles dies auch noch im Verlauf der Projektarbeit.

Abbildung 4: Das Ökosystem Projekt löst das gestellte Problem wirtschaftlich

Ganz allgemein kann gesagt werden, dass am Anfang eines Projekts das Wissen nicht ausreichend geschweige denn vollständig vorhanden ist und vom Team erst erfahren und gelernt werden muss. Das notwendige Wissen, um das Problem des Projekts zu lösen, hat erhebliche Lücken in jeder Hinsicht. Eine wesentliche Aufgabe eines Projektteams ist es diese Wissenslücken zu füllen. Das gilt für Lücken im Domänenwissen, ebenso wie für fachlich- technisches Wissen und für das Prozesswissen.

Das klingt alles so Abstrakt, also möchte ich hier ein paar Beispiele aus meiner persönlichen Erfahrung wiedergeben (anonymisiert):

In einem Projekt erstellte unser Team ein Planungssystem für Zugfahrten. Zum Domänenwissen gehört zum Beispiel dass die im Kursbuch stehenden Zeiten für Ankunft und Abfahrt nur für den Bahnkunden relevant sind. Intern, im Führerstand der Lokomotive zum Beispiel gelten durchaus andere Zeiten, die im sogenannten technischen Fahrplan für den Lokomotivführer stehen. Nur wenige alte Hasen im Projektteam hatte vor dem Projekt überhaupt eine Ahnung, dass es hier unterschiedliche Sichten gibt. Erst das Arbeiten mit den Fachleuten brachte diese Erkenntnis für alle.

Technisches Wissen beschäftigt sich zum Beispiel mit der Build- und Deployumgebung, also mit dem Stagingprozess eines Produkts bis es schließlich für die Produktion freigegeben ist. Eine internationale Bankingsoftware muss für jedes Land durch die Abnahmetests der dort geltenden gesetzlichen Regelungen gejagt werden, bevor die Software dort die Freigabe zur Produktion erhält. Ich wusste zum Beispiel lange Zeit nicht, dass unter anderem gefordert werden kann, dass gewisse Daten physikalisch in einem Land abgespeichert sein müssen, also zum Beispiel nicht in einer Amazon Wolke sein können, die irgendwo schwebt. Die Durchführung von Abnahmetests muss die Verfügbarkeit von Testdaten berücksichtigen.

Organisatorisches Wissen setzt dem Projekt Randbedingungen, in welchem die Entwicklung abläuft. Bei einem bestimmten Kunden zum Beispiel darf ein Projekt aus organisatorischen Gründen erst mit einer neuen Phase anfangen zu arbeiten, wenn die vorhergehende Phase in einem offiziellen Review als erfolgreich abgenommen gilt. Ich habe es selbst erlebt, dass Projekte in der Review Phase zu zwei Wochen Stillstand verurteilt waren. Das war mir bei Start des Coaching eines Projektteams in dieser Organisation nicht bewusst und – ganz ehrlich – ich hätte es vorher auch nie geglaubt. Dieser Fall ist schon ein Hinweis für mögliche Ansatzpunkte von mehr Agilität.

Fassen wir die bisherigen Erkenntnisse zusammen:

1. Das Ziel einer Organisation ist es das RICHTIGE Produkte zum RICHTIGEN Zeitpunkt herzustellen
2. Ein Produkt oder die bessere Version des Produkts wird über ein Projekt erstellt
3. Ein Projekt ist ein soziotechnisches Ökosystem
4. Ein Projekt startet mit einem komplexen Problem zu dessen Lösung sich das Projektteam Wissen erarbeiten muss, da Wissenslücken jeder Art vorhanden sind.
5. Das Wissen fällt in die beiden Kategorien:
   a. Wissen WIE das Produkt gebaut werden soll, das Prozesswissen
   b. Wissen, WAS das Produkt können soll, hierzu setzen wir als Hilfsmittel Requirements Engineering ein

Dieser Blog hat uns also die Erkenntnis gebracht, dass Projektarbeit Wissensarbeit ist. Ein Projektteam ist eigentlich eine Art Lerngruppe. Ein Projektteam ist dann erfolgreich, wenn es sich effizient die richtige Menge Wissen erarbeitet und dieses effizient zum Bau des Produktes einsetzt.

Agile RE Blog 1: Was ist Requirements Engineering

Ich fange mit auf dem Allgemeinplatz an, als Einstieg, sozusagen in der Komfortzone. Dieser Allgemeinplatz ist die Frage, was ist Requirements Engineering eigentlich?!

Ich mir sicher bin, dass ich bei 100 Experten dazu 200 verschiedene Antworten bekomme. Das nutze ich, die meine einfache Antwort im Kontext des Themas zu geben. Diese lautet: Requirements Engineering ist ein Hilfsmittel, wenn auch ein sehr wichtiges Hilfsmittel. Requirements Engineering ist eines der Hilfsmittel, um ETWAS zu erschaffen. Dieses ETWAS ist in der kommerziellen Welt typisch ein Produkt (wie ein Handy, Auto oder eine käufliche Software), ein Service (wie Bankkonto, Telephonie, Internetanschluss oder Cloud Service), eine Dienstleistung (Hausverwaltung, Consulting oder Kundendienst) oder eine Mischung aus all dem.

Abbildung 1: Das Produkt steht im Mittelpunkt, Requirements Engineering ist ein Hilfsmittel

Das Produkt - ich sage im Weiteren vereinfachend für alles dies Optionen - ist der Gegenstand unseres eigentlichen Bestrebens. Damit verdienen wir unser Geld. Also ist es besser als nur ein Produkt zu erschaffen, dieses mit möglichst niedrigen Total Cost of Ownership (TCO) zu erschaffen.

Requirements Engineering ist also ein HILFSMITTEL, um ein vom Markt verlangtes Produkt zu erschaffen und dies in einer Art und Weise, dass die Ideenfindung dazu, die Herstellung und der Verkauf, eben die TCO, billiger sind als der Erlös.

Dieses "in einer Art und Weise" ist nun genau der springende Punkt. Gute Produkte (oder Services oder Dienstleistungen) sind diejenigen, die mit den richtigen Eigenschaften zum richtigen Zeitpunkt auf dem Markt kommen. Nehmen wir an, wir haben bereits ein Produkt - oder auch zwei oder mehrere Produkte zum Verkaufen in unserer Organisation, die wir am Markt anbieten.

Nun ist klar, dass „Morgen“ die Produkte anders aussehen müssen, wir müssen sie umbauen oder erweitern, damit sie attraktiv bleiben. Wir müssen eine neue Version der Produkte erstellen. Diese Erkenntnis ist trivial. Das typische Gefäß, um Produkte zu erstellen oder zu erweitern sind Projekte. Ein Projekt ist laut Definition eine temporäre Organisationsform, um einen bestehenden Zustand, in dem Fall den Zustand des Produkts (ein Projekt kann auch andere Dinge treiben als Produkte) in einen neuen Zustand zu überführen. Wir haben somit ein oder mehrere Projekte, um von einem Produkt eine neue Version zu bauen oder auch ein komplett neues Produkt zu erschaffen. Irgendwo rund um oder in das Produkt und Projekt stecken wir auch das Hilfsmittel Requirements Engineering hinein, die notwendig ist, um die neue Version des Produkts zu erschaffen.
Ich möchte an der Stelle wiederholen: ein „GUTES PRODUKT“ bringt die richtigen Eigenschaften zum richtigen Zeitpunkt an dem Markt. Eine erfolgreiche Organisation kümmert sich aktiv um diese beiden sehr abstrakten Eigenschaften „RICHTIGE EIGENSCHAFTEN“ und „RICHIGER ZEITPUNKT“. Wichtigen Eckpfeiler dafür ganz am Anfang Innovationsprozesse mit der Identifikation der Produkte, dann die Definition unseres Produktportfolios und die darauf abgestimmte Release Planung. Mit der Release Planung entstehen die Projektportfolios als ausführende (operative) Ebene unterhalb der Produktportfolios. Aus Sicht der Organisation ist die Definition des Produktportfolios die strategische Ebene, das Management und Releasemanagement des Produktportfolios die taktische Umsetzung der Strategie und die Projekte die operative Ausführung von Strategie und Taktik(Regieanweisung: Grafik erweitern).

Die strategische Ebene lasse ich im Weiteren einfach unberücksichtigt. Die taktische Ebene, also das Management des Produktportfolios mit Releaseplanung der Produkte und die damit verbundenen Aktivitäten, das alles ist wichtig jedoch wichtig für die weiteren Überlöegungen. Darin steckt Requirements Engineering und die Chance zur Agilität. Denn Requirements Engineering beschäftigt sich mit den Eigenschaften, die sich bereits in den Produkten befinden und auch mit den Randbedingungen unter denen sie erstellt und eingesetzt werden, wie zum Beispiel regulatorischen Auflagen. Requirements Engineering arbeitet mit dem Innovationsprozess in Form neuer Ideen, welche als neue Anforderungen Eingang finden für kommende Produktversionen. Requirements Engineering arbeitet mit der Marketingabteilung, mit Kunden und / oder mit dem Kundendienst. Requirements Engineering betrachtet die Randbedingungen der Technik und der Erstellungsprozesses, um wirtschaftliche Aspekte zu beachten und den TCO zu optimieren.

Wir haben nun das Bild, wo Requirements Engineering im Kontext der Überlegungen zu finden ist. Wir bewegen uns also noch in der Komfortzone und haben den Einstieg in den nächsten Schritt erarbeitet.

Abbildung 2: Das Ökosystem der Produktentwicklung mit strategischer, taktischer und operativer Ebene

Wenn wir nun das Ökosystem der Produktentwicklung (siehe Abbildung 2) betrachten, dann fallen zusammen fassend zwei Dinge ins Auge:

1. Es existiert eine Ebene oberhalb des Projekts, die Ebene des Produktportfolios (auch, wenn sich darin nur ein einziges Produkt befinden sollte). Auf dieser Ebene müssen taktische Entscheidungen getroffen werden, wie sich die Produkte weiter entwickeln sollen, oder welche neuen Produkte benötigt werden. Die Release Roadmap mit resultierendem Projektportfolio ist die taktische Umsetzung des strategischen Produktmanagements. Das Bewirtschaften (Management) eines Produktportfolios ist ein kontinuierlicher Prozess, welcher Marktbedürfnisse, Innovationen, den Zustand meiner Organisation und kommerzielle Randbedingungen gegeneinander abgleicht. All das benötigt ein gutes Maß an Requirements Engineering, welches dafür sorgt, dass unsere Organisation das RICHTIGE Produkt zum RICHTIGEN Zeitpunkt am Markt verkaufen kann. (ANMERKUNG: An der Stelle kann gestritten werden, ob es sich um Requirements Engineering handelt, oder ob das ein Teil der Business Analyse oder ein beliebiger anderer Begriff ist. Wenn wir uns die benötigten Fähigkeiten und in die ausgeführten Tätigkeiten der Personen ansehen, welche hier aktiv werden, so sehen wir, dass diese zu einem hohen Grad deckungsgleich mit Requirements Engineering sind. Ich nenne es daher einfach Requirements Engineering).
2. Es existiert die operative Umsetzungsebene der Produktreleasemap, die Projekte. Diese Projektebene, eben das Projektportfolio spielt zu definierten Synchronisationspunkten mit der Prozessebene des Produktmanagements eng zusammen. Ein wesentlicher Aspekt fällt hierbei sofort auf: Die taktische Ebene und die operative Ebene verwenden Informationen und Wissen, dass in beiden Ebenen entstanden sein kann und transparent zwischen den Ebenen wandern können muss. Ich denke zumindest auf dieser Ebene sind wir uns einig, dass es sich um Requirements Engineering handelt.

Zusammenfassend stellen wir fest, dass RE in der taktischen Ebene und in der operativen Ebene steckt. Beide Ebenen müssen eng miteinander zusammenarbeiten. Requirements Engineering ist ein wichtiges Bindeglied in der Kommunikation zwischen den beiden Ebenen, eine Schlüsseldisziplin, also eines der wirklich wichtigen Hilfsmittel. Erfolg oder Misserfolg der Organisation hängt ganz stark damit zusammen, ob das Requirements Engineering zwischen diesen beiden Ebenen effizient gestaltet und gemäß der Strategie der Organisation gelebt wird.

Im nächsten Schritt möchte ich das Ökosystems des Projekts unter die Lupe nehmen. Ganz erstaunliche Dinge lassen sich in dem Ökosystem erkennen, die zur Agilität führen und nicht die Wurzel im Agile Manifesto besitzen oder in den Bücher von Mary Poppendieck (die jedoch ihre Bedeutung daher nicht verlieren).

Agile Requirements Engineering - Eine Blog Serie

Sorry, this blog series about agile requireemnts engineering is in German. Reason is the source - a German conference, where I was asked to talk about this topic. So if somebody is interested in a translation, please let me know and I will care for.

---

In meiner Rolle als Board Member des IREB International Requirements Engineering Boards e.V. erhalte ich immer wieder Anfragen, wie es denn mit Agilität in Zusammenhang mit Requirements Engineering aussieht. Anfang habe einfachgeantwortet, dass es für mich hier keinen Unterschied zu einem agilen Vorgehen an sich gibt.

Die Anfragen regten mich jedoch an, mich einmal intensiver mit dieser Frage zu beschäftigen und zu hinterfragen, ob es denn eine spezielle Sicht aus dem Blickwinkel des Requirements Engineering auf agiles Arbeiten gibt. Die Antwort war ja – wenn der Kontext weiter gezogen wird als alleine das agile Arbeiten in einem Projekt. Agilität alleine im Projektkontext ist meiner Meinung nach nämlich eine klare Einschränkung.

Das Ziel einer beliebigen Organisation kann ja nicht sein effizient Projekte durchzuziehen. Projekte sind zeitlich begrenzte Vorhaben, um Organisationsziele zu erreichen. Das kann eine Innovation sein, um die Zukunft zu sichern, ein Produkt zu erstellen, um damit Geld zu verdienen oder einfach ein Vorhaben um die Organisation zu optimieren.

Das war der Start meiner Überlegungen, welche Verantwortung dem Requirements Engineering in einer Organisation übertragen ist und welchen Einfluss ein agiles Arbeiten dann auf die Gestaltung dieser Verantwortung ausübt. Aus den Überlegungen wurde ein Vortrag, den ich testweise an einer Konferenz gehalten habe, um ein Feedback zu den Überlegungen zu erhalten. Das dieses Feedback motivierend war und ein vorhandenen Interesse gezeigt hat, setze ich eine Blogreihe zu den Überlegungen auf

Agility and staff organization in large organizations

In the last six to seven year I worked a lot with large organizations - in only a few cases real agile, but we were always discussing how to change towards more agility...

These discussions inspired me to reflect on the staff organization and staffing rules for projects. If you have some hundred knowledge workers in your organization you just have to setup some kind of structure. Question is: What kind of structure is best suited for the organization?!

Contradictory goals and constraints come into play.

• you have to staff projects and programs with the appropriate skills
• you have to offer your employees a clear development and career path
• every staff member needs a boss in the line mangement for several reasons
• organizations today need a certain amount of flexibility in the size of the workforce so they can adopt to a changing market (or win and loss figures)
• the project portfolio includes anything starting from real up2date innovation projects to boring maintenance of legacy systems
• the only thing that is constant is change in your organization

I recognized two core pattern for staff organization. From my point of view these pattern are as following:

1. The "Pool pattern": Creation of discipline oriented pools of engineers lead be a line manager (the pool head). Typical pools are: business analysis, project management, requirements engineering, architecture, development and testing. Each time a projects comes into life the pool head is requested to send the needed amout of FTE's, lets say 1 PM, 0.5 RE, 1 Architect, 4 Devs, 2 Tester and so on.
2. The "Application pattern": Each software application has a more or less constant team that has the knowledge to develop and maintain the application. The team sticks to the application as long as the application lives.

From my point of view both pattern have a few advantages but many disadvantages.

  

The Pool Pattern allows to define a clear carrier and development path for staff members - often well aligned with human resource management and development. An architect runs through these skill levels and trainings over the years and will become an senior architect over the time (if she is able to cope). As well you know in your organization how many of X and what level you have and check that against what you need for expertise in your organization.

But drawnbacks are enormous:

• You educate specialists that identify with being a specialist. A developer does not know how to test (and worse: does not want to).
• If a project needs 0.5 RE it get's 0.5 RE in person, i.e. an RE ends up as team member in 2 or 3 projects at the same time. Efficiency of such a poor person tends against Zero, even if she is keen and good. Might not be the case for Dev's and Tester, but for core roles like RE's and BA's I have seen this often.
• Project teams are just put in place and destructed again as the projects are defined and close down. The knowledge a team builds up to succeed with the specific context of the project is gone. No sustainable path for project work. Efficiency is intentionally wracked.
• Agility is out of reach. For agile teams you need the multi-disciplin engineer, not the specialist in X. A multi-disciplin engineer typically is very good in A, but good in B and C and - in case nobody else is available right now - will go for D at least sufficient.

The "Application Pattern" is good for efficiency in respect of this application. The team around the application is pretty constant and sharing knowledge. They know how to deal with the dark sides in the application and know how to develop and maintain. Sounds pretty good for setup of agile teams. But in real life I have seen as many disadvantages:

• Example: The team responsible to create reports with the report application X that is stoneage. These developers are lost for the market. Personal development never took place. Some never realized that and the organization neither. No additional statements needed.
• The team around the team lead (she is typically the line manager as well) has a strict parochial thinking. A local kingdom with a very strong local king. In case of troubles always the others are guilty. The local king protects but as well closes out his team. Lucky team to have a king with high ethics (I personlly met many of these high ethic peers for there team :-) but others as well :-( ).
• To push a valuable business request through that touches - let's say - four or five local kingdoms is a multi-battlefront war between business and IT. One reason for the often mentioned and existing gap between business ind IT.
• Anybody talking about personal development?! Organizations structured like this often buy-in the needed skill-set on the market. From time to time there are re-organizations going hand in hand with payoffs.
• Interesting aspect: in organizations like this the instrument "project" often lost his meaning. Nobody really can say what a project is, when it started and when it ends. The team is working in a kind of permanent process on its application...

These structural patterns often hinder a change towards agility. The "Pool Pattern" with partial engagement in projects, therefore wrong cut projects and specialists. Inefficiency in the work force, specialists that are not used to work as teams and permanent building up of knowledge and throwing that knowledge just away again.

The "Application Pattern" with local kingdoms. A thinking that prevents business requests to be seen and handled as a whole, thus slowing down time to market. The compensation is installing a huge workforce of business analysts decomposing business values into tiny change requests passed into kingdoms to prevent subject matter discussions with local kings.

Two ways to implement waste. Is there a successful way?

My idea would be a combination of these pattern with a serious change of what a team is responsible for, what an application really is and what a project should has as context, goal and size.

I guess I reflect about that the next time.

Biking in Graubünden

Well, in my last blog I recommended the Restaurant Gemsli in Graubünden. Now I want to recommend a good way to burn the calories, so can can enjoy the local and rich food at Gemsli.

Stop reading here, if you do not like to toture yourself by biking uphill a 1200 m altitude or riding small single-trails. As well stop reading here if you not like terrific views or ancient hidden Walser colonies.

In case you love all of that I recommend the following tour starting at Thusis in Graubünden right at the Viamala gorge, where the river Rhine (in Retoromania: Rein Posteriur) breaks through.

The small detour passing Carschenna helps to to avoid the national road where truck try to kill you.

As soon as you enter the small dirt road direction Mutten (there is a bus stop), you will shift in a small gear. 1000m giong uphill in 10km way are waiting for you. There is no chance of a rest or relieve other then to take a break in turning the wheels.

Obermutten is the place for a break. Obermutten is an acient Walser colonie hidden at the rim of near the col. You will see Obermutten in the last moment and it cannot be seen from the mountains around (I tested it). The Walser, moving from the Wallis direction east about 1200 a.d. wanted to live as free farmers and often settled in hidden places up the mountains. Now these colonies are recommended to be set under the UNESCO Convention Concerning the Protection of the World Cultural and Natural Heritage.

We took a rest in the small Restaurant Pöstli in Obermuttern. A very friendly host served us local specialities...

Then we left for starting with the downhill direction Sarnest and Zillis right before the Viamala gorge. The next image tells you how the beginning of this trail looks like.

Unluckily (or not, depends on what you like) this kind of way opens up to a fair to go dirt track that falls down to Zillis. Fun to have good breaks.
...and yes, Gemsli was waiting for us.

Restaurant Gemsli, Flerden, Graubünden, Switzerland

If you ever spend some time in Thusis and you love the homebred local cuisine, you definitly have to book for a dinner at the Restaurant Gemsli in Flerden. Flerden is a small village 500 meter above Thusis.
Search for Restaurant Gemsli Flerden in Google Earth or go to the local site  (in German only).

Ideally you go twice. The first time eat Pizokel or Kapunz or any other local speciality of the local cuisine. While you are eating discuss with the host your next dinner. She is just cooking just for passion using natural beef, vegetables and ingredients.

The first time you try to enter the Gemsli, don't be scared off by the impression of the Restaurants facade from outside. Inside you will find a homebred but cosy farmersroom with a large and warm oven. You will feel comfortable.

Are Scrum Master Courses really the primary need?

Thanks to Jeff Sutherland and Ken Schwaber who developed Scrum some 15 years ago. Today Scrum is one of the far most used tools among many more tools that have been developed in the last two decades to become agile.

Thanks to Jeff Sutherland and Ken Schwaber for the development of a course to educate Scrum Masters, so that the message of Scrum was disseminated into organizations. Clearly at starting times of Scrum the most important course was the Scrum Master Course, brought onto the market by the Scrum Alliance, called Certified Scrum Master Course or CSM. This type of course really was one of the drivers to make Scrum popular. Some ten thousands of certified Scrum Master are out there.

Still this course is the most requested training for Scrum. But exactly that is what makes me nervous... A Scrum Master is the coach and guide of the team. The goal of the course is to enable Scrum Masters, not team members. My concern: What to do with all these Scrum Masters? Let's play with some figures. Let's assume that the average Scrum team has seven team members and that one Scrum Master can jump-start two teams per year. Eighty thousand Scrum Master - about that number of registered Scrum Masters are listed on the Scrum Alliance site - potentially would be able to jump-start five hundred thousand Scrum team members per year!!! I would say there are enough Scrum Masters running around. If you need one, you probably already have some in your organization. This might be bad luck for all who want to start a career as SCM trainer in these days.

What really is concerning me is that still team members often do not know how to act in their specific environment and good product owners are rare like a shall with a perfect pearl. Reasons are obvious: To succeed as team it needs more then just coping with Scrum. A team developi software needs as well software engineering best practices, tool and environment skills. Teams by now are just in the beginning to learn all this in combination as a multiple functional team with multi-discipline team members. As well a team of managers using Scrum: It needs skills how to decompose a complex problem of their domain into pieces and how to manage these in a backlog. Then what about product owners. I have seen only very few really powerful and empowered product owners - what might be a problem of the organization behind, but without an education path for product owners this will not change. The context of a product owner is complex depending on the organization and product or services a product owner is responsible for. Over all the symbioses of a set of skills, required to be successful in a profession by using Scrum, must be trained in combination. That a path towards agility.

With one word: The today's primary need of training is not a CSM class. The need is on specific trainings for Scrum team members, specific to their environment and tasks. Simple sample: if you want to become a very good ice hockey player, you can not start with learning how to glide on ice and independent from that pushing the puck over a field. You have to learn both at the same time. A training attended by a developer needs a portion of Scrum, of SWE best practices and playing with tools and environment in combination. Scrum product owners need a training that talks about business value and decomposition of complex problems in their business context.

Consequences are as well on the trainer side. Trainers need to cope with the context of the target audience. A trainer not able to understand the code of an automated acceptance test should not train a team of developers. It might be a good idea to ask the requested trainer, before you engage him for a team of software developers, how he would write automated acceptance tests or setup continuous integration. A trainer for a management team acting in a Scrum way needs to understand and handle management problems. A trainer for product owners ideally knows the business domain beside all knowledge about business value, total cost of ownership and value chains - yes an maybe Kanban as well.

So what we need are more specific trainings for different types of target teams and YES for product owners as well. There are some steps to go on this road. I personally see the following steps:

1. Please STOP sending whole teams into SCM (Scrum Alliance) or PSM (scrum.org) courses. Only Scrum Masters need this course.
2. Select a specific training for the team members. Problem is: where to find those courses? My proposal: browse and ask the well know sources on the web, ask your favorite agile consulting partner and shape the specific class with him. This might be more expensive then a standard course, but ways more effective in the end.
3. Care for empowered product owners. The current species of project managers, product managers and even the keen business analysts or requirements engineers typically carry already a good skill set. Often missing is the agile mindset as experienced project managers shaped their skills in a different culture. Empowered product owners, well established in the organization, are an essential success factor for your projects.
4. Convince managers that life long learning is a prerequisite for knowledge workers - no matte if you are using Scrum or waterfall to build your products. Convince them to invest into specific trainings and in coaching for their teams.

In my collaboration with scrum.org and following the discussions in the agile community I recignize that specific trainings for Scrum teams in different context and for product owners by now are a very hot topic an many options pop up.



More on special trainings later... best Rainer