Heute geht es um die Abkürzung RK. Bei RK denke ich an den Ronneburger Kreis, einem gemeinnützigen Verein, bei dem ich Mitglied bin. Der Ronneburger Kreis wurde von Menschen gegründet, die sich bei Management-Trainings von Rupert Lay kennengelernt haben und die der Meinung waren, man müsste etwas für ethisches Handeln in Wirtschaft, Politik und Gesellschaft tun. Ich war Mitgründer und habe lange Jahre im Kuratorium und jetzt im Beirat des RKs gewirkt. Meine Erfahrung: als Lobby für ethisches Handeln hat man es auch nicht leicht.

Heute geht es aber um die Relevanzkriterien in Wikipedia, abgekürzt RK:

RK bzw. WP:RK

Sind Abkürzungen für Relevanzkriterien; WP:RK funktioniert als Abkürzungsredirect auf dieselben

(original aus dem Glossar von Wikipedia kopiert)

Das mit der Relevanz ist natürlich eines der Hauptprobleme einer demokratisch organisierten Enzyklopädie. Wikipedia ist multidimensional geworden. Gestartet als allgemeine Enzyklopädie enthält es heute (fast) alles. Man findet unter anderem:

• Ein Nachschlagewerk für IT-Probleme (z.B. was gibt es für Ports?)
• Beschreibungen technischer Sachverhalte (Wie funktioniert eine Nabenschaltung?)
• Definitionen von (philosophischen) Begriffen (Was ist Glück?)
• Beschreibungen von Unternehmen (Was ist Siemens?)
• Das neue “Who is who” für Menschen und Unternehmen (Wer ist Rupert Lay?)
• Geschichten der Pop-Musik (Was ist Hey Jude?)
• Begriffe aus dem Management (Was sind “Lessons Learned “?)
• Schachvereine (Gibt es einen FC Bayern München im Schach?)
• und vieles mehr …. (Was ist wikipedia?)

Ich könnte die Liste noch ziemlich lange fortsetzen …

Was ist denn relevant?

Zuerst die Definition von Relevanz in Wikipedia. Man sieht am Eintrag, dass der Begriff nicht einfach ist. Deshalb ein (un-)lustiges Beispiel für persönlich empfundene Relevanz.

Bei der S-Bahn im Großraum München ist die von mir gefühlte Pünktlichkeit deutlich schlechter als die von der Deutschen Bahn AG veröffentlichte Statistik zur Pünktlichkeit. In der Statistik sind fast 80 % der S-Bahnen pünktlich, mein Eindruck als Nutzer ist, dass es nur jede zweite ist. Das liegt unter anderem auch daran, weil in der Statistik eine Verspätung von 5 Minuten als nicht relevant gewertet wird und deshalb eine S-Bahn erst dann als verspätet gezählt wird, wenn sie mehr als 5 Minuten später kommt. Fünf Minuten Verspätung seien nicht relevant. Das lasse ich für den Zug von Hamburg nach München gelten. Wenn ich aber von Riemerling nach Neuperlach will, dann sind 5 Minuten Verspätung bei 6 Minuten Fahrzeit schon relevant. Wenn die Zugfolge (wie ab und zu ab Unterhaching) im 10-Minuten-Abstand erfolgen soll, sind 5 Minuten die Hälfte des Takts und deswegen auch relevant. Und wenn die S-Bahn sich in einen Tunnel einreihen soll, in dem (theoretisch) im Minutentakt gefahren werden kann, so hat das auch relevanet Folgen. Wenn dagegen der Zug mit dem Atommüll nach Gorleben einen Tag Verspätung hat, dann ist das sicher nicht relevant, man denke nur an die vielen 100.000 Jahre, die der Müll noch strahlen wird.

In Wikipedia ist es natürlich noch viel schwieriger mit der Relevanz, gerade wenn es um Personen, Unternehmen oder gar Sport und Sportvereine geht. Aber es gibt für alles klare und demokratisch erstellte Regeln. Wer und was in Wikipedia rein darf, das steht in den Relevanzkriterien.

Nehmen wir zum Beispiel Schachvereine. Ein Schachverein gilt als relevant, wenn er einmal in einer höchsten nationalen Spielklasse und/oder in einer internationalen Spielklasse gespielt hat. Und dann wird in den Regeln präzise festgelegt, was in welcher Zeit und in welchem Land als höchste nationale Spielklasse zu gelten hat. Die Bayernliga von 1968 ist da nicht dabei, obwohl sie damals die höchste deutsche Spielklasse war. Das hat 1968 (da gab es im Schach noch keine Bundesliga) aber nicht gereicht. Da musste man als Verein in der Endrunde der deutschen Meisterschaft sein, um heute relevant zu sein. Der an Mitgliedern stärkste Verein ist den RKs folgend nicht relevant und darf so nicht in Wikipedia rein. Auch ein Verein, der in 1873 gegründet wurde und heute noch existiert, ist nicht relevant, es sein denn, er wäre mal Deutscher Meister geworden. Sollte ja auch in 135 Jahre der Existenz möglich gewesen sein. Man sieht, “gerechte” Relevanzkriterien festzulegen ist gar nicht einfach.

