Meine Top 4 Anwendungen im Social Web

Eine permamente Debatte wird über der Nutzen von sozialen Netzwerken in österreichischen Unternehmen geführt. Ich möchte dies zum Anlass nehmen um meinen persönlichen Nutzen aus dem Social Web transparent machen. Unter den Top 4 meiner wichtigsten Social Web Anwendungen befinden sich:

  • Twitter
  • Delicious
  • Facebook
  • Xing

Ich möchte nun auf die Bedeutung der einzelnen Netzwerke für mich genauer eingehen.

Twitter:
URL: http://twitter.com/stwunder
Den überwiegenden Anteil meiner rund 2200 Follower kenne ich nicht persönlich und werde dies wahrscheinlich auch nie tun. Das ist aber auch nicht notwendig, da der Nutzen in den Verbreitungsmöglichkeiten des Netzwerkes liegt – das vergleichsweise große Netzwerk bietet mir sehr gute Verbreitungsmöglichkeiten für meine Inhalte (Blog Posts, Interessante Artikel, Fragen an die Community,…). Einen wesentlichen Nutzen ziehe ich aus der Aktualität und der Qualität der Inhalte, die in meinem Netzwerk geteilt werden. Mit Hilfe von Applikationen wie Tweetdeck oder Seesmic verwalte ich meinen Twitter-Stream und behalte so den Überblick.

Delicious:
URL: http://www.delicious.com/dead_fish_cant_swim/
Delicious hat sich zu einem der produktivsten Tools in meinem privaten als auch beruflichen Alltag entwickelt. Ich habe vor einigen Jahren begonnen meine ersten Links auf Delicious abzuspeichern und zu taggen – der Grund dafür war mein Frust über das Fehlen von dezentraler Favoritenverwaltung in Browsern. Über die Jahre hat sich Delicious zu einem unglaublich wertvollen “Webseiten-Index” mit über 1700 Einträgen für mich entwickelt – auffindbar bleiben die Links dabei über die Tags. Da sich fast alles online verlinken lässt ist Delicious heute für mich eine zentrale Wissensdatenbank auf die ich fast stündlich zugreife.

Facebook:
URL: https://www.facebook.com/stwunder
Ja, auf Facebook bin ich auch – und das seit mittlerweile über 5 Jahren. Der Nutzen von Facebook liegt für mich ganz klar in der Vernetzung mit Menschen aus meinem sozialem Umfeld. Dazu gehören alte Schulfreunde, Arbeitskollegen, spontanen Bekanntschaften, Freunden, usw. Ohne Facebook würde man viele dieser Menschen einfach aus den Augen verlieren. Anders als bei Twitter ist es mir wichtig, dass ich jeden persönlich kenne, der sich in meinem Facebook Netzwerk befindet.

Xing:
URL: https://www.xing.com/profile/Stefan_Wunder3
Xing bietet mir eine gute Möglichkeit meine Berufserfahrung und fachliche Kompetenz öffentlich zu zeigen. Ich bin auch Mitglied in einigen fachbezogenen Gruppen, nutze diese aber kaum – fachliche Themen finden meist auf Twitter ihren Platz.

Darüber hinaus verwende ich eher sporadisch einige andere Social Web Anwendungen, wie z.B. Flickr, Slideshare, Scribd, Quora, Mendeley und Google+.

Welche Social Web Anwendungen habt ihr im Einsatz? Wo seht ihr den persönlichen Nutzen dieser Anwedungen?

Advertisements

User Stories richtig formulieren

In der agilen Softwareentwicklung hat sich das Arbeiten mit User Stories etabliert. Eine User Story beschreibt immer eine Kundenanforderung, den dahinter liegenden Business Case, so wie den Nutzen für den Anwender und dient als Ausgangspunkt für das Entwicklerteam, so wie für die Kommunikation mit dem Kunden, Entwicklern, Product Ownern, Auftraggebern, usw. Im optimalen Fall liegen bei der Erstellung von User Stories definierte Use Cases und Personas vor, die bei der Erstellung von User Stories als Hilfestellung dienen. Der erste Teil der User Story, die High-Level Beschreibung, beantwortet immer möglichst kurz und prägnant folgende Fragen: Wer will Was, Warum tun? (Mike Cohn, 2010) verwendet dafür folgendes Template:

Als <Benutzer / Rolle> möchte ich <ein Ziel> erreichen, damit <ein Nutzen> entsteht.

z.B.: Als Webshop-Kunde möchte ich Waren in einen virtuellen Warenkorb legen, damit ich diese zu einem späteren Zeitpunkt gesammelt betrachten kann.

Wer, Was, Warum möchte ist in dieser Form eindeutig und kompakt ausgedrückt. In der Praxis ist es daher sinnvoll sich an dieses Template zu halten um die drei W-Fragen zu beantworten. Viele Product Owner und Teams meinen jedoch eine noch bessere Variante gefunden zu haben um dies zu bewerkstelligen – meiner Erfahrung nach sind diese Abwandlungen jedoch meist entweder unvollständig in der Beantwortung der W-Fragen oder schlichtweg wesentlich länger in der Beschreibung und damit schlechter verständlich.

So weit, so einfach. Eine User Story soll aber neben der Kundenanforderung auch die notwendigen Details  für die Umsetzung enthalten. Dafür werden Akzeptanzkriterien definiert. Diese sollen Fragen über das Wie, Wann und Wohin beantworten. Sie sollen außerdem als Basis für automatisierte Testfälle dienen. Ich habe mir daher folgende Form bei der Definition von Akzeptanzkriterien angewöhnt:

  • Voraussetzung: Darin werden die notwendigen Vorbedingungen (z.B. Zustand der Software, aktueller Prozessschritt, Zustand der GUI,…) definiert.
  • Auslöser: Darin wird die Aktion (z.B. User Aktion, Eingehender Request, Triggern eines Events,…) beschrieben, die den Soll-Zustand triggert beschrieben.
  • Soll-Zustand: Beschreibt den vom Kunden gewünschten Soll-Zustand mit den notwendigen technischen Details.

Ein Akzeptanzkriterium für die oben definierte Webshop User Story könnte wie folgt aussehen:

  • Voraussetzung: Der Webshop-Kunde befindet sich auf der Produktseite XY und hat die Produktoptionen (Größe, Menge, Farbe) gewählt (siehe <Link zu Mockup 1>)
  • Auslöser: Der Webshop-Kunde klickt auf den Button “In den Warenkorb legen”
  • Soll-Zustand:
    • Der Kunde sieht den Warenkorb (siehe <Link zu Mockup 2>)
    • Das Produkt befindet sich mit den gewählten Optionen im Warenkorb (siehe <Link zu Mockup 3>)
    • Die Tabelle shopping_cart enthält die Produkte, die sich im Warenkorb befinden mit allen Optionen

In der Regel sind 5-10 Akzeptanzkriterien notwendig um das Verhalten der Software ausreichend zu beschreiben. Um den Kontext und die Details näher zu Beschreiben können Klassendiagramme, Systemarchitektur-Diagramme, Mockups, Screenshots, Sequenzdiagramme, Schnittstellendefinitionen, usw. verlinkt oder an die User Story angehängt werden. Ziel ist jedoch die User Story möglichst kompakt und übersichtlich zu halten um den Fokus zu bewahren. Im Zweifelsfall ist es besser eine große User Story in zwei kleine Stories aufzuteilen.

Quellen:

Mike Cohn (2010), Succeeding with Agile Software Development using Scrum, Addison-Wesley, Kap.13, S.239

Prof. Dr. Ikujiro Nonaka in Wien

