Eine deutschsprachige Einführung in Doctrine 2 ORM von mir gibt es jetzt bei Slideshare.

PS: Mehr zu mir, also dem Autor dieses Artikels, finden Sie hier im Blog auf meinem Profil.

Sie wollen mit Google AdWords starten? Da schenke ich Ihnen doch gerne 100 Euro Werbebudget! Das sind 100 oder mehr potentielle Käufer Ihrer Produkte oder Nutzer Ihrer Dienstleistung und das ohne jegliche Verpflichtung für Sie. Ist das Budget aufgebraucht, müssen Sie nicht weiter investieren, wenn Sie nicht wollen.

Schicken Sie mir eine kurze Nachricht und ich sende Ihnen einen Gutschein zu.

Hinweis: Dieses Angebot richtet sich nur an Neukunden, die aktuell noch keinen AdWords-Account haben. Für bestehende Accounts kann der Gutschein leider nicht verwendet werden.

PS: Mehr zu mir, also dem Autor dieses Artikels, finden Sie hier im Blog auf meinem Profil.

Manchmal frage ich mich, ob wir seit der Erfindung des Internets und dessen Verbreitung, so wie wir es heute kennen, nicht eigentlich große Teile der Evolution erneut beschreiten. Conversion Optimierung ist da so ein Thema. Ich glaube, ich kenne keinen Supermarkt, der nicht so gestaltet ist, dass der Absatz durch geschickt platzierte Schokoriegel im Kassenbereich gefördert und die Kaufwahrscheinlichkeit durch optimierte Einkaufswege durch den Laden erhöht wird. Selbst der Spätkauf bei mir um die Ecke macht das so. Und das nicht erst seit gestern, sondern seit mindestens mal zehn Jahren. Das die Schachtel Kelloggs nicht in jenem Regalfach, das 5 Meter über dem Boden entfernt ist, aufgestellt wird, damit es auch Jemand kaufen kann, ist selbst für nicht-Fachleute einleuchtend. Das der Weg zur Kasse nicht durch Kartons vollgestellt, das Kassenband erwartungsgemäß funktioniert und meine EC-Karte auch tatsächlich vom Gerät gelesen wird, ist nicht minder logisch. Im Web nennen wir das dann “Usability Optimierung”, machen eine Wissenschaft draus und fühlen uns wie die Versteher der Welt. Streckenweise ist das alles schon sehr peinlich.

Heute in meinem RSS-Reader stolpere ich über den “Social Media Tipp des Tages: Hören Sie zu!”. Ach? Das ist ja mal ganz was Neues. Wenn man seinem Gesprächspartner auch mal zuhört, stellt sich eine gute Kommunikation ein. Ich glaube, dass gilt so ziemlich seit Menschengedenken. Aber gut, dass wir das im Web jetzt auch zur Kenntnis nehmen. Übrigens sind Ehrlichkeit, Aufrichtigkeit und ein angemessener Tonfall samt passender Wortwahl auch sehr hilfreich für den Aufbau von menschlichen Beziehungen. Damit habe ich dann jetzt meinen Beitrag dazu geleistet, dass wir als User gemeinsam mit dem Web weiter unseren Kinderschuhen entwachsen. Wahnsinn. Ich wüsste so gern, wie die Zeit kurz nach Erfindung des Telefons bzw. nach dessen initialer, flächendeckender Verbreitung wohl so war. Vermutlich haben sich alle Leute wie wild ständig angerufen, einfach nur des Anrufens wegen und weil man sich so gefreut hat, dass man jetzt auch auf diesem Wege mit einander kommunizieren konnte. Komisch, irgendwie erinnert mich das grad alles an Handys, SMS und an …. Facebook. Manchmal frage ich mich, ob das Web wirklich so eine Hochtechnologie ist, für die Viele sie halten und wie sie landläufig ja gerne wahrgenommen wird.

Was lernen wir daraus: Die “physische (Konsum-)Welt” ist für jeden Onliner mehr als einen flüchtigen Blick wert, auch, wenn Sie längst totgesagt ist. Außerdem sollten wir uns nicht für so wichtig nehmen. Auch wenn das Internet alles verändert, Vieles zum positiven, so ist die ganze Branche in vielen Bereichen weiterhin eine ganz kleine Nummer und wir müssen noch viel, viel lernen. Wir sollten viel selbstkritischer sein. Und weniger arrogant. Und bitte lasst uns auch mal damit aufhören, ständig dieses “Optimization” an jede Tätigkeit anzuhängen. Das klingt viel zu final, viel zu nach dem heiligen Gral. Ein Produkt ist niemals fertig. Die Conversion niemals optimal. Außer vielleicht wenn Sie bei 100% läge. Wenn jemand so ein Business hat, würde ich gerne mitmachen. Aber wir schweifen ab. Wie wäre es mit “Improvement”? Wäre das nicht viel treffender und inbesondere … ehrlicher? Ich verstehe ja auch nach wie vor nicht, wieso SEO eigentlich SEO heißt und wieso wir das nicht mal ändern.

PS: Mehr zu mir, also dem Autor dieses Artikels, finden Sie hier im Blog auf meinem Profil.

Startet man als CTO (oder als “Lead Developer” oder “VP Engineering” oder “IT-Abteilungsleiter” oder …) in einem (Startup-)Unternehmen, dass bereits eine weile Bestand hat, so steht man in aller Regel nicht auf der “grünen Wiese“, sondern sieht sich zunächst einmal mit einer ganzen Reihe von gewachsenen Strukturen, Prozessen und Tools konfrontiert. Ganz im Sinne von Kanban, das eine Evolution zum Besseren einer radikalen Revolution des Status Quo vorzieht, sollte der Neu-CTO zunächst einmal all seine Energie darauf verwenden, die Ausgangssituation genau zu verstehen (übrigens auch dann, wenn er später nicht Kanban, sondern Scrum oder Wasserfall macht ).

Ein paar wichtige Dinge noch vorab, die eigentlich immer Gültigkeit haben, aber besonders auch für Neu-CTOs gelten :