Gerade bei “Wirtschaftsunternehmen” sind die Relevanzkriterien besonders umstritten:

Als relevant für einen enzyklopädischen Eintrag gelten Unternehmen, die

• mindestens 1000 Vollzeitmitarbeiter haben oder
• mindestens 20 Zweigniederlassungen / Produktionsstandorte / Filialen (keine Verkaufsbüros/Handelsniederlassungen etc.) besitzen oder
• an einer deutschen Börse im regulierten Markt oder in einem gleichwertigen Börsensegment im Ausland gehandelt werden oder
• einen Jahresumsatz von mehr als 100 Millionen Euro vorweisen oder
• bei einer relevanten Produktgruppe oder Dienstleistung eine marktbeherrschende Stellung oder innovative Vorreiterrolle haben (unabhängige Quelle erforderlich) oder
• eines dieser Kriterien historisch erfüllten.

(Originaltext Wikipedia, 16. 11. 2008, 19:35)

Eine klare Definition, die natürlich viele “relevante” Unternehmen ausschließt. Und da lief auch gerade wieder eine heftige Diskussion innerhalb Wikipedias ab (nach dem Motto: “Wikipedia ist kein Mädchenpensionat”), ob man die RKs für Unternehmen nicht erweitern sollte. Die Bandbreite der Meinungen geht da weit auseinander. Es gibt da auch Meinungen wie die, dass Unternehmen mit mehr als 5 Mitarbeitern relevant sind.

Die Relevanz von Personen ist auch ein schwieriges Thema. Natürlich lockt die Eitelkeit viele Menschen ins moderne “Who is who”. Und da wird es schwierig, wer rein darf und wer nicht. Mit meinem Selbstversuch bin ich ja schnell und den Kriterien folgend absolut zu recht gescheitert. Aber auch da gibt es interessante Konstellationen. Wie überall hat der Fußball auch in Wikipedia eine besondere Rolle. Als bekennender Haching-Fan habe ich natürlich nach den Spielern der Spielvereinigung gesucht. Da habe ich auch den Torwart Marcus_Stolzenberg gefunden, den ich nicht kannte. Er hatte nur ganz wenige Einsätze in der ersten Mannschaft von Haching (und auch sonst nicht), erfüllt aber die Relevanzkritierien für Fußballspieler. Auch hierzu habe ich vor kurzem in Wikipedia eine leidenschaftliche Diskussion entdeckt:  Ist ein Spieler, der nur einmal drei Minuten in der 2. Bundesliga zum Einsatz kam, relevant? Nach den Regeln sicherlich, aber man darf zweifeln, ob dieser junge Mann relevanter ist als ein Abteilungsleiter, der bei Siemens oder BMW 40 Jahre gearbeitet hat.

Technisch könnte man alle Menschen und Unternehmen in Wikipedia “reinlassen”. Aber wie kann man den hohen Qualitätsanspruch halten, wenn man eine solche Artikelflut zulässt? Wer soll das alles prüfen und gegebenenfalls korrigieren? Wer hält es auf dem Laufenden? Hilft ein Verfallsdatum für nicht gelesene und gepflegte Artikel? Alles noch zu lösende Probleme mit spannenden Diskussionen.

Der Prozess der demokratischen Meinungsbildung ist auch in Wikipedia nicht einfach, auch wenn mir scheint, dass er dort deutlich konstruktiver erfolgt als bei unseren politischen Parteien. Dazu gehört auch das Entwickeln von nPOVs (neutral Point of View), der Begriff kommt dann in der nächsten Folge von “Wikipedia und ich” dran.

RMD

P.S.

Beim Prominentenkick habe ich auch schon mitgemacht, aber selbst deswegen bin ich nicht relevant! So erfreue ich mich an meiner Irrelevanz. Und weil ich es oben erwähnt habe, lasst uns gemeinsam Paul und sein Hey Jude (Vorsicht Musik!) anhören .

Endlich wieder Zeit für Wikipedia!

Ich habe ja schon im ersten Wikipedia-Beitrag berichtet, wie wichtig mir Begriffe wie Freiheit oder Weisheit sind. Christof und ich kamen vor einiger Zeit auf den Gedanken, dass geübte Freiheit in einem sozialen System, wie z.B. in einem Unternehmen, einer besonderen Art von Klarheit bedarf. Natürlich haben wir gleich mal in Wikipedia nachgeschaut, um eine vernünftige Definition zu finden. Fehlanzeige, der Begriff Klarheit war - auch im philosophischen Sinne - nicht vorhanden. Das habe ich als Defizit empfunden und wollte es ändern - und habe so meinen ersten Beitrag in Wikipedia abgeliefert. Jetzt bin ich aber kein Philosoph und konnte deshalb nur eine sehr rudimentäre Definition von Klarheit in 2 Varianten (allgemein und unternehmensbezogen) schreiben.