Letzte Woche hatte ich die Gelegenheit Prof. Dr. Ikujiro Nonaka bei einem Gastvortrag “The Wise Leader” an der Wirtschaftsuniversität in Wien live zu erleben. Nonaka zählt zweifellos zu den wichtigsten Wissenschaftern des Wissensmanagements – dementsprechend groß waren meine Erwartungen und meine Vorfreude. Neben mir waren hunderte Interessierte im Audi Max der WU versammelt und lauschten gespannt einem charismatischen Nonaka.

Der Vortrag war für meinen Geschmack sehr philosophisch angehaucht. Nonaka sprach viel über Visionen, Weisheit, Strategie, Innovationen und Werte, die Manager vermitteln und gestalten müssen. Vor allem sprach er über Phronesis, was er als elementaren Baustein auf den Weg zu einem “Wise Leader” sieht.

Nonaka griff auf Definition von Aristotiles zurück, der Phronesis wie folgt definierte:

“Phronesis is a virtuous habit of making decisions and taking actions that serve the common good.”

Weiters sprach (Nonaka, 2011) über sechs Fähigkeiten, die “Wise Leader” erlernen müssen um Phronesis im Unternehmen zu gestalten:

  1. Die Fähigkeit das Gute zu beurteilen
  2. Die Fähigkeit Räume (jap.: “ba”) zu gestalten
  3. Die Fähigkeit das Essenzielle zu erfassen
  4. Die Fähigkeit das Essenzielle zu kommunizieren
  5. Die Fähigkeit politischen Einfluss zu üben
  6. Die Fähigkeit Phronesis bei Anderen zu fördern

Ich möchte nun auf die sechs Punkte einzeln eingehen.

Die Fähigkeit das Gute zu beurteilen
Neben den Fähigkeiten zu Wirtschaften und zu Führen ist die Zielsetzung für “Wise Leader” moralisch und ethisch korrekt zu handeln. Werte zu vermitteln und Prinzipien zu verfolgen spielt für sie daher eine zentrale Rolle. Der Betrachtungshorizont des “Wise Leaders” geht weit über den des kapitalistisch denkenden Managers hinaus, da dieser die Frage des gesellschaftlichem Nutzens seines handelns stellt.

Die Fähigkeit Räume (jap.: “ba”) zu gestalten
Phronetische Führer gestalten Räume, in welchen ein gemeinsamer Kontext geteilt wird. Dieser gemeinsame Kontext ist die Basis für neues Wissen.

Die Fähigkeit das Essenzielle zu erfassen
Damit beschreibt Nonaka die Fähigkeit sich ständig ändernder Situationen richtig und schnell anzupassen und die richtigen Maßnahmen zu ergreifen.

Die Fähigkeit das Essenzielle zu kommunizieren
Um Andere mit Ideen und Visionen anstecken zu können, müssen Diese klar und deutlich kommuniziert werden. Der phronetische Führer beherrscht die Kommunikation des Essenziellen.

Die Fähigkeit Einfluss zu üben
Damit meint Nonaka die Fähigkeit Menschen zusammen zu bringen und sie zum Handeln anzuspornen, deren Bemühungen und Wissen zur Synthese verschmelzen zu lassen um ein gemeinsames Ziel zu verfolgen.

Die Fähigkeit Phronesis bei Anderen zu fördern
Der Phronetische Führer muss ein System schaffen, in dem Phronesis zwischen den Individuen weitergegeben wird um eine dynamische Organisation zu erreichen, die auf verändernde Bedingungen flexibel und kreativ reagieren kann.

Als Beispiele für phronetische Führer nannte Nonaka Steve Jobs und Soichiro Honda, die seiner Meinung nach die sechs Fähigkeiten des phronetischen Führens besaßen.

Nonaka betonte auch am Beispiel von Apple, dass Unternehmen “Erlebnisse” (Multimedia-Erlebnis) statt “Dinge” (iPod) verkaufen müssen, da sich erst aus dem Erlebnis ein Wert für den Kunden ergibt.