• In aller Regel setzt ein Unternehmen nicht die aktuellste Technik ein. Auch wenn man also immer gerne sofort “the latest & greatest” einsetzen möchte, so ist dies schlichtweg nicht immer möglich und auch nicht immer sinnvoll. Arrangieren Sie sich zunächst mit dem Status Quo. Wertschätzen Sie die Leistung des Teams und der Organisation, so weit mit den verfügbaren Mitteln gekommen zu sein. Reden Sie nicht am ersten Tag schlecht über die aktuelle Situation. Diese Einstellung bedeutet allerdings auf der anderen auch nicht, dass man einfach damit lebt und nichts zum Besseren verändern will. Natürlich wollen Sie das. Aber eben auf einem positiven Fundament. Sie wollten ja nicht gleich als Miesepeter und Besserwisser gelten.
• In aller Regel sind die Prozesse in einem Unternehmen nicht ideal. Auch wenn man also immer gerne sofort Alles automatisieren und optimieren will, so ist dies schlichtweg nicht immer möglich und auch nicht immer sinnvoll. Prozesse sind fast nie bewusst “engineered” (und selbst dann ist das ja keine Garantie für Qualität), sondern haben sich im Laufe der Zeit aus der Situation heraus so etabliert.
• In aller Regel sind die Produkte oder Dienstleistungen, die ein Unternehmen verkauft oder erbringt, nicht optimal. Eigentlich sind Sie das nie. Und wichtig ist insbesondere, dass man die Probleme nicht alle sofort und über Nacht beheben kann. Fast immer gibt es viel mehr Verbesserungsideen, als man direkt umsetzen kann. Auch mit offensichtlichen Problemen müssen Sie also mal eine Weile Leben können. Haben Sie ein wenig Geduld. Gleiches gilt übrigens auch für eingesetzte Tools. Auch die haben immer Ecken und Kanten. Es gibt immer etwas zu Verbessern.
• Andere Menschen haben andere Ansichten. Etwas, das Sie selbst für verrückt oder falsch halten, es ist es nicht zwangsläufig. Häufig haben Sie nur eine andere Sichtweise und vor allem andere Erfahrungen, die Sie zu diesem Urteil bringen. Seien Sie nicht zu schnell mit dem “in eine Schublade stecken” und verteufeln. In aller Regel existieren Dinge nicht vollkommen ohne Grund. Oftmals ist der eigentlich Grund nur nicht sofort ersichtlich, aber irgendjemand wird sich irgendwann irgendetwas dabei gedacht haben.

So, jetzt aber. Die folgende Aufstellung hat ganz bewusst keinen Anspruch auf Vollständigkeit sondern ist viel mehr mein persönliches “Logbuch“. Schaut man aus einer anderen Brille, so ergeben sich sicherlich zusätzliche oder andere Fragestellungung. Zudem habe ich administrative Themen des “Vorgesetzten-Daseins” nahzu vollständig ausgeklammert.

Team

• Wer sind die Mitarbeiter im eigenen Team?
• Wie ist die Aufbauorganisation im eigenen Team?
• Über welche Kenntnisse und Fertigkeiten verfügen die Mitarbeiter?
• Welche Rollen sind vorhanden?
• Sind aktuell Stellen zu besetzen oder sollen Stellen abgebaut werden?

Kontext & Umwelt

• Wer sind die internen Auftraggeber (Upstream)?
• Wie genau kommen die Aufträge in meinen Bereich?
• Für wen agiere ich intern als Auftraggeber (Downstream)?
• Wie genau stelle ich Aufträge nach “Downstream”?
• Mit welchen internen Dienstleistern wird zusammengearbeitet? Wie “exklusiv” ist der Zugriff?
• Mit welchen externen Dienstleistern wird zusammengearbeitet?
• Welche Vorschriften von öffentlichen Stellen finden Anwendung für den eigenen Bereich / die eigene Tätigkeit?
• Wie sehen die Eskalationsprozesse aus?

Leistungskatalog

• Welche Leistung werden von meinem Bereich erbracht?
• Gibt es definierte SLAs für die Leistungserbringung? Wenn ja, welche?
• Welche Prozesse zur Leistungserbringung existieren in meinem Bereich? Wer ist beteiligt?
• Wie gliedern sich die Prozesse des eigenen Bereichs in die übergreifenden Geschäftsprozesse ein? Wie sehen die Geschäftsprozesse von “Ende-zu-Ende” aus?

Systeme, Software & Architekturen

• Welche Anwendungen / Aspekte werden selbstständig entwickelt und betrieben?
• Welche Technologien werden dazu eingesetzt?
• Wie sieht das Domänen Model aus, in dessen Umfeld die Anwendungen eingesetzt werden?
• Wie sehen die Datenstrukturen aus?
• Wie und wann werden neuen Versionen released?
• Welche Verbindungen gibt es zwischen separaten internen  Systemen? Wie sind diese realisiert?
• Welche externen Systeme (Standardlösungen) werden eingesetzt?
• Welche Verbindungen zu externen Systemen existieren? Welche Daten werden ausgetauscht, welche Funktionen bereitgestellt?

Tools

• Für welche Ausfgaben oder Prozesse werden Tools eingesetzt?
• Welche Tools werden eingesetzt?
• Wer ist verantwortlich für den Betrieb und die Wartung der einzelnen Tools?
• Welche Dokumentationssysteme gibt es?
• Wer ist für Aktualität der in Dokumentationen und Wikis vorgehaltenen Informationen verantwortlich?

IT-Infrastruktur

• Aus wechen Komponenten / Netzen besteht die Infrastruktur?
• Für welche Komponten wird die Wartung selbst durchgeführt, wofür Dienstleister eingesetzt?
• Gibt es Single Points Of Failures (SPOF) in der IT-Infrastruktur? Wenn ja, welche? Wird das Risiko aktuell bewusst eingegangen?
• Wie schnell kann der Betrieb nach Ausfalls eines SPOFs wieder hergestellt werden?
• Wo sind aktuell Kapazitätsflaschenhälse?
• Gibt es eine Test / Staging – Umgebung für Applikationen?
• Welche Zugangskontrollen sind implementiert?
• Wie steht es um die “Evergreens”? Datensicherung? Recovery? Security? Wie sind Abläufe, Notfallrufnummern und wer sind die handelnden Personen?