Es kam wie es kommen musste. Kurz später war er schon da, der erste SLA:

SLA

Abkürzung für „Schnelllöschantrag“, siehe Schnelllöschantrag.

(aus dem hochinteressant zu lesendem Glossar von Wikipedia).

Die Begründung war unter anderem, dass dieser Begriff schon einmal angelegt worden sei und wegen inhaltlicher Schwäche wieder gelöscht wurde.

Das Blatt wendete. Vielleicht hatte ich doch ein paar relevante Aussagen zur Klarheit hinterlegt, der SLA wurde selbst verworfen und der Artikel nicht gelöscht. Aber er veränderte sich. Ich hatte in meiner Unerfahrenheit einen weiteren Fehler gemacht. Ich habe Klarheit nur angerissen (aus zwei Sichten, die mir wichtig waren), jedoch nicht als zusammenhängenden Artikel mit Bedeutung, Hintergrund usw. des Begriffes beschrieben. Das war auch meine Absicht, ich wollte ja nur einen Stein ins Wasser werfen und dann die Profis ranlassen. Hat auch so funktioniert, ist aber kein guter Stil in Wikipedia und hat mir eine sanfte Rüge eingebracht. Immerhin lernt ich dabei, dass ich ein “Bausteinsetzer” war. Obwohl ich meinen Job als solchen nicht ausreichend gemacht habe, bin ich zumindest froh, dass es sie jetzt gibt, die Klarheit in Wikipedia.

Der Artikel Klarheit (Philosophie) ist übrigens noch in in ÜA:

ÜA

Vorlage:Überarbeiten wird von aufmerksamen Wikipedianern eingefügt, die einen Artikel einer gründlichen Nachbearbeitung würdig befinden. Dies wird üblicherweise mit „+ÜA“ in der Zusammenfassungszeile angemerkt. „-ÜA“, „minus ÜA“ oder „rm ÜA“ bedeuten, dass dass dieser Bearbeitungshinweis gelöscht wurde.

(auch aus dem Glossar von Wikipedia).

Deswegen bitte ich alle Leser, besonders die Philosophen, doch mal die Klarheit anzuschauen und zu verbessern. Ein Textteil, der mir besonders wichtig war, ist übrigens rausgerutscht:

Klarheit herrscht in einem Unternehmen dann, wenn ein Sachverhalt oder eine Aufgabe von den Mitarbeitern eindeutig und unmissverständlich verstanden wird. Klarheit sorgt bei den Mitarbeitern für identische Konstrukte über einen bestimmten Sachverhalt oder eine bestimmte Aufgabe.

Ein “Wikipedianer” hat mir empfohlen, ein neues Lemma, etwa Klarheit (Unternehmensführung) einzuführen (das geht übrigens ganz einfach). Werde ich auch machen - und wahrscheinlich wird das Lemma auch gleich wieder gelöscht werden. Das Problem ist halt, dass das doch sehr schwierige Themen sind, bei denen ich mich an (oder besser jenseits) meiner Kompetenzgrenze empfinde. Und wie soll ich eine Quelle für eine Definition von Klarheit finden, die ja von mir ist? Also, professionelle Unterstützung für mich und Wikipedia ist erwünscht - an die Arbeit!

Ich habe übrigens auch Artikel aus meinem Fach gefunden, die dringend ÜA gemacht werden sollten. Zum Beispiel bin ich mit SINIX und Informix in Wikipedia nicht zufrieden. Und da kenne ich persönlich eine ganze Reihe von Kollegen, die es besser wissen sollten, weil sie bei der Entwicklung hautnah dabei waren. Die möchte ich auch gerne für die Mitarbeit bei Wikipedia werben. Und unser CLOU ist auch nicht in Wikipedia. Ist auch schade, immerhin wurde CLOU und HIT hundertausendfach (wahrscheinlich mehr als das) in Deutschland eingesetzt. Allein die Siemens AG hat in 10 Jahre ihrer SINIX-Erfolgsgeschichte mehr Lizenzen von HIT/CLOU als von Informix verkauft (Quelle - wie bei Wikipedia üblich: Herr Öfelein, PM bei Siemens für HIT/CLOU in den 80iger und 90iger Jahren). Wer ist bereit, einen CLOU-Artikel für Wikipedia zu schreiben? Die InterFace-Archive stehen ihm offen.

Vielleicht noch eine Info. In Wikipedia gibt es zu jedem Artikel auch eine Diskussionsseite. Hier die Diskussionsseiten zu Klarheit und Klarheit (Philosophie). Da sieht man auch die Geschichte, wie ich eben zur Klarheit in Wikipedia kam.