Ganz besonders spitzte ich natürlich meine Ohren, als (Nonaka, 1986) auf Scrum zu sprechen kam. Auch mit Scrum beschreibt er ein Framework, basierend auf Werten, Praktiken und Ritualen um das individuelle Wissen im Produktentwicklungsprozess besser zu verteilen, zu nutzen und produktiver zu werden und legte damit den Grundstein des heute bekannten Scrum in der agilen Softwareentwicklung.

Quellen:

Nonaka (2011), The Wise Leader, Im: Harvard Business Review, May 2011

Nonaka (1986), The New New Product Development Game, Im: Harvard Business Review, January-February 1986

Anforderungen schätzen – aber WIE?

Es gibt wohl kaum ein kontroverseres Thema in der agilen Softwareentwicklung als des Schätzen der Anforderungen. Diesen Eindruck habe ich jedenfalls, wenn ich täglich mit Product Ownern, Entwicklerteams und Scrum Mastern über die Methodik und die verwendeten Einheiten beim Schätzen diskutiere. Welche Einheit ist die beste? Sollen abstrakte Größen, wie Story Points, oder lieber absolute Größen, wie Stunden oder Personentage, für die Schätzung von Anforderungen verwendet werden? Ich habe das Gefühl, dass sich hier keine einheitliche Herangehensweise etabliert hat. Ein Blick in die Literatur zeigt auch hier keine einheitliche Meinung über die Einheit der Schätzungen:

Kent Beck sagt zum Schätzen in der 2. Auflage seines Buches “Extreme Programming Explained” folgendes:

“The first edition of Extreme Programming Explained had a more abstract estimation model, in which stories cost one, two, or three points. […] I prefer to work with real time estimated now, making all communication as clear, direct and transparent as possible.”

Boris Gloger vertritt in seinem Buch über Scrum die Meinung, dass nur eine Schätzung in abstrakten Größen (keinesfalls Zeiteinheiten) zum Schätzerfolg führt.

Mike Cohn legt sich in seinem Buch “Succeeding with Agile: Software Development Using Scrum” nicht genau fest und lässt die Entscheidung ob “Story Points” oder “Ideal Work Hours” verwendet werden bei den Teams.

Ken Schwaber und Mike Beedle unterstützen die Ansicht von zeitunabhängigen Schätzungen in ihrem Buch “Agile Development with Scrum“:

“Duration is not considered in Scrum. Work remaining and date are the only variables of interrest.”

Es sieht also fast so aus als ob hier jeder seinen eigenen Weg finden muss. Aber wo liegen die Vor- und Nachteile von konkreten bzw abstrakten Einheiten in der Praxis?

Vorteile Nachteile
Konkrete Einheiten (Personentage, Ideal Work Hours, Stunden,…)
  • Hohe Transparenz
  • Einfache Kommunikation des Aufwands
  • Kompatibilität zu traditionellen Methoden
  • Wenig Konflikte da bekannte Methode
  • Selbstbetrug durch festhalten an unrealistischen Schätzungen
  • Ungenaue Schätzungen selbst bei sehr erfahrenen Entwicklern
  • Steigerung der Velocity nicht feststellbar

 

Abstrakte Einheiten (Story Points, Kühe, Bäume,…)
  • Fokus auf Funktionalität, die dem Kunden einen Nutzen liefert
  • Genauere Schätzungen auch von unerfahrenen Entwicklern
  • Steigerung der Velocity feststellbar
  • Inkompatibilität mit Arbeitsweise anderer Abteilungen
  • Klärung was Einfluss auf die Größe der Schätzung hat ist oft schwierig (Funktionalität, Komplexität, Rahmenbedingungen,…)
  • Erhöhtes Konfliktpotential

Unabhängig welche Methode zur Anwendung kommt, sind Referenzen (z.B. Referenz User Stories) eine große Hilfe um vergleichbare Schätzungen über die Zeit und über Teams hinweg erzielen zu können. Neben der Einheit spielt auch die Schätz Methode eine wesentliche Rolle – also wie der eigentlich Prozess des Schätzens abläuft. Dazu aber in einem anderen Blogpost mehr.