Projekte

• Welche Projekte werden derzeit bearbeitet?
• Wie ist in den laufenden Projekten der Status?
• Welche Projekte sind für die Zukunft geplant? Existiert eine Roadmap?
• Nach welche Kriterien werden Projekte priorisiert?
• Von wem werden Projekte priorisiert, wie werden Projekte finanziert?
• Welche Projekte wurden in der Vergangenheit durchgeführt und wie war deren Ergebnis?

Performance, Finanzen & KPIs

• Welches Budget ist eingeplant? Wie ist die aktuelle Soll/Ist – Situation?
• Mit welchen KPIs wird die Qualität und Quantität der Leistung vom zu verantwortenden Unternehmensbereich gemessen?
• An wen, in welchem Umfang und in welcher Form werden diese KPIs reported?
• Welche KPIs existieren für andere Unternehmensbereiche und wie wirken sich die eigenen KPIs auf ebenjene aus?

Außenwahrnemung & Kundenzufriedenheit

• Wie ist die gefühlte Außenwahrnumung des eigenen Bereichs?
• Wie ist es um die Kundenzufriedenheit Upstream und Downstream bestellt?
• Welche Situationen, Aussagen oder Probleme sind “typisch” für den eigenen Bereich?

Strategie

• Welcher Strategie folgt der zu verantwortenden Unternehmensbereich bis dato?
• Welche Strategie / Taktik wird vom Unternehmen verfolgt?
• Welche bekannten Probleme und Herausforderungen bestehen aktuell für den Bereich und das Unternehmen?

PS: Mehr zu mir, also dem Autor dieses Artikels, finden Sie hier im Blog auf meinem Profil.

Für alle Product Owner, die noch nach einem pragmatischen Tool zur Release Planung und zur Unterstützung der Product Backlog Priorisierung suchen, stelle ich gerne meine Excel / Google Docs Product Roadmap – Vorlage zur Verfügung, die sich in den letzten Monaten für mich als hilfreich und praktikabel herausgestellt hat. Schauen wir uns Schritt für Schritt für Kernelemente der “Product Roadmap” an, damit Sie die Vorlage sofort produktiv einsetzen können.

Struktur

Grundsätzlich besteht das Template aus den 3 Kernelementen: “Theme Data”, “Scoring” und “Timetable” (von links nach rechts).

Theme Data

Die Spalten im Bereich “Theme Data” (links) bündeln alle Meta-Informationen zu einem Theme:

• ID: Eindeutiger und dauerhafter Schlüssel für ein Theme.
• Theme: Bezeichnung des Themes.
• Owner: Verwantwortlicher / Initiator und damit erster Ansprechpartner bei Fragen.
• Added: Datum, an dem die Initiative zum Backlog hinzugefügt wurde. Dies ist vor allem hilfreich, wenn man irgendwann mal das Backlog aufräumen und “Karteileichen” entfernen will.

An dieser Stelle ein paar zusätzliche Erklärungen: Ein Theme ist die Gruppierung von logisch zusammenhängenden User Stories. Ich arbeite auf der Ebene der Priorisierung und Releaseplanung nicht mit User Stories, sondern mit ebenjenen Themes und richte mich damit nach dem Empfehlungen von Mike Cohn. Ein Theme repräsentiert dabei in aller Regel ein MMF (Minimum Marketable Feature), auch, wenn letztendlich mehrere User Stories zu dessen Realisierung erforderlich sind. Schlussendlich macht die Bearbeitungsreihenfolge der User Stories innerhalb eines Themes keinen Unterschied mehr und ist stattdessen häufig von logischen Abhängigkeiten unter den Stories geprägt. Die einzelnen User Stories zu den Themes verwalten ich in anderen Systemen oder in einen anderen Tabellenblatt. Wichtig ist dabei nur, das die Verbindung von Themes und User Stories gegeben ist. Durch den Einsatz einer eindeutigen und dauerhaften ID für jedes Theme ist das ja allerdings kein Problem. Es wäre aber natürlich auch denkbar, die Vorlage direkt mit User Stories zu füllen. Fühlen Sie sich also frei, die Vorlage so zu verwenden, wie sie für sie zweckmäßig ist.

Scoring

Über das Scoring wird die Wichtigkeit eines Themes bestimmt und damit dessen Priorität und Position auf der Roadmap. Je wichtiger ein Theme, desto schneller wird es umgesetzt. Da der Scoring-Prozess etwas sehr individuelles ist, hier ein paar Fragen, die Sie zunächst für sich beantworten sollten:

• Welche Eigenschaften eines Themes haben Einfluss auf die Bewertung der Priorität? Ich verwende etwa die folgenden Eigenschaften nach denen alle Themes bewertet werden: “Strategic Fit”, “Revenue” und “Costs (oder: Aufwand)”.
• Welches Gewicht haben die Eigenschaften jeweils? Der Einfachheit halber bin ich dazu übergegangen, alle Eigenschaften mit dem gleichen Gewicht auszustatten. Das muss allerdings nicht so sein und Sie können die Gewichtung entsprechend problemlos in der Vorlage justieren.
• Welche Werte pro Eigenschaft sind möglich? Ich nutze, analog zum Vorgehen bei der Aufwandsschätzung von User Stories, die bekannte, an die Fibonnaci-Folge angelehnte Staffelung: 0, 1, 2, 3, 5, 8, 13 (und gelegentlich: 20). Sie können allerdings auch Werte von 1 bis 5 oder sonstige numerische Reihen Ihrer Wahl verwenden.
• Wer setzt die Bewertungen wann fest? Legen Sie als Product Owner die Bewertung alleine fest? Oder agieren Sie in einem komplexeren Umfeld und benötigen einen Product Council zur Bestimmtung der Prioritäten?

Das Scoring-Element lässt sich übrigens auch reduziert darstellen und gibt dann nur noch den errechneten Gesamtscore pro Theme aus. Das ist oftmals vollkommen ausreichen und gibt insb. dem Timetable mehr Platz auf dem Screen.