Die Diskussionsseiten sind oft sehr spannend zu lesen, da gibt es weitere interessante Überlegungen zu den Artikeln. Ich bevorzuge zurzeit indirekte Verbesserungen auf den Diskussionsseiten, bevor ich mich wieder an echte Artikel wage.

Das war es für heute, das nächste Mal kommen dann Relevanz und RK’s dran!

RMD

Seit einem halben Jahr darf ich bei Manage&More mitmachen, einer Aktivität von unternehmerTUM. Ich übe mich dort in der Rolle eines Mentors und habe einen Mentee. Bis vor kurzem wusste ich gar nicht, was ein Mentee ist, mittlerweile bin ich selber ein Mentee und zwar in Sachen Wikipedia. Das ist aber eine andere Geschichte.

Mein Mentee heißt Michael, er passt also auch vom Namen gut zur Überschrift. Michael ist ein sympathischer und authentischer Typ, früher hätte man gesagt, “einer mit dem man Pferde stehlen gehen kann”. Alle 4 - 6 Wochen treffen wir uns und sprechen über ein vorher vereinbartes Thema. Mal berichtet der eine und der andere spiegelt und fragt nach und mal machen wir das anders herum. So lernen wir voneinander einiges. Zum letzten Treffen hat Michael mir eine E-Mail gesendet: “Lass uns doch mal über Motivation sprechen!?” Das Thema hat mich angesprochen. Denke ich doch oft selbst genug darüber nach, wie meine Motivationslage so ist und warum ich für manche Themen gar nicht zu motivieren bin. Vorbereitet hab ich mich auf das Treffen zu erstmal mal, in dem ich - wie fast immer - den Begriff in Wikepedia gesucht habe. Da stand einiges zu Motivation drin. Ich habe es ausgedruckt, es waren 13 Seiten - und in der Tat war kaum etwas Falsches oder wirklich Unwichtiges dabei.

Michael wollte über Motivation mit mir sprechen, weil ihm in einem Feedback-Gespräch zurück gemeldet wurde, dass er ab und zu in Besprechungen seine Unlust zu gewissen Themen nicht verbergen könne und durch dieses “Fehlverhalten” die anderen Teilnehmer der Besprechung demotivieren würde. Und wie alle anständigen Menschen hat er zuerst die Schuld bei sich selbst gesucht. Aber Heucheln ist nun mal gar nicht so sein Ding.

Die spannende Frage war: Was soll man machen, wenn man in einer Besprechung an einem Thema mitwirken muss, das einem völlig unsinnig erscheint, man aber aus irgendwelchen Sachzwängen dabei sein muss. Ich glaube, das passiert uns allen hin und wieder - und wahrscheinlich in größeren Organisation noch häufiger als in kleinen.

Soll man dann heucheln, das Desinteresse verbergen und einfach aufs Tempo drücken, damit die grausame Besprechung schnell zu Ende geht und man sich dann ganz schnell wieder seinen wichtigen und geliebten Aufgaben widmen kann? Oder soll man den anderen Beteiligten ehrlich sagen, das man das Thema für nicht relevant hält, die eigene Beteiligung deswegen eh nicht zielführend wäre und dann die Besprechung mit einem freundlichen “Das könnt Ihr ohne mich ja eh viel besser, ruft mich an, wenn ihr das Thema durch habt!” verlassen?

Eine andere Idee: Man könnte sich auch das ungeliebte Thema zu eigen machen und sich die Frage stellen, welche Bedingungen denn erfüllt sein müssten, damit man es selber auch für sinnvoll erachten kann? Dann würde man sicher gute Argumente finden, die man trefflich einsetzen könnte oder die aber den eigenen Standpunkt verändern würden.

Wenn man aber wirklich der Meinung ist, dass das Thema absoluter Blödsinn ist, dann müsste man doch die Zivilcourage aufbringen, dies zu formulieren und einen innovativen Verbesserungsvorschlag zu machen - auch wenn man vor der Macht von entpersonalisierten und sich verselbstständigten Systemen resigniert hat und keine Chance sieht, etwas positiv zu wenden.

Wie man sieht, das Problem ist nicht einfach. Ich glaube, dass Heucheln und “Gute Miene zum bösen Spiel machen” die schlechteste Empfehlung ist.

mehr »

3 von X

Wie kaum anders zu erwarten beendeten wir den Sprint weit vor der Zeit;

Zum einen konnten die Performer den vom Product Owner (und mir) angenommenen Arbeitsaufwand stark “unterbieten”, zum anderen wurden Arbeitspakete, welche zu diesem Zeitpunk noch nicht relevant waren, oder starke Abhängigkeiten zu nachfolgenden Aktivitäten hatten einfach ‘hinten angestellt’ oder gänzlich verworfen.

Alles in allem machte es dem Team großen Spaß, in dieser Tiefe in die Planung involviert zu sein..