8 Gründe warum ich Agile Entwicklung gut finde

Ich beschäftige mich nun seit etwa 5 Jahren mit agiler Softwareentwicklung und Lean Production Systems. Wie die meisten war ich auf der Uni wärend meiner Ausbildung mit dem gängigen Wasserfallmodell vertraut gemacht worden. Als ich dann zum ersten mal über Extreme Programming in einer Vorlesung von Univ.-Prof. Dipl.-Ing. Dr. Slany an der TU Graz hörte war die Verwirrung entsprechend groß über das was mir da erzählt wurde – die Verwirrung schlug jedoch in Neugierde um und wurde immer größer – und so begann ich mich nach erfolgreicher Absolvierung der Lehrveranstaltung mit Extreme Programming, Scrum, Kanban und Lean Production im Detail zu befassen.

Ich habe in meiner bisherigen beruflichen Laufbahn in der Softwareentwicklung beide Paradigmen (Wasserfall und Agil) im Einsatz erlebt und habe in den meisten Fällen die agile Methodik als die zeitgemäßere empfunden. Die persönlichen Gründe dafür möchte ich hier kurz zusammenfassen:

  1. Lean: Agile Entwicklung zielt auf einen “schlanken” Produktionsprozess ab. Dadurch fallen überflüssige Tätigkeiten weitestgehend weg und der Fokus richtet sich auf das nutzenbringende Produkt. “Weniger ist mehr” unter der Voraussetzung dass das, was gemacht wird, gut gemacht wird war schon immer mein Leitspruch im Studium und Beruf. Designer haben dies ja schon lange für sich entdeckt.
  2. Value: In meiner Ausbildung zum zertifizierten Value Manager habe ich viel über eine wertbasierte Denkweise im Management gelernt. In der agilen Entwicklung wird genau diese Denkweise umgesetzt – es ist oberstes Ziel die Produktentwicklung inkrementell nach dem Wert der Produktinkremente priorisiert umzusetzen um somit den Business Value stetig zu maximieren.
  3. Kollaboration: Wissensintensive Tätigkeiten bedürfen einem hohen Maß an Kommunikation und Kollaboration. Um die Vorteile der Gruppenarbeit zu erhalten wird häufig in vielen Unternehmen in Teams gearbeitet. Jedoch ist ein Team, das nicht miteinander kollaboriert wertlos. Daher definiert das agile Manifest “Kollaboration” als einen der absolut wichtigsten Kernwerte.
  4. Motivation: Wenn ich an einem Tag produktiv war gehe ich zufrieden und mit einem guten Gefühl ins Bett – das kennt ihr doch auch, oder? Agile Methoden schaffen einen Rahmen für höchste Produktivität am Arbeitsplatz und steigern dadurch das Gefühl etwas geschafft zu haben und somit die Motivation der Mitarbeiter. Weiters bieten agile Arbeitsweisen den Beteiligten viele Freiheiten und Platz zur Selbstverwirklichung – laut Herzberg der Schlüssel zur nachhatigen Motivation der Mitarbeiter.
  5. Innovationskultur: Agile Methoden hängen meiner Meinung nach thematisch sehr stark mit Innovations- und Wissensmanagement zusammen. Es ist nur in einer Unternehmenskultur, die Innovation, Kreativität, Selbstverwirklichung und persönliche Entfaltung fördert möglich agil zu arbeiten.
  6. Kreativität: Agilität heißt auf Veränderungen rasch reagieren zu können. Dabei ist ein hohes Maß an Kreativität erforderlich. Der Schlüssel jeder Innovation, eines jeden neuem Produktes oder Dienstleistung ist letztlich Kreativität.
  7. Kontinuierliche Verbesserung: Agile Methoden sehen die kontinuierliche Verbesserung als einen festen Bestandteil der Methodik. Letztlich soll nicht nur auf Veränderungen rasch reagiert werden können sondern auch gelernt werden. Ein wesentlicher Teil des Lernens in agilen Prozessen ist “Learing by doing”.
  8. Realismus: Agiler Entwicklung haftet ein gesunder Realismus an. Vor allem in der Softwareentwicklung wurde dieser viele Jahre lang durch unrealistische Deadlines, Anforderungen, Kundenwünsche, usw untergraben. Es ist nunmal meist schwieriger als man anfangs denkt ein neues Produkt zu entwickeln.