Timetable

Auf Basis der Kosten- /Aufwandsbewertung im Scoring können nun unter Berücksichtung der ermittelten Velocity des Realisierungsteams und einem auf diesem Wert definierten “Wechselkurs” für Theme Points und Story Points die einzelnen Initiativen auf die Zeitleiste projiziert werden. Im Timetable ist zudem markiert, welche Blöcke/Themes bereits erledigt sind (grün) und welche noch ausstehen (grau). Zusätzlich kann die aktuelle Kalenderwoche in der Spaltenüberschrift farblich hervorgehoben werden. Das erleichtert die tägliche Arbeit mit dem Dokument.

PS: Mehr zu mir, also dem Autor dieses Artikels, finden Sie hier im Blog auf meinem Profil.

Seit einigen Tagen arbeite ich mich in freien Minuten durch “Kanban” von David J. Anderson, dem Standardwerk zu Kanban in der Softwareentwicklung vom Erfinder höchstpersönlich. Kanban ist seit einiger Zeit das neue “Hype-Thema” in der agilen Welt und wird von vielen als das “bessere Scrum” gefeiert. Dieser Artikel ist eine Art Einführung in Kanban für Scrum – Anwender und stellt das Ergebnis meiner persönlichen Auseinandersetzung mit dem Thema und insbesondere dem Buch dar. Ich selbst habe verschiedene Scrum-Zertifizierungen und bin seit Jahren Anwender in den verschiedenen Rollen wie Scrum Master, Product Owner und Developer. Ich denke, dass ich ein gutes Verständnis für Scrum entwickelt habe und bereits ausreichend praktische Erfahrung gesammelt habe, um diesen Vergleich anzustellen. Leser sollten ein Grundverständnis von Scrum mitbringen, um möglichst viel aus dem Artikel für sich herausziehen zu können.

Prolog

Scrum ist ein Framework. Kanban ist es nicht und ist damit im Grunde gar nicht mit Scrum vergleichbar. Übrigens spreche ich im Folgenden, wann immer ich den Begriff Kanban verwende, von “Kanban in der IT”, also der Anwendung der von Toyota entwickelten Produktionsablaufsteuerung auf die Prozesse zur Herstellung von Software. Da sich das klassische Kanban und “Kanban in der IT” durchaus unterscheidet, ist deren Abgrenzung grundsätzlich wirklich wichtig.

Was ist nun also Kanban, wenn es denn kein Framework für Softwareentwicklungsprozesse ist? Es ist eine Change Management Methode. Es unterstützt grundsätzlich also erst einmal dabei, von A nach B zu kommen und das möglichst elegant. Allerdings skizziert Kanban auch bereits das “B”, den angestrebten Idealzustand, wenn auch nicht so deutlich wie Scrum das tut. Für mich ist Kanban ein wenig das “Refactoring”, wenn Scrum das “Neubauen” ist, wenn ich es einmal so im “Programmier-Sprech” ausdrücken darf. Während Scrum eine ganze Reihe von neuen Rollen, Prozessen und Ritualen quasi über Nacht in einem Unternehmen etablieren will und bestehende Konstrukte dabei in aller Regel vollständig überworfen werden, geht Kanban einen anderen Weg: Zunächst wird der Ist-Zustand der internen Abläufe transparent gemacht und visualisiert. Von dort ausgehend werden die einzelnen Teilaspekte des Status Quo begutachtet und mit Hilfe verschiedener Methoden und Instrumente optimiert, bis ein verbesserter Zustand erreicht ist. Dabei ist Kanban weniger dogmatisch als Scrum und verlang in letzter Instanz keine fix definierten Rituale wie Sprints, Planungs- und Review-Meetings oder Retrospektiven, auch, wenn insbesondere Letzteres auch bei Kanban von größter Wichtigkeit ist. Es ist also erlaubt, was funktioniert. Das ist bei Scrum im fortgeschrittenen Stadium zwar ähnlich, aber eben selten bis nie zu Beginn. Scrum bereits im Rahmen einer Einführung zu modifizieren halte ich im übrigen auch für gar nicht sinnvoll.

So unterschiedlich Kanban und Scrum also sind, so verfolgen sie in letzter Instanz doch das gleiche Ziel: Die Optimierung der internen Abläufe im Rahmen der Softwareentwicklung im Bezug auf Wirkungsgrad, Kalkulierbarkeit und Qualität der erzielten Ergebnisse. Viel mehr noch geht es aber um die Transformation einer Organisation zu einer durch Retrospektiven über die eigenen Tätigkeiten reflektierenden und ständig nach Verbesserung strebenden Gruppe von Menschen, die einander vertraut und miteinander in einem inspirierenden und fördernden Umfeld agiert, um Großartiges zu leisten.

Pull-Prinzip

Das Pull-Prinzip ist einer der Eckpfeiler von Kanban. Es sagt, dass neue Arbeit geholt wird, wann immer (an der jeweiligen Station) Kapazität dafür vorhanden ist. Ein ähnliches Prinzip gibt es bei Scrum mit dem “Sprint Commitment”: Das Team nimmt sich zu Beginn ein definiertes Arbeitspaket für die nächste Iteration. Dabei gilt, dass das Team entscheidet, wie viel es zu leisten vermag. In Kanban hat das Pull-Prinzip einen größeren Stellenwert und ist durch den differenzielen Flow (siehe auch nächster Punkt) kleinteiliger als bei Scrum. Aber das Kernelement ist hier sehr ähnlich: Nicht Vorgesetzte oder das Management entscheidet in letzter Instanz, wie viel Arbeit ein Team in einem definierten Zeitintervall leisten kann, sondern das Team selbst. Die Anmaßung vergangener Tage, als “Chef” besser einschätzen zu können, wie aufwändig es ist oder auch nicht ist, ein bestimmtes Feature zu entwickeln, sollte mittlerweile hoffentlich weitestgehend passe sein. Falls nicht, schauen Sie doch mal nach einem neuen Job.

Flow