Nun fehlte eigentlich nur noch das ‘Big Picture’, bezüglich dem eigentlichen Ziel unserer Arbeit.

Ich habe bereits angesprochen, dass ein Product Backlog, wie wir es aus der Softwareentwicklung kennen für dieses Projekt wohl nicht besonders viel Sinn machen würde.. aber gänzlich ‘weglassen’ konnten wir dieses Artefakt auf keinen Fall: schließlich hatten wir das hehere Ziel, uns (auch argumentatorisch) gegen Einflüsse von Außen aufzustellen.

Also, bei insgesamt vier Projektaufträgen zum gegenwärtigen Zeitpunkt sollte das PBL wohl Aufgaben aus dem gesamten Programm enthalten; auch mussten wir Linien- und ad hoc Aufwendungen berücksichtigen, um mit der Methode Erfolg zu haben…

Mein Ansatz war ein simpler, der hauptsächlich von gesundem Menschenverstand getrieben wurde:

Wir würden die Vision und das Mission Statement des Auftraggebers sowie die direkten Projektziele zu einem Dokument zusammenfassen, welches dann entsprechend der auftretenden Änderungen iterativ überplant, und dessen Inhalte laufend neu priorisiert werden sollte.

Die Erstellung stellte sich anfänglich etwas kompliziert dar, aber nach dem Wechsel auf eine etwas abstraktere (Meta-)Ebene konnten wir schließlich ein ganz brauchbares PBL erstellen. Auch hier zeigte sich erneut, dass eine entsprechend verständliche Vision und das daraus abgeleitete Mission Statement wahre Wunder im Bezug auf Transparenz und Motivation bewirken können.

Heute geht es mit wehenden Fahnen in Sprint 2.

Die Performer akzeptieren die Methode, trotz Statschwierigkeiten mittlerweile voll umfänglich - nun geht es noch um das notwendige Maß an “Management Attention” - wenn auch noch ‘der Chef’ die Methode und das Vorgehen als wertvoll versteht, sind wir einen großen Schritt weiter - bis dahin kämpfe ich noch mit der “Insellösung” - ich transportiere die Ergebnisse und Abhängigkeiten aus SCRUM in Richtung des großen, tosenden Wasserfalls, gegen den wir anschwimmen..

Unser Fortschritt wird von mir in ein GANTT- Diagramm übersetzt, anhand dessen unser Team die Performance im Gesamtprojekt berichtet.

Wir werden sehen, wo weiteres “Optimierungspotenzial” auftritt, sobald es die ersten Wechselwirkungen zwischen Linie, Gesamtprojekt und unserer kleinen aber feinen SCRUM Gemeinde gibt.

We’ll see..

In den letzten beiden Artikeln zum Thema „Agiles Schätzen und Planen“ wurden bereits vorgestellt, wie es möglich ist, einen Sprint so zu planen, daß man sich möglichst immer die optimale Menge an User Stories vornimmt (nicht zu viel, aber auch nicht zu wenig).

Diese Planung wird alleine durch das Team durchgeführt (plus den Scrum Master). Eine Einflussnahme von aussen ist nicht vorgesehen, nicht einmal durch den Product Owner.

Das Team soll sich nämlich die zu erledigende Arbeit für den Sprint möglichst selbst auswählen, muss sich diesem „Sprint-Ziel“ dann aber auch verschreiben und darf auch nur noch in Ausnahmefällen davon abrücken. Auf diese Weise soll sich das Team stärker mit den Zielen identifizieren als wenn sie diese von aussen zugewiesen bekämen. Übrigens ein Ansatz, der tatsächlich funktioniert, wie unsere Erfahrungen hier eindeutig zeigen.

Natürlich möchte man aber auch dem Product Owner einen (berechtigten) Einfluss auf die Sprint-Ziele zugestehen. Wie löst man nun diese scheinbare Konfliktsituation?

Eigentlich ganz einfach:

Der Product Owner nimmt mit an der Sprintplanung teil.

Eigentlich ist dies sowieso notwendig, da nur der Product Owner dem Team den Sinn und Zweck einzelner Einträge des Product Backlogs erklären kann. Ein gutes Verständnis der Einträge ist aber wiederum unabdingbare Voraussetzung für eine gute Schätzung.

Kommt man nun gegen Ende der Planung an den Punkt, an dem das Team sich die Einträge für den neuen Sprint aussucht, so geschieht dies ja anhand der Einträge des Product Backlogs (das ja nach Geschäftswert sortiert ist). Die Sortierung aktuell zu halten gehört mit zu den wichtigsten Aufgaben des Product Owners.

Hat das Team die Liste der Features fertig erstellt, so wird sie noch einmal dem Product Owner vorgelegt, um sein Einverständnis zu erhalten. Normalerweise wird man es auch erhalten. Sollte dies aber wieder Erwarten nicht der Fall sein, so bleiben ihm noch drei Möglichkeiten der Einflussnahme:

• Er sortiert die Einträge des Product Backlog neu. Dies sollte eigentlich nur in Ausnahmefällen notwendig sein, zumindest wenn er es mit seiner Aufgabe genau nimmt, und das Product Backlog konstant aktuell hält,
• Er reduziert den Umfang eines Eintrags, um ihn so doch noch mit in den aktuellen Sprint aufnehmen zu können
• Er splittet den Eintrag auf. Der erste (dringendere) Teil wird sofort realisiert, der Rest auf einen späteren Sprint verschoben.

Somit wird die Kontrolle darüber, was in einem Sprint realisiert wird, zu gleichen Teilen auf Team und Product Owner verteilt:

Auf das Team, weil es alleine entscheidet, wieviele Story Points im Sprint umgesetzt werden können, und zudem noch die Einträge des Product Backlogs mit Story Points beschätzt.

Und auf den Product Owner, da er dem Team eine verbindliche Reihenfolge vorgibt, in der die Einträge des Product Backlogs realisiert werden müssen, und dieses bis zum Ende der Sprintplanung noch ändern kann.

Spielen alle Beteiligten ehrlich und aufrichtig zusammen, so schafft man so eine fast optimale Auslastung des Teams.

Darüber hinaus behält man auch immer den „Business Case“ (man verzeihe mir dieses Wort) im Auge, da der Product Owner, der ja derjenige mit der „Vision“ ist, immer dafür sorgt, die richtigen Anforderungen zur richtigen Zeit zu realisieren.

Die Sprintplanung ist also nun komplett, es kann also losgehen mit der Realisierung :). Bis zu Beginn des nächsten Sprints die nächste Planung ansteht…

BFI

Unser Autor Jens-Uwe Schmidt wurde im DEVELOPMENT NEWSLETTER – OCTOBER 2008 von HDS zum “instructor of the month” gewählt und ausführlich mit Interview vorgestellt:

Donna Garber, Academy Development Manager von HITACHI DATA SYSTEMS hat uns die Veröffentlichung gestattet. Sie schreibt:

“Jens-Uwe Schmidt is our featured instructor and also the winner of last month’s Challenge. Congratulations Jens-Uwe! We loved reading about your hobbies and we’d like to take you up on your offer to be more involved in course development”.

Die Ankündigung und das Interview ist hier nach zu lesen! Jens-Uwe ist auf den Seiten 2, 3 und 4 vertreten.

Zu Jens-Uwe: Obwohl er noch nicht so ganz lange bei InterFace ist, ist er irgendwie nicht mehr wegzudenken. Er ist nicht nur ein exzellenter IT-Fachmann und Storage-Kenner, sondern auch ein kritischer Mensch und guter Kumpel. Eigentlich hat er nur einen Fehler: Er schreibt zu selten für IF-Blog!

RMD

HDS - Academy Exchange (40)

Das ist doch schön zu sehen, wenn meine eigenen Ideen, die Rolle des ProductOwners zu visualisieren auch von “großen Geistern” geteilt werden: Jeff Sutherland schreibt dazu auf seinem Blog “World’s Best Product Owner: Evil Genius Steve Job“.

Kurz, aber mal wieder ein Lebenszeichen …

Stolz präsentieren wir etwas ganz besonderes: Jetzt ist es da, das nach unseren Recherchen erste und einzige “Scrum-Plakat” weltweit. Exklusiv wird es in IF-Blog zum kostenfreien Runterladen angeboten. Es war ein hartes Stück Arbeit für unser Team, aber jetzt ist die erste Version unseres Scrum-Plakates freigegeben.

Der Weg dahin:

Unser “Technology Scout” Alexander Maisch (genannt Axel) hat mir vor knapp einem Jahr berichtet, das er auf seiner Suche nach einem Scrum-Plakat nicht fündig wurde. Der Schluss war einfach: dann machen wir doch selber eines. Dann haben sich die Jungs und Mädels von InterFace, von der TUM und TEG so richtig ins Zeug gelegt. Wie für alles, was Hand und Fuss hat, haben wir neun Monate gebraucht. Und jetzt haben wir es gemeinsam geschafft, die erste Freigabe-Stufe ist erreicht.

Hier ist es, unser ultimatives Scrum-Plakat - zum freien Download. Auf Deutsch und Englisch

Und natürlich wird es kontinuierlich weiter entwickelt und jeder ist herzlich eingeladen, bei der Weiterentwicklung mitzuwirken. Und natürlich werden wir die weiterenwickelten Versionen dann auch wieder zum Runterladen freigeben!

RMD

Wie meinen Zuhörern (und dem Veranstalter) zugesagt, hier eine Zusammenfassung meines Vortrages in Kurzform:

Ich habe den Vortrag in drei Themenbereiche gegliedert:

1) Entwicklung von Technologien vom Beginn der Menschheit bis heute!