Nicht immer läuft alles in der Praxis so glatt wie oben beschrieben. Aber selbst wenn es nicht optimal läuft ist es meist besser als wenn gar kein Bewusstsein für Agile Arbeitsweisen gegeben ist. Die oben angeführten Gründe habe ich mir mehr oder weniger frei von der Seele geschrieben. Sie widerspiegeln meine persönliche Sichtweise und müssen daher nicht immer genauen Definitionen in der Theorie entsprechen. Wer diese Sichtweise  durch eigene Gedanken ergänzen möchte oder Anderer Meinung ist, ist herzlich eingeladen Kommentare zu hinterlassen 😉

Erfolgreiche Meetings planen

Was ist eigentlich ein “erfolgreiches Meeting”? – nun ich würde sagen das hängt davon ab, was man sich von einem Meeting erwartet. Für ein erfolgreiches Meeting ist es also essentiell die erzeugte Erwartungshaltung zu erfüllen. Die Planung im Vorfeld spielt da eine wesentliche Rolle.

Eine große Hilfe bei der Planung meiner Meetings war mir u.A. das Buch Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers. Dave Gray, Sunni Brown und James Macanufo beschreiben darin das 7 P’s Framework zur Meeting Vorbereitung:

  • Purpose: Welchen Zweck hat das einberufene Meeting? Durch einen klaren Zweck werden die Teilnehmer motiviert und dem gemeinsamen Zusammensitzen wird ein Sinn gegeben.
  • Product: Was soll in dem Meeting produziert werden? Mit welchem “Produkt” verlassen wir das Meeting? Die klare Kommunikation der Zielvorstellung ist wesentlich um zu jedem Zeitpunkt im Meeting den Fokus zu erhalten.
  • People: Wer muss am Meeting teilnehmen um das gewünschte Ziel zu erreichen? Welche Personen teilnehmen sollen ergibt sich aus dem Zweck und der Zielvorstellung. Es ist außerdem wichtig, dass allen Personen deren Rolle im Meeting klar ist.
  • Process: Der Ablauf des Meetings wird über die Agenda festgelegt. Diese dient vorab um den Teilnehmern den Inhalt grob zu vermitteln und während des Meetings um den “Fahrplan” einzuhalten.
  • Pitfalls: Jedes Meeting birgt individuelle Gefahren in sich. Sind die Räumlichkeiten geeignet? Gibt es die notwendige Infrastruktur? Gibt es “schwierige” Persönlichkeiten im Meeting? Es ist daher wichtig die Gefahren im Vorfeld abzuklären.
  • Preparation: Was muss vor dem Meeting noch alles erledigt werden? Darunter fällt das Vorbereiten der Präsentationsunterlagen (Flip-Charts, Folien, Ausdrucke,…) sowie alle weiteren Aufgaben, die vor dem Meeting erledigt werden müssen.
  • Practical Concerns: Wann und wo wird zu Mittag gegessen? Wer ist für die Raumreservierung verantwortlich? Jedes Meeting bedarf eines logistischen Aufwands. Dieser kann sehr unterschiedlich sein, sollte jedoch nicht vergessen werden.

Ich beachte bei jedem Meeting die 7 P’s und mache diese auch den Teilnehmern vorab transparent. Damit habe ich bisher sehr gute Erfahrungen gemacht und kann diese Praxis nur jedem weiterempfehlen.