Während das klassische Scrum-Board mit den Spalten “Todo”, “In Progress” und “Done” den Bearbeitungsstatus eines Tasks darstellt, nutzt ein Kanban-Board diese Dimension zur Abbildung der einzelnen Bearbeitungsschritte. Innerhalb von “In Progress” herrscht bei Scrum ja so etwas wie das kontrollierte Chaos. Zwar werden die User Stories zunächst in Tasks heruntergebrochen und somit das Vorgehen strukturiert, allerdings folgt ebenjenes im Weiteren keinem definierten Ablauf. Das Team muss selbst dafür sorgen, das Abhängigkeiten erkannt und aufgelöst und blockierende Aufgaben sinnvoll “eingetaktet” werden. Hier stellt Kanban doch eher einen Gegenpol dar und würde mit Spalten wie “Technische Konzeption”, “Screendesign”, “Programmierung”, “Test”, “Dokumentation”, etc. die einzelnen Arbeitsschritte abbilden. Schaut man noch etwas weiter “Upstream” und “Downstream”, so könnte das Board durchaus um Spalten wie “Priorisierung”, “Konzeption” und “Aufwandsschätzung” oder “Deployment”, “Internes Annoucement” und “Externes Announcement” erweitert werden. Arbeitet man mit einem Kanban-Board, auf dem der Flow so detailliert abgebildet ist, können sich auf dem Board sogar die User Story – Karten selbst bewegen. Task-Karten sind dann nur noch selten erforderlich.

Die geschaffene Transparenz kann dabei helfen, den Flaschenhals auf detaillierterem Niveau zu erkennen. So wird mit Hilfe eines Scrum-Boards schnell deutlich, wenn etwa der Designer im Team überlastet ist und Verzögerungen im Entwicklungsprozess verursacht, was sich letztendlich in der Gesamtleistung des Teams negativ wiederspiegelt. Scrum-Teams entdecken solche Engpässe in aller Regel auch und bringen diese Tatsache spätestens im Rahmen der Sprint-Retrospektive zur Sprache, so dass nach Verbesserungsmöglichkeiten gefahndet werden kann.

Limit Work-In-Progress

Ein weiteres Kernelement von Kanban ist “Limit Work-In-Progress”, oder anders: Mach’ nicht zu viele Baustellen gleichzeitig auf. Ich halte diese Devise grundsätzlich für sehr sinnvoll und nicht nur im Rahmen von Kanban für ein Schlüsselelement produktiver Unternehmen. Während bei Scrum die maximal in einem Zeitintervall zu bearbeitende Menge “paralleler” Arbeit durch das Sprint Commitment gegeben ist, geht Kanban hier einen Schritt weiter und limitiert Arbeit auch “pro Station”. So gibt es etwa niemals mehr als 2 Work Items im Schritt “Konzeption” oder “Programmierung”. Durch den Einsatz von Puffern wird vermieden, dass Abläufe ins Stocken geraten. An dieser Stelle wird auch Kanban, so einfach der Ansatz auf den ersten Blick auch erscheint, durchaus kompliziert und dessen erfolgreiche Anwendung zu einer echten Herausforderung, denn solche Limits müssen individuell identifiziert und festgelegt werden.

Ich habe in Scrum-Teams gute Erfahrung damit gemacht, die parallele Arbeit auch dahingehend zu begrenzen, dass nur 2 maximal 3 User Stories gleichzeitig Tasks im Status “In Progress” haben dürfen. Das hilft, Dinge fertig zu kriegen und nicht die Implementierung aller User Stories des Boards irgendwie zu starten aber am Ende im schlimmsten Fall keine davon richtig zu Ende zu bringen.

Work Item Types

Während in Scrum offiziell nur User Stories an das Task Board gehängt werden, gibt es in Kanban das Konzept der unterschiedlichen “Work Item Types”. Angefangen bei “Bug” über “Maintenance” bis hin zu “Refactoring”, “User Story” und ggf. zusätzlichen Typen. Ebenso wie der Flow in Kanban etwas situationsspezifisches ist, so sind es auch die “Work Item Types”. Wenn es eine Sache in Scrum gibt, die für mich bislang am wenigsten gut funktioniert hat, dann ist es die nicht-projektbasierte (Weiter-)Entwicklung und insbesondere der Betrieb einer bereits produktiven Anwendung. In meiner Tätigkeit als CTO bei erento entwickeln wir etwa unser Produkt, die erento Miet-Marktplätze, zwar kontinuierlich weiter, in dem wir neue Features realisieren, verwenden aber einen großen Teil der verfügbaren Kapazitäten auch drauf, das bestehende System zu betreiben. Und dazu gehört vor allem die Beseitigung von Defekten als auch das kontinuierliche Erledigen von Kleinstaufgaben im Tagesgeschäft (ich nenne sie “Dailies”), die weder den Charakter eines Defektes noch den einer User Story haben und dessen Erledigung in aller Regel auch nicht bis zur nächsten Iteration warten kann. Dazu zählen zum Beispiel händische Modifikationen an den Anwendungsdaten (siehe auch: Das simulierte Feature), Anpassungen an Grafiken und Texten oder die Umsetzung von Kleinstanforderungen, für die ebenfalls teils Entwicklerkapazitäten beansprucht werden. Als ich vor einigen Jahren das erste Mal von Kanban gehört hatte, tauchte es vor allem immer wieder im Zusammenhang mit den Begriffen “Wartung” und “Betrieb” auf. Hier erscheint mit Kanban eine wirklich Bereicherung zu sein. In Scrum kann ich zwar auf dem Taskboard eine “Bugs”-Zeile einrichten, die Bearbeitung hat aber keine planerische Verbindung zum Commitment des Sprints. Das wiederum macht es sehr schwierig, überhaupt ein Sprint Commitment abzugeben. Mit den Dailies ist es noch schwieriger.

Iterationen