Seit es Menschen gibt, haben sie Techniken und Technologien entwickelt. Um die Entwicklung von Technologie zu diskutieren, habe ich menschliche Entwicklungen dem Kriterium ihrer Zweckhaftigkeit folgend in zwei Bereiche eingeteilt: Technologien für den Körper und Technologien für den Verstand.

Technologien für den Körper umfassen so alle Entwicklungen, die der Ernährung (”Fressen und Saufen”), des Reduzierens von körperlicher Anstrengung (”Faulheit”), Schützen des Körpers vor Kälte oder Nässe, Bewahren der körperlichen Gesundheit, der Vermehrung bzw. Vermeidung von Vermehrung (Sexualität), der schnellen Fortbewegung (Mobilität), der Entwicklung von Herrschaft und ähnlichem dienen.

Hier sind beispielhaft zu nennen: Jagd, Ackerbau und Viehzucht, Waffen, Feuer, das Rad, Fahrzeuge, Medizin, Schiffe, Fahrrad, geschlossenes Feuer, Lichtquellen, Kraftmaschinen, Automobil, Eisenbahn, Beherrschung der Elektrizität, Flugzeug, Chemie, Pharmazie, Kernspaltung und vieles mehr. Ich habe diese Disziplinen die “Allgemeinen Technologien” genannt.

Technologien für den Verstand umfassen alle Entwicklungen, die dem Erzeugen, Bewahren, Verbreiten und Verarbeiten von Informationen und Ähnlichem dienen. Beispielhaft sind hier: die Entwicklung von Sprache, Bildern und Schrift, Buchdruck, Datenübertragung, Rechenstab, Kurzschrift, Morse-Alphabet, Kabelübertragung, Telefon, Telex, Funk, Rechenmaschine, Schreibmaschine, Schallplatte, Radio, Fernsehen, diverse Aufzeichnungsgeräte, Computer, E-Mail, Internet. Diese Disziplinen habe ich unter dem Begriff der “Informatik” zusammen gefasst. Besonders wichtig waren mir die Begriffe “Digitalisierung” und “Virtualisierung”.

Ordnet man die Entwicklung all dieser Technologien auf einer Zeitachse an, stellt man eine ungeheure Beschleunigung (E-Funktion??) der technologischen Entwicklung fest. Man erkennt auch, wie die “Informatik” die Entwicklung der “Allgemeinen Technologien” vorangetrieben hat. Ohne Buchdruck wären die Technologiesprünge der Neuzeit unmöglich gewesen, ohne mechanische Rechenmaschine hätte keine Atombombe entwickelt werden können und was ein “WEB2″ bringen wird, können wir nur erahnen.

Die gewählte Darstellung lässt einen zweiten wichtigen Aspekt vermuten: Die Entwicklung von relevanten Fortschritt verläuft immer von “unten nach oben”, eigentlich im Sinne eines “automatischen” Prozesses der demokratischen Meinungsbildung und Ziel-/Regelfindung. Dies gilt für die Entstehung von Sprache, Schrift und Mathematik wohl genauso wie für Wikipedia.

2) Zitat von Bertrand Russell

Teil 2 des Vortrages habe ich auf einem Zitat von Bertrand Russel aufgebaut:

Jeder Zuwachs an Technik bedingt, wenn damit ein Zuwachs des menschlichen Glücks verbunden sein soll, einen entsprechenden Zuwachs an Weisheit!

Russel war nicht nur ein bedeutender Mathematiker und Philosoph des letzten Jahrhunderts, sondern auch eines der großen Idole unserer Jugend. Wenn wir seinem Zitat folgen und davon ausgehen, dass der Zuwachs an Weisheit beim Menschen z.B. seit Goethe nicht wesentlich stattgefunden hat, dann könnte man zu dem Schluss kommen, das der Zuwachs an Technologie das Glück der Menschen nicht mehrt. So kommt die Ethik ins Spiel. Vielleicht hilft ethisches Verhalten das “lag” zwischen Technologie und Weisheit ein wenig zu verkleinern.

3) Überlegungen zur Ethik von Managern

Schwerpunktmäßig habe ich über die Ethik der Entscheidung gesprochen. Führungskräfte (sogenannte Manager) befinden sich in einem großen Dilemma: Sie sollen in ihren Entscheidungen Ziele sinnvoll vereinen, die sich massiv widersprechen. Gewünscht wären jetzt sittlich verantwortete und nach sorgfältiger Güterabwägung getroffene Entscheidungen. Leider ist dies aber schwer und erschwert schnelle Entscheidungen. Deswegen behelfen sich viele Manager und Systeme und erleichtern sich die Entscheidungsfindung, in dem sie einen Trick anwenden:

Das geht ganz einfach. Man muss nur die Anzahl der zu vereinenden Ziele reduzieren, am besten auf ein einziges. Dies vereinfacht das Manager-Leben ungemein, ist aber als höchst unethisch zu bewerten und führt fast immer zu unteroptimalen Entscheidungen mit langfristig massiv negativen Folgen. Zwei Beispiele seien hier genannt. Ganz aktuell erleben wir die Weltfinanzkrise: Das singuläre Prinzip des Shareholder Value hat Profit im Bereich der Hochfinanz unisono als einziges Ziel festgelegt. Und dies hat eine Krise von gigantischem Ausmaß bewirkt. Und alle von Analysten getriebenen Unternehmen sind gefolgt - und ändern ihr Verhalten auch heute nicht, obwohl man es jetzt wirklich gelernt haben sollte! Demnächst in diesem Blog gibt es dazu noch ein oder mehr Beispiele.

Doch auch die Titanic musste untergehen, weil der Kapitän den Auftrag hatte, auf der Jungfern-Fahrt das “Blaue Band” zu gewinnen - und dieses Ziel hat er äußerst gewissenhaft befolgt.

RMD

P.S.

Meinen Zuhörern ein herzliches Danke für die vielen Beiträge in der Diskussion nach dem Vortrag.

Oft erlebe ich, dass Mitarbeiter in Großunternehmen ein relativ banal klingendes Daten-Problem haben, für das sie eine Lösung suchen - aber wenig Hilfe bei der IT finden.

Ein Beispiel: Ein sehr großer internationaler Konsumgüterhersteller kauft Verpackungsmateralien zentral für ganz Europa und für 2 Jahre ein (um gute Einkaufskonditionen zu erhalten). Es müssen ca. 50.000 Materalien (Folien unterschiedlicher Stärke, unterschiedlicher Größe mit unterschiedlichen Aufdrucken) bestellt werden. Dazu bittet man weltweit ca. 200 Anbieter um Preisangebote und trifft dann eine Auswahl und eine Kaufentscheidung. Klingt ganz einfach? Nun hat die Einkaufabteilung so wenig Datenbank-Spezialisten und hat nur eine Idee: 200 Excel-Dateien verschicken und die Rückläufe manuell zu analysieren. Da Excel nur 65000 Zeilen zulässt, war die Analyse vor 2 Jahren ein 3-wöchiger Prozeß für ein Team von 8 Leuten (die primär Daten per copy/paste in neue Spreadsheets kopiert haben).

Das muß doch besser gehen? Die eigene IT schlägt ein Einkaufsportal vor: Webbasiert mit einer Oracle-Datenbank. Sicher eine hochprofessionelle Lösung, aber viel zu teuer für eine Einmalaktion (und niemand will sich heute darauf festlegen, wie die nächste Einkaufsrunde in 2 Jahren durchgeführt wird) und unmöglich in kurzer Zeit umsetzbar. Office-Produkte (Excel und Access) werden von der IT nicht unterstützt und als unprofessionell abgetan - dabei könnte man durch Progarmmierung einer Einleseroutine für die Excel-Files und Erstellung einiger Access-Analysen (in Verbindung mit eine MIni-Schulung in Access) enormen Nutzen stiften.

Warum verpasst die “IT” solche Chancen? Ich glaube, es gibt 2 Klassen von “IT-Aufgaben” in Unternehmen. Eine ist das Erstellen, Warten und Betreiben von unternehmenskritischen EDV-Anwendungen (SAP, Flugbuchungssysteme für Airlines, Steuerungsprogramme für Produktionsroboter, …) die praktisch immer verfügbar sein müssen. Für diese Programme sind detaillierte Konzeption, Dokumentation, Grob- und Feinplanung, ausführliche Testphasen, … unerlässlich.

Gleichzeitig gibt es eine Vielzahl von Anwenderproblemen, die Ad-Hoc gelöst werden müssen und nur wenig mehr IT-Know-How benötigen, als der Benutzer hat (Man denke an ein kleines Excel-Makro, das automatisch Daten aus zwei verschiedenen Quellen abgleicht) aber enormes Potential hat (ein halber Tag Programmierung spart jede Woche 8 Stunden manueller Arbeit). Wenn nicht zufällig jemand in der jeweilgen Abteilung “IT-affin” genug ist und sich selbst Wissen angeeignet hat (was aber mangels Ausbildung und Erfahrung oft nur zu einer besseren aber nicht guten Lösung führt), gibt es keinen Ansprechpartner in Unternehmen.

Vielleicht ist es gewollt, dass “die IT” das zu ihren Aufgaben zählt - da das aber nicht klar kommuniziert ist (Was ist Aufgabe der “IT”?), erwarten die Benutzer Unterstützung für Ihre Probleme - und werden frustriert. Vielleicht fehlt in einem Unternehmen einfach nur eine 2.Abteilung “User-Problem solving”, die - unabhängig von IT-Strategie - die drängenden Nöte der Benutzer aufgreift und pragamatisch adressiert?

E2E