Zum Thema “erfolgreiche Meetings” bin ich vor Kurzem auch auf einen Blogpost von Olga Repnikova von Borisgloger.com gestoßen, den ich hier noch aufgreifen möchte. Olga Repnikova unterscheidet darin 3 Ebenen der Meeting Vorbereitung:

  • Inhaltliche Vorbereitung: Hier geht es, wie der Name schon sagt, um die Definition der Inhalte und der Zielsetzung des Meetings. Leitfragen: Handelt es sich um ein Review- oder Planungsmeeting?, Geht es um Informationsaustausch und Diskussion oder sollen bereits Entscheidungen getroffen werden?, Welche Themen werden zur Sprache kommen?, Wie bin ich für die Themen vorbereitet?,…
  • Methodische Vorbereitung: Hier geht es um die Definition des Regieplans. Jedes gute Meeting hat einen spannenden Einstieg, flüssige Übergänge zwischen den Themen und einen klaren Abschluss. Leitfragen: Wie gestalte ich den Einstieg?, Wie ermögliche ich Überleitungen zwischen den Themen?, Wie schließe ich das Meeting?, Wann sind Pausen geplant?, Ist die Teilung der Gruppe erforderlich?,…
  • Organisatorische Vorbereitung: Die organisatorische Vorbereitung beinhaltet die Definition der Räumlichkeiten, Personen, Zeit, Medien, usw für das Meeting. Leitfragen: Welche Personen müssen eingeladen werden?, Wann soll die Einladung raus gehen?, Gibt es eine Teilnehmer-Mindestanzahl?, Ist das Meeting an eine bestimmte Person geknüpft?,…

Ich persönlich präferiere die 7 P’s von Gray, Brown und Macanufo zur Meetingvorbereitung, da diese meiner Meinung die ktitischen Punkte der Meeting-Planung klar hervorheben jedoch finde ich die 3 Ebenen von Repnikova eine gute Ergänzung um die Meeting-Planung auf den unterschiedlichen Ebenen klarzumachen.

Wie plant ihr eure Meetings? Was sind eure Erfahrungen, was erfolgreiche Meetings ausmacht?

Die Werte von Scrum

Bevor ich auf die Werte von Scrum eingehe, möchte ich den Begriff “Wert” erst definieren.

Der Wertbegriff ist ja in vielen Zusammenhängen zu sehen und unterscheidet sich teils sehr stark, abhängig vom Kontext, in dem er verwendet wird.

Kent Beck definiert den Begriff “Werte” im Zusammenhang mit eXtreme Programming wie folgt:

“Values are the roots of things we like and don’t like in a situation.”

Er spricht dabei von kulturellen Werten, die in einer Organisation von den Menschen gelebt werden um eine bestimmte Kultur zu etablieren. Zugegeben eine sehr generische Definition die uns jedoch für den Anfang ausreicht um den Begriff abzugrenzen.

Nun aber zu den Werten von Scrum. Im ersten Buch über Scrum, “Agile Software Development with Scrum“, beschreiben Ken Schwaber und Mike Beedle die folgenden fünf Kern-Werte von Scrum:

  • Commitment
  • Fokus
  • Offenheit
  • Respekt
  • Mut

Ich möchte nun mit meinen eigenen Worten auf die Werte im Detail eingehen:

Commitment

Scrum, wie auch XP sieht es vor, dass sich Entwickerteams zu einem gewissen Arbeitspensum commiten – d.h. dass die Teams in einer definierten Zeit (Sprint, Iteration,…) eine definierte Funktionalität entwickeln werden. Der Wille und der Mut zu commitments ist daher ein elementarer Wert in Scrum.

Fokus