Das Schlagwort “Iteration” taucht im Index von Anderson’s Buch nicht auf. Sie spielen in Kanban also keine Rolle und passen irgendwie auch gar nicht ins Bild. Dadurch, dass die Work Items über das Board wandern und sich ständig die Auslastungssituation an den einzelnen Stationen ändert, können neue Work Items prinzipiell jederzeit in den Flow hineingezogen werden und auch den Flow wieder verlassen. Zwar wäre es denkbar, Work Items zu “Releases” zu bündeln, die am Ende des Flows angekommen sind, etwa weil man die Transaktionskosten für das Release (siehe nächster Punkt) gering halten will, aber es besteht eben kein Zwang. Wenn wir beim Thema Deployments bleiben und die Organisation über eine stabile Continuous Integration und Deployment Infrastruktur verfügt, im Idealfall gepaart mit einer Batterie automatisierter Tests, so spricht nichts gegen häufige Ad-hoc-Releases.

Aufwände

Kanban geht auch auf die Tatsache ein, dass etwa neben der reinen Programmierung eines neuen Features auch weitere Aufwände entstehen. Anderson unterscheidet dabei in “Transaction Costs” und “Coordination Costs”, wobei “Transaction Costs” als vor- und nachbereitende Aufwände zu verstehen sind, etwa für das Deployment eines fertig programmierten neuen Features. “Coordination Costs” sind Aufwände, die entstehen, um die gemeinschaftliche Arbeit zu planen.

Gerade diese Blickwinkel sind es, die es in Scrum so explizit nicht gibt. Ein erfahrener Scrum-Anwender würde natürlich immer auf die Retrospektive verweisen und anmerken, dass ein gut funktionierendes Scrum-Team in der Retrospektive über Hindernisse und übermäßige “Transaction / Coordination Costs” sprechen würde, allerdings muss man da erst einmal hinkommen und so professionell reflektieren, dass Probleme dieser Art überhaupt erkannt und zur Sprache gebracht werden. Daher finde ich es sehr sinnvoll, dieses Thema in Kanban so explizit zu thematisieren.

Kontinuierliche Verbesserung

Während in Scrum die Sprint Retrospektive das Tool zur kontinuierlichen Verbesserung darstellt, so wird bei Kanban ebenfalls die nachhaltige Verbesserung (Kaizen) angestrebt. Im “Großen” gibt es bei Kanban ein definiertes Instrument der Reflektion: Das Operations Review Meeting, sozusagen die Retrospektive für die gesamte Organisation. Beim Lesen des Kanban Buchs kam es mir allerdings ein wenig so vor, als wäre das Operations Review Meeting kein wirklicher Bestandteil von Kanban, sondern eher ein Best Practice, den Anderson einem sehr ausdrücklich ans Herz legt. Ein Retrospektive-Meeting für das “Realisierungsteam”, so wie in Scrum, gibt es in Kanban nicht. Stattdessen werden die Daily Stand-Up Meetings dazu verwendet zu reflektieren. Während beim Daily Scrum traditionell ja die 3 Fragen

• Was habe ich seit dem letzten Daily Scrum erreicht?
• Was will ich bis zum nächsten Daily Scrum erreichen?
• Was hindert mich im Moment daran, meine Arbeit zu machen?

beantwortet werden, wird bei Kanban darauf verzichtet. Oder anders: Es ist nicht fest definiert, was im Stand-Up passiert. Durch den hohen Grad an Transparenz der einzelnen Arbeitsschritte auf dem Board (siehe weiter oben unter “Flow”) wird in der Regel kaum noch Zeit darauf verbracht über das zu sprechen, was erledigt wurde – es ist in aller Regel jederzeit für jeden auch so ersichtlich, wer woran arbeitet und wer was erledigt hat. Im Großen und Ganzen sind sich Kanban und Scrum hier allerdings sehr ähnlich. Es geht darum, kontinuierlich an sich zu arbeiten, als Individuum, Team und Organisation. Die Tools sind andere oder abgewandelte, aber unter dem Strich gibt es viele Parallelen.

Product Backlog & Priorisierung

In Scrum entscheidet der Product Owner über die Wichtigkeit der Product Backlog Items. Wie der Product Owner die Reihenfolge tatsächlich bestimmt, dazu gibt es in Scrum keine Aussage. Bei Kanban wird im Gegensatz zu Scrum übrigens kein Product Backlog gefordert, dass den DEEP-Kriterien entspricht, das also insb. jederzeit vollständig priorisiert ist und in dem alle Items im Aufwand geschätzt sind. Stattdessen wird ganz nach Japanischen Vorbild die Entscheidung, welche Items als nächstes an der Reihe sind, so spät wie nur irgend möglich getroffen, also genau in dem Moment, in dem Slots im Eingang des Flows frei werden.

Einführung im Unternehmen

Während im Scrum-Umfeld ein Dehnen der Regeln  und Anpassungen wenn überhaupt erst zu einem späteren Zeitpunkt empfohlen werden, geht Kanban davon aus, dass jedes Unternehmen eine individuelle Implementierung benötigt. Scrum in eine bestehende Organisation mit bekannten Abläufen und Denkmustern einzuführen ist je nach Situation schwierig bis sehr schwierig. Die meisten gescheiterten Scrum-Projekte oder Implementierungen in Organisationen, die ich kennengelernt habe, waren nahezu immer darauf zurückzuführen, dass der Wechsel von bestenden Strukturen und Abläufen hin zu Scrum mit seinen teils diametral andersartigen Ansätzen die Organisation überfordert hat. Die Einführung von Kanban gestaltet sich zunächst einmal einfacher als die von Scrum, weil es keine Prozesse oder Rituale vorgibt, die eine Organisation installieren muss. Stattdessen gibt eine Reihe von Empfehlungen wie oben beschrieben, u.a. Limit WIP. Auf Grund dieser Tatsache können im Idealfall umfassende Change-Management-Projekte zur der Einführung von Kanban vermieden werden. Bei Scrum ist dies in der Regel anders, weil es je nach aktueller Situation der Organisation massive Veränderungen vom ersten Tag an mit sich bringt.

Epilog

Kanban ist ein interessanter Ansatz. Ich persönlich kann für mich am meisten aus dem Buch herausziehen, wenn ich die Softwareentwicklung als Teil des Gesamtunternehmens sehe und das Umfeld stärker mit einbeziehe. Ich suche schon seit längerem nach Methoden und Ansätzen, um Scrum unternehmensweit und damit auch jenseits der “Programmierung” einzusetzen. Für Teams und Unternehmen, die Scrum einsetzen, kann Kanban tatsächlich der nächste Schritt in der Evolution sein. Allerdings finde ich nicht, dass Scrum und Kanban in Konkurrenz zueinander stehen, sondern sich vielmehr ergänzen können oder auch im parallelen Einsatz eine gute Figur machen.

Für mich ist ein großes Problem die Tatsache, dass der abgebildete Flow eine gewisse Linearität aufweisen sollte, damit sich die gewünschte Transparenz einstellt und das Task Board in dieser Form einen echten Mehrwert darstellt. Gerade in der Programmierung habe ich da so meine Bedenken. Insbesondere wenn man auf Basis des MVC-Patterns entwickelt, kann man sehr schön Arbeit parallelisieren und Teamwork fördern. Kanban hat auch für diese Herausforderung Antworten parat, die mich aber nicht überzeugen. Hier sehe ich eine echte Schwäche von Kanban. Auf der anderen Seite kann Kanban aber natürlich dabei helfen, die Aktivitäten “In Progress” auf dem Board transparenter zu machen, keine Frage. Allerdings macht gerade die Tatsache, dass die Realisierung in die Verantwortung des Teams gegeben und eben keine Transparenz gefordert wird, Scrum ja ein wenig zu dem, was es ist. Das würde man natürlich zumindest ein Stück weit aufgeben.

Grundsätzlich finde ich das sanfte Vorgehen bei der Einführung von Kanban sehr reizvoll. Nachteilig finde ich allerdings die Tatsache, das Kanban  - und das liegt in seiner Natur – keine inhaltliche Unterstützung gibt. Es ist eben im Gegensatz zu Scrum kein Framework – mit allen Vor- und Nachteilen. Ich denke, ein “Continuous Change Management”, wie es Kanban bei seiner Implementierung von einer Organisation und vor allem von Führungskräften verlangt, ist sicherlich einem “Big Upfront Change – Projekt” zur Einführung vorzuziehen.

PS: Mehr zu mir, also dem Autor dieses Artikels, finden Sie hier im Blog auf meinem Profil.

In der aktuellen Ausgabe der OBJEKTspektrum gibt es einen Artikel von mir zum Thema “Foggs Verhaltensmodell: Systematisch die Konversion optimieren”. Worum geht es?

Den ganzen Artikel gibt es bei der OBJEKTspektrum zum Download als PDF oder in der Print-Ausgabe am Kiosk

PS: Mehr zu mir, also dem Autor dieses Artikels, finden Sie hier im Blog auf meinem Profil.

Unverhofft kommt oft! Da schlagen sich seit Jahren die Institutionen mit den abenteurlichsten Spezifikationen um die Vorherrschaft im Semantic Web und dann das: Google, Microsoft und Yahoo! raufen sich zusammen und veröffentlichen mit schema.org quasi über Nacht einen gemeinsamen Standard für semantisches Markup und bringen das Internet der Vision des Semantic Web damit einen entscheidenden Schritt näher.

Es ist schon verrückt irgendwie. Da entstehen in den letzten Jahren zig Standards wie etwa die “Rich Snippets“, RDFa, microformats und weiß der Geier nicht was und ganz heimlich wird HTML Microdata dank schema.org zum Star. Ist das Rennen damit gelaufen? Ja. Zumindest im “öffentlichen Web”. Denn es ist ja so, dass auch alle Websites dieser Welt von Heute auf Morgen einen pinken Hintergrund hätten, wenn Google glaubhaft machen könnte, das dies einen signifikant positiven Einfluss auf das Ranking hat. Und das meine ich jetzt gar nicht negativ – ganz im Gegenteil: Hier zeigt sich wieder einmal sehr schön, dass Standards eben nur dann erfolgreich sind, wenn Sie auch Anwendung finden. Die Grammatik der Schema.org Schnippsel könnte einfacher kaum sein und genau das wird ebenfalls zum Erfolg beitragen: Die SEOs und Hobby-Webmaster dieser Welt bestimmen die Technologien für das Semantische Web. Das war ja eigentlich auch schon genauso im Web 1.0 und Web 2.0. XHTML haben sie ja auch irgendwann eingestellt. Und das schlichtweg, weil es einen Tick zu kompliziert für die meisten aktiven im Web war. Wer sich schon einmal die Web Ontology Language (OWL) und die verwandten Technologien angesehen hat, der wird vermutlich begeistert sein, sich zugleich aber auch zu Recht die Frage stellen: Wer soll das eigentlich beherrschen? Der Webmaster von nebenan? Wohl kaum. Also zumindest nicht so, wie man von einem Normalsterblichen erwartet, dass er HTML beherrscht.

Schema.org wird zu SEO 2.0 führen und die Regeln von SEO in vielen Bereichen neu definieren. Denn worum geht es bei SEO ja ganz maßgeblich? Es geht darum mit dem verfügbaren Vokabular (also den üblichen verdächtigen HTML-Tags wie h1-h6, p, strong, etc.) den Inhalt einer Seite so auszuzeichnen, dass Google versteht, worum es hier eigentlich geht bzw. für welche Keyword-Phrase diese Seite vermutlich passend ist. Mit HTML Microdata wird nun eine vollkommen neue Dimension des Verständnisses des Inhalts einer Seite für Maschinen geschaffen. Die nächsten Monate werden zeigen, was die Auswirkungen der Einzug haltenden Semantik im Markup vieler Websites haben wird. So viel ist sicher: The Race is on!

PS: Mehr zu mir, also dem Autor dieses Artikels, finden Sie hier im Blog auf meinem Profil.

Die Google Webmaster Tools sind ein prima Werkzeug für Website-Betreiber, keine Frage. Google informiert über fehlende oder doppelte Title-Tags, Meta-Descriptions, Page Load Speed, 404s und vieles mehr. Alles auch ganz prima und super hilfreich, allerdings im Grunde genommen schon zu spät. Denn wenn es dort auftaucht, hat Google ja ebenjene semantischen Fehler, Duplicate Content und etwaige Dead Links schon gefunden und unserer Website im Zweifel negativ angekreidet.