Aus dem Management ist “Fokus” als strategische Erfolgsposition durch Porter bekannt. In der Softwareentwicklung ist der Fokus auf die gegenwärtige Arbeit genauso ausschlaggebend für den Erfolg eines Unternehmens. In Scrum und XP wird durch “herunterbrechen” der Anforderungen in überschaubare Tasks und durch das Arbeiten in Sprints bzw. Iterationen der Fokus auf die gegenwärtige Arbeit gelenkt. Auch tägliche Stand-up Meetings und die gegebenen Commitments führen dazu, dass alle Beteiligten immer ein Ziel vor Augen haben und dadurch fokusiert an die Arbeit herangehen.

Offenheit

Offenheit ist in Scrum in zweierlei Ausprägungen präsent. Einerseits ist die Offenheit eines jeden Einzelnen gegenüber neuen Praktiken, Techniken, Denkweisen, usw. gemeint. Auf der Anderen Seite ist damit Transparenz mit Konflikten, Anforderungen, Informationen, usw. umzugehen gemeint.

Respekt

Scrum bedeutet Teamarbeit und das geht nicht ohne gegenseitigen Respekt. Ein respektvoller Umgang beinhaltet für mich unterschiedliche Meinungen zuzulassen, eigene Schwächen und jene Anderer zu honorieren und einen entsprechenden Umgang miteinander zu pflegen.

Mut

Scrum funktioniert anders als die meisten traditionellen Unternehmen gestrickt sind. Statt Hierarchien zählen Netzwerke, statt Authorität tritt Kollaboration in den Vordergrund. Um traditionell gewachsene Strukturen zu verändern braucht es viel Mut und Courage.

Kent Beck beschreibt ähnliche Werte in seinem Buch “Extreme Programming Explained“. Meiner Meinung nach sind diese Werte ebenfalls als essentiell für Scrum anzusehen:

  • Einfachheit
  • Kommunikation

In weiterer Folge möchte ich die Begriffe noch etwas weiter ausführen.

Einfachheit

Scrum und eXtreme Programming werden auch als “lean development” – also schlanke Entwicklung – bezeichnet. In diesem Wörtchen “lean” steckt schon der Drang nach Einfachheit mit drinnen. Es soll in Scrum immer der direkte Weg zum nutzenbringenden Produkt gewählt werden, anstelle von viel Zeit in langwierige Planungen zu invesiteren, die sich über die Zeit wieder x-mal ändert. “Weniger, aber dafür richtig!” ist also das Ziel in Scrum.

Kommunikation

Software wird von Menschen entwickelt. Darum ist Kommunikation ein elementarer Bestandteil der Softwareentwicklung selbst. Um ehrlich zu sein denke ich dass die mit Abstand meisten Probleme in der Softwareenwicklung Kommunikationsprobleme sind. Immer dann wenn Wissen von einer Person an eine andere Person übermittelt wird kann es, abhängig von der Art der Übermittlung, beim Wissenstransfer zu mehr oder weniger Missverständnissen kommen. Im Wissensmanagement spricht man von direktem Wissenstransfer, wenn sich zwei Personen face-to-face gegenüber stehen während diese kommunizieren, im Gegensatz zum indirektem Wissenstransfer, der über Dokumente oder technische Systeme abgewickelt wird. Besser für die “fehlerfreie” Kommunikation ist der direkte Wissenstransfer, da hier der Empfänger mit Feedback (Worten, Gestik, Mimik,…) direkt reagieren kann und so mehr Aspekte in die Kommunikation einfließen. Das ist aber ein großes Thema und ist daher einen eigenen Blogpost wert.

Zugegeben klingt das alles sehr abstrakt und vieles erscheint auf den ersten Blick als allzulogisch – doch wozu braucht es nun diese Werte für Scrum überhaupt?

Hier komme ich wieder auf die Unternehmenskultur zu sprechen. Es ist aus meiner Sicht unabdingbar für das Funktionieren von Scrum eine Kultur im Unternehmen zu schaffen, bei der die Werte von Scrum höchsten Stellenwert haben und gelebt werden.