Die Google Webmaster Tools können also nicht das einzige Werkzeug im Koffer sein, das der Webmaster von Heute mit sich herum trägt. Neben Tools zum Check der generellen Verfügbarkeit der Website und den durchschnittlichen Ladezeiten, wie etwa Pingdom, CloudKick oder New Relic, gibt einem ein eigener Crawler gerade bei größeren Seiten mit vielen einzelnen Pages eine Menge wichtiger Infos, die man ansonsten sonst erst viel, viel später – nämlich wenn das Kind bereits in den Brunnen gefallen ist – über die Google Webmaster Tools bekommen würde. Hier die gute Nachricht: Man braucht kein Mega-Datacenter wie das von Google um regelmäßig eine Site zu crawlen und die relevanten Informationen zu extrahieren. Eine überschaubare Desktop-Applikation tut es hier auch.

Die 3 bekanntesten Tools für diesen Job sind:

• Xenu Link Sleuth: Der Klassiker, kostenfrei und immer noch eine gute Wahl.
• Screaming Frog: Newcomer, spezialisiert auf SEO, wirklich gut, aber erst in der Bezahlversion ein Tipp.
• A1 Website Analyzer: Günstiger als Screaming Frog und mein persönlicher Tipp.

Viel wichtiger als das Tool an sich ist aber der geübte Umgang mit ebenjenem und vor allem dessen regelmäßiger Einsatz. Gerade nach umfassenderen Releases, oder besser noch vor dem Release auf einem Staging-System, sollte das Tool der Wahl angeworfen werden um zu schauen, ob nicht ggf. ungewollt Dead Links erzeugt oder Duplicate Content produziert wurde.

Leider ist keines der Tools direkt dazu geeignet, im Rahmen eines automatisierten (erweiterten) Build-Jobs ausgeführt zu werden und um ggf. sogar einen Rollout eines neuen Releases zu stoppen, falls signifikante Fehler festgestellt werden. Aufgrund der Tatsache, dass insb. SEO-seitige Probleme aber oftmals eh erst sichtbar werden, wenn die Anwendung auf die umfassenderen Produktivdaten losgelassen wird, würde das konzeptbedingt vermutlich aber auch meist eh nur sehr bedingt funktionieren. Als sehr sinnvoll hat sich hingegen erwiesen, einen separaten, automatischen Job, ggf. auf einem dedizierten (Windows-)System, nächtlich auszuführen, so dass am Morgen die Ergebnisse begutachtet und ggf. Bugfixes durchgeführt werden können. In aller Regel kommt man so dem (Google-)Crawler auch noch zuvor und kann die größten Probleme beseitigen, bevor zunächst die Suchmaschinen auf sie aufmerksam werden und sie dann, mit einigem Zeitverzug, in den (Google-) Webmaster Tools auftauchen. Denn dann ist es, wie gesagt, eigentlich schon zu spät.

PS: Mehr zu mir, also dem Autor dieses Artikels, finden Sie hier im Blog auf meinem Profil.

In der Scrum Sprint Retrospektive lässt das Team den letzten Sprint revue passieren. Dies ist ein sehr wichtiger Akt, ist es doch die Basis für kontinuierliche Verbesserung. Interessanterweise höre ich immer wieder von Teams, die zwar im Sprint Review akribisch den Sprint Verlauf sezieren, aber die Randpunkte des Sprints vollkommen außer Acht lassen. Dabei sind Sprint Planning und Sprint Retrospektive neben der Besprechung von Impediments und Blockern, die im Verlauf eines Sprints auftreten können, die markanten Eckpfeiler eines jeden Sprints und somit auch einer rückblickenden Betrachtung mehr als würdig.

Hier eine Reihe von Beispielfragen zu Sprint Planning und Sprint Review, denen sich das Team in der Sprint Retrospektive stellen sollte:

Sprint Planning

• Waren die User Stories ausreichend und hilfreich vorbereitet?
• Waren die User Stories sinnvoll gesliced oder gibt es Verbesserungsbedarf?
• Konnte der Product Owner offene Fragen beantworten oder waren bis zuletzt die Unabwägbarkeiten so groß, dass sich das Commitment schwierig gestaltete?
• Gibt es weiteres Feedback, das wir dem Product Owner geben können?
• Lagen wir mit unseren Schätzungen richtig? Bei welcher Story haben wir zu hoch gegriffen, wo haben wir den Aufwand unterschätzt?
• Waren wir beim Commitment zu konservativ, hätten wir uns mehr zutrauen sollen oder haben wir unsere Kapazität überschätzt?
• Wo hat unser Taskbreak-Down gut funktioniert? Wo weniger gut? Haben wir an Alles gedacht? Haben wir irgendwas vergessen, was im Sprint dazu geführt hat, dass wir neue Taskkarten schreiben mussten?
• Waren Ort, Zeitpunkt um Umfang des Sprint Planning angemessen?
• …

Sprint Review

• Haben wir das Sprint Ergebnis überzeugend präsentiert? Konnten wir begeistert?
• Haben wir unsere Leistung als Team für alle transparent und greifbar gemacht?
• Waren wir ausreichend vorbereitet? Gab es technische oder organisatorische Probleme bei der Präsentation?
• Waren die Akzeptanzkriterien für die Verifizierung und Präsentation dienlich?
• Waren Ort, Zeitpunkt um Umfang des Sprint Review angemessen?
• Hatten wir die richtigen Personen im Raum? Konnten alle folgen?
• …

Übrigens rate ich, auch die letzte Sprint Retrospektive mit in der aktuellen Sprint Retrospektive zu berücksichtigen. Dies erlaubt eine Meta-Meta-Reflektion: Wie effektiv war die Reflektion des letzten Sprints? Welche Fragen hätten wir uns noch stellen müssen? Was lief gut? Was können wir bereits in dieser Sprint Retrospektive besser machen?

Viel Erfolg bei der kontinuierlichen Verbesserung!

PS: Mehr zu mir, also dem Autor dieses Artikels, finden Sie hier im Blog auf meinem Profil.