Um Schadensbegrenzung bemüht, verfügt der Digital Native über Mittel und Wege, seine Wissenslücken umgehend zu schließen. Eine schier endlose Wissensdatenbank steht ihm nahezu überall zur Verfügung.

Betrachtet man im Gegenzug die angelernten Digitalen, gestaltet sich die sofortige Konsultation des Internets zur Wissensaufnahme häufig holpriger. Es werden tendenziell eher Annahmen getroffen und Behauptungen aufgestellt und es wird länger auf vermeintlich Bewährtem beharrt.

Lässt sich hier eine gedankliche Brücke zum Projektmanagement schlagen?

Den Begriff, den ich zur Debatte stellen möchte, ist der des Agile Native.

Dies sind häufig Berufs- oder Quereinsteiger, die aus einem agilen Umfeld heraus in den Bereich des Produkt- bzw. Projektmanagements gelangen. Unternehmen stehen vor der Herausforderung, diesen Mitarbeitern eine adäquate Grundausbildung zu vermitteln.

Ist das Zeichnen von Netzplänen und Gantt-Charts an dieser Stelle essentielles Grundlagenwissen? Sollte jeder neue Mitarbeiter zuerst mit ausführlichen Anforderungsdokumenten und lückenloser Dokumentation betraut werden? Oder reicht tatsächlich die Mechanik eines  leichtgewichtigen agilen Ansatzes für einen Einstieg in die Materie, der doch so häufig in der realen Welt an seine Grenzen zu stoßen scheint?

Projekte scheitern nicht, weil der Projektplan das falsche Format hat. Sie scheitern auch nicht, weil die Erstschätzung ungenau war. Projekte scheitern, sehr vereinfacht gesagt, wenn es grundlegende Mängel in Kommunikation und Zielsetzung gibt. Die tägliche Projektarbeit besteht aus komplexen Interaktionen und erfordert viel Aufmerksamkeit, Abstimmung und Reflektion von allen Beteiligten. Ob Pläne oder Listen mit Tool A oder B und nach Vorgehen Y oder Z erstellt wurden, ist im Normalfall nicht entscheidend. Wichtig ist der Fokus aufs Wesentliche: Ziele, Werte und Prinzipien. Dieses zu vermitteln, ist das Ziel agiler Ansätze – und die Mechanik leitet sich daraus ab.

Vor Kurzem nahm ich an einem Training zu einem agilen Framework teil. Das durchaus heterogene Teilnehmerfeld bestand aus Projektmanagern mit traditionellem und agilem Hintergrund. Als anfangs die agilen Prinzipien und die Aufgaben von Projektleitern thematisiert wurden, meldete sich ein Teilnehmer mit traditionellem Hintergrund leicht provokativ mit der Aussage zu Wort, dass er bereits seit Jahren nach diesen ach so revolutionären Prinzipien im traditionellen Umfeld arbeite – das sei doch gesunder Menschenverstand. Die Antwort des Trainers zu dieser Feststellung war so trivial wie erleuchtend: Weiter so!

Es macht im Grunde keinen Unterschied, welches Framework oder welchen Ansatz man verfolgt. Agile Prinzipien und Frameworks basieren auf Erkenntnissen des traditionellen Projekt- und Produktgeschäfts. Was rückblickend gut funktionierte, inspiriert heute Agil, was zu Misserfolg führte, gilt als Antipattern und wird durch viel besprochene Frameworks wie Scrum eliminiert.

Wichtig ist das Befolgen agiler Prinzipien, nicht das unreflektierte Umsetzen einer Methode.

Eine agile Grundausbildung sorgt dafür, dass sich diese erwiesenermaßen erfolgreichen Denkstrukturen verfestigen. Der Aufbau von methodenspezifischem Wissen ist anschließend Fleißarbeit und die erfolgreiche Umsetzung so unterschiedlich wie die Unternehmen selbst. Ich bin der Überzeugung, dass eine agile Grundausbildung im ersten Schritt deutliche Vorteile mit sich bringt. Verstöße gegen die agilen Prinzipien, egal in welchem Kontext, lösen beim Projektmanager anschließend Befremden aus und beugen so Verschwendung und Misserfolg effektiv vor.

Damit sollten Agile Natives dafür sorgen, dass agiles Gedankengut die Verbreitung findet, die ihm gebührt.

Johannes Lübkert, Heiko Lentz und Michael Heinecke, die das Web-Performance-Team von Telefonica bzw. o2 bilden, berichteten über “Visualisierung von Performance”. Ihr Ausflug in Technik im Front- und Backend und der Datenvisualisierung von WPT- und RUM-Samples war so spannend, dass sich eine lange und interessante Diskussion entwickelte. Diese war so fruchtbar, dass wir den zweiten Talk kurzerhand ausfallen ließen, um die Zeit für diese Diskussion zu nutzen.

Das Web Performancer-Team: Michael, Johannes und Heiko

Das nächste Mal treffen wir uns am 28. Mai um 19:00 Uhr bei t8y.com (Bernhard-Nocht-Straße 113, 22763 Hamburg). Beide Speaker sind bereits bekannt, denn sie haben schon auf einem Meetup referiert. Uwe Beßle wird seine Erfahrungen mit Lasttests (was testen, wie messen, wie auswerten) mit uns teilen. Steve Souders wird sich wieder per Hangout zuschalten und einen Überraschungstalk halten.

Anmelden kann man sich über unsere Meetup-Gruppe oder über XING. Noch sind Plätze frei!

Historisch gewachsen? – Softwarearchitekturen dokumentieren und kommunizieren

Jeder von uns weiß: Dokumentieren zählt nicht unbedingt zu den Lieblingsbeschäftigungen eines Entwicklers. Und dann auch noch Architektur? Kästchen, Linien, Wolken? Wirkungsvolle Architekturdokumentation ist keine bunte High-Level-Powerpoint-Präsentation. Sie macht zentrale Entscheidungen auch später noch nachvollziehbar. In dieser Session erlebt Ihr, wie Ihr Eure Architektur geeignet festhalten könnt, anstatt sie zu vergessen. Vortrag, interaktive Elemente und die Möglichkeit zum Austausch wechseln sich dabei ab. Für Neue im Team habt Ihr anschließend bessere Antworten parat als “Historisch gewachsen”.

Für diejenigen unter Euch, die Stefan noch nicht kennen: Stefan Zörner ist Anwendungsarchitekt, Berater, Trainer und Coach bei oose in Hamburg. Seine inhaltlichen Schwerpunkte sind Softwarearchitektur und Java-Technologien. Ganz besonders interessiert ihn, wie sich Entwürfe effizient festhalten und kommunizieren lassen. Sein Wissen hierzu teilt er regelmäßig in Form von Vorträgen und Artikeln (u.a. im Java Magazin) mit. Sein Buch “Softwarearchitekturen dokumentieren und kommunizieren” ist 2012 im Hanser-Verlag erschienen. Stefan ist Apache-Committer und aktives Mitglied im International Software Architecture Qualification Board (iSAQB).

Wir freuen uns auf ein spannendes Meetup!

Vor gut einem Jahr hat mein Kollege Jo Ehm hier unsere BPMS-Scorecard vorgestellt, eine Balanced Scorecard, in der wir alle unserer Erfahrung nach wichtigen Kriterien für die Auswahl eines BPMS gesammelt haben. Mit ihr lassen sich einzelne Tools gezielt vergleichen und bewerten, um letztlich eine Entscheidung herbeizuführen. Wer schon weiß, was er will, ist mit diesem Werkzeug gut bedient.

Doch um an diesen Punkt zu gelangen, muss man sich zunächst Gedanken darüber machen, welche Art von BPM-Tool man benötigt. Solche Tools lassen sich grob kategorisieren: es gibt reine Modellierungswerkzeuge, Process Engines zur Automatisierung von Prozessen, komplette Suiten, die beides mitbringen und außerdem umfangreiche Reportingmöglichkeiten bieten und dazwischen praktisch sämtliche Spielarten. Dazu kommt, das solche Tools schnell eine veritable Investition erfordern. Umso wichtiger, sich genau zu überlegen, wie das Einsatzszenario aussieht.

Für die Zieldefinition kann man die bereits genannten Kategorieren zugrunde legen: Modellierung, Automatisierung, Reporting. Wenn Prozesse lediglich modelliert, aber nicht automatisiert werden sollen, genügt ein reines Modellierungstool. Soll dagegen der komplette Prozesslebenszyklus abgedeckt werden, ist ein Tool, das auch Möglichkeiten für Automatisierung und Monitoring bietet, sinnvoll.

Ist das Einsatzszenario definiert, gilt es, tiefer in die drei Kategorien zu leuchten und genauer zu bestimmen, welche Eigenschaften das Tool der Wahl haben soll. Sollen Modelle toolübergreifend ausgetauscht werden können? Benötigt man das BPM-Tool zur Integration verschiedener externer Systeme? Soll das Tool Möglichkeiten zur Verwaltung manueller Aufgaben bieten? Müssen KPIs für das Monitoring im BPM-Tool hinterlegt werden können? Daneben müssen noch einige allgemeine Rahmenbedingungen abgesteckt werden, etwa: Welche Technologien kommen zum Einsatz, wie wichtig sind Testmöglichkeiten?

Pauschale Antworten darauf können wir nicht geben – wohl aber die richtigen Fragen stellen. Diese haben wir nun in einem Whitepaper zur BPM-Toolauswahl übersichtlich zusammengefasst und führen interaktiv in fünf Schritten zum passenden Tool. Das Whitepaper steht auf unserer Website zum Download bereit.

Im zweiten Vortrag, einem Pecha Kucha (20 Folien mit einer festen Laufzeit von je 20 Sekunden) berichtet Jo Ehm sehr kurzweilig über SOAgil kann BPM sein. Hierbei geht es um praxiserprobte Vorgehensweisen, mit denen man BPM-Projekte, die von ihrer Natur her immer latent dazu neigen, dass sich ein Wasserfall einschleicht, erfolgreich agil abwickelt. Kurz, knapp (6’40”) und knackig, so macht ein Vortrag Spaß!

Also: nichts wie hin zum Dammtor und zum Holisticon-Stand!

Doch wie geht man dann mit allen möglichen Ausnahmen um, insbesondere, wenn es darum geht, Geschäftsprozesse mit Hilfe einer Process Engine zu automatisieren? Abhilfe schafft hier ein Konzept, das wir in Kundenprojekten schon erfolgreich umgesetzt haben: das Konzept des Störprozesses. Dabei wird einem fachlichen Geschäftsprozess ein entsprechender Störprozess zur Seite gestellt. Treten im Verlauf des fachlichen Prozesses unvorhergesehene Störungen auf, die nicht im Fachprozess berücksichtigt sind und aufgrund derer der Fachprozess nicht sinnvoll fortgesetzt werden kann, so wird der dazugehörige Störprozess gestartet. Dies kann entweder manuell durch einen Benutzer geschehen oder auch automatisch beim Eintreten bestimmter Bedingungen.

Zu Beginn des Störprozesses muss zunächst die Instanz des gestörten Fachprozesses identifiziert werden, typischerweise durch die Angabe eines eindeutigen fachlichen Schlüsselwerts (wie z.B. einer Bestellnummer). Der Störprozess unterbricht dann als erstes die fachliche Prozessinstanz (die aktuelle Ausführung der Prozessinstanz wird also angehalten). Voraussetzung hierfür ist natürlich, dass die eingesetzte Process Engine ein solches Konzept unterstützt und eine entsprechende API dafür bereitstellt. Als nächstes kann ein Benutzer Informationen zur vorliegenden Störung erfassen und entscheiden, was als nächstes mit dem Fachprozess passieren soll. Diese Information und die möglichen Aktionen sind typischerweise spezifisch für den jeweiligen Fachprozess, d.h., ein Störprozess ist in der Regel immer auf einen konkreten Fachprozess abgestimmt. Prinzipiell gibt es aber drei grundlegende Möglichkeiten, wie mit dem Fachprozess jetzt umgegangen werden kann: a) nach Behebung der Störung wird die fachliche Prozessinstanz ab dem Punkt, an dem sie zuvor angehalten wurde, wieder fortgesetzt, b) die Prozessinstanz muss komplett gecancelt werden, oder c) die Prozessinstanz wird abgebrochen und auf Basis der bereits erwirtschafteten Fach- bzw. Prozessdaten neu aufgesetzt. Insbesondere in letzterem Fall ist in der Regel auch eine Bereinigung der Daten notwendig, damit die neu aufgesetzte Prozessinstanz auch auf einem konsistenten Datenbestand arbeiten kann.

Denkbar ist auch, dass ein Fachprozess an verschiedenen Stellen mit “Einsprungpunkten” für das Wiederaufsetzen nach einer Störung versehen wird, sodass es möglich ist, den Prozess gezielt auf verschiedene Meilensteine in seinem Ablauf “zurückzurollen”. Dementsprechend erhöht sich dann natürlich auch die Logik des zugehörigen Störprozesses. Er muss herausfinden, in welchem Schritt die fachliche Prozessinstanz unterbrochen wurde, um abhängig davon die möglichen Aktionen für das Wiederaufsetzen abzuleiten und die Daten entsprechend aufzubereiten.

Doch nochmals zurück zu unserem Ausgangspunkt: Ausnahmen sind immer und überall. Wie entscheide ich, welche Ausnahmen ich im Fachprozess selbst abbilde und wann es Sinn macht, einen separaten Störprozess zu implementieren? Hier hilft die folgende Faustregel:

1. Fachliche Ausnahmen, die mit einer gewissen Wahrscheinlichkeit absehbar sind und die sich stets auf standardisierte Weise behandeln lassen, sollten durch den Fachprozess abgebildet werden.

2. Technische Fehler sollten nach Möglichkeit der Process Engine selbst überlassen werden. Dies bedingt natürlich, dass die Process Engine eine entsprechende Fehlerbehandlung unterstützen muss – dass die Engine z.B. an Transaktionen teilnehmen kann und vor allem, dass Prozessinstanzen beim Auftreten einer technischen Exception in einen kontrollierten Fehlerzustand laufen, aus dem ein Administrator den fehlgeschlagenen Prozess (nach Behebung des technischen Fehlers) wieder anstarten kann. In diesem Zusammenhang kann auch die Möglichkeit von automatischen Benachrichtigungen bei technischen Fehlern nicht schaden.

3. Alle sonstigen (fachlichen) Eventualitäten können über das hier beschriebene Konzept eines Störprozesses abgewickelt werden. Dabei sollte jedoch immer auf ein gesundes Kosten-Nutzen-Verhältnis geachtet werden. Es ist sicherlich wenig ökonomisch, einen komplexen Störprozess zu implementieren, der in Praxis fast nie gebraucht wird.

Im Zuge des kontinuierlichen Verbesserungsprozesses des Business Process Managements können die aufgetretenen Ausnahmesituationen dann über die Zeit analysiert werden und häufig wiederkehrende Muster (wo sinnvoll/standardisierbar) in den Fachprozess integriert werden.

Die Fertigstellung von Features kann nicht nur durch Bugs, sondern durch verschiedenste Blocker (Impediments) behindert werden. Das Impediment Backlog enthält bekanntlich verschiedenste Arten von Blockern. Betrifft ein solches Hindernis direkt einen Task oder eine Story, so kann es auf einem kleinen roten Post-it an die entsprechende Karte geheftet werden: dies erhöht die Transparenz und stellt einen direkten Bezug her.

Es empfiehlt sich, am Taskboard alle Tasks, die dem Sprint Planning II entstammen, auf gleichfarbigen (z.B. gelben) Post-its festzuhalten. Kommen im Rahmen der Umsetzung neue Tasks hinzu, so können diese in Form andersfarbiger Post-its (z.B. blau) angeheftet werden. Somit ist auf den ersten Blick erkennbar, inwieweit neue, im Sprint Planning II nicht bedachte Tasks entstanden sind. Diese Informationen können später im Rahmen der Retrospektiven verwendet werden und zur Ableitung von Verbesserungsmaßnahmen beitragen.

Ein derart farblich codiertes Taskboard kann auf einen Blick Gründe für eventuell nicht fertiggestellte Features liefern, darüber hinaus verschafft es einem allein durch die Farbgebung einen Eindruck vom aktuellen “Gesundheitszustand” des Projekts.

Dies zeigt auch der nachhaltige Erfolg des Hamburger Scrumtisches, der alle zwei Monate in der Hamburger Handwerkskammer abgehalten wird. Bei der Veranstaltung, die von Holisticon und it-agile durchgeführt und gesponsert wird, erscheinen im Schnitt 40-50 diskussionsfreudige Scrummer. Als reiner Open Space gehalten, bietet dieser Scrumtisch eine tolle Gelegenheit, sich untereinander Geschichten zu erzählen, Fragen zu stellen oder einfach nur nett bei Schnittchen und Kaltgetränken zu unterhalten.

Die “Beraterdichte” ist erfreulich gering: man hat einige Experten dabei, die gerne aus ihrer Erfahrung plaudern, aber der eigentliche Mehrwert wird generiert durch Diskussionen auf Augenhöhe, sozusagen von Anwender (des Frameworks Scrum) zu Anwender. So kann man frei von der Leber weg über seine Probleme sprechen, ohne Angst haben zu müssen, am nächsten Tag einen Vertriebler am Telefon zu haben, der einen Auftrag an Land ziehen will.

Diese offene und wahrhaft kollegiale Atmosphäre macht den Charme des Hamburger Scrumtisches aus, der seit nunmehr 2008 ausgerichtet wird. Vielen Dank an alle Teilnehmer, die diese Veranstaltung immer wieder zu einem Erfolg machen!

Carsten Sahling beim Vortrag zu DSDM Atern

Am vergangenen Montag Abend lud die Holisticon AG bei bestem Wetter zum Abendvortrag der PMI Agile CoP Hamburg ein. Diese Xing-Gruppe hat es sich zum Ziel gesetzt, nicht nur klassische Verfahren mit agilen zu verknüpfen, sondern sich auch in loser Folge anderen verwandten Themen zu nähern. In diesem Zuge werden auch neue Methoden und Praktiken angeschaut, wie in diesem Fall DSDM Atern.

DSDM Atern ist eine agile Projektmanagementmethode, die seit den 90er Jahren in England weite Verbreitung gefunden hat, in Deutschland jedoch weitestgehend unbekannt ist. Nach dem kurzweiligen Vortrag von Carsten Sahling, dem Leiter des Geschäftsfelds Agil bei der Holisticon AG, entstand eine durchaus kontroverse, aber sehr fruchtbare Diskussion zum Thema. Die Vertreter der Scrum-Fraktion empfanden die Methode als überdimensioniert und meinten, all diese zusätzlichen Phasen, Rollen und Artefakte könne man auch mit Scrum abbilden. Das Gegenargument war hier, dass es sicher möglich ist, aber leider nicht mit definierten Scrum-Bordmitteln, sondern nur mit Best Practices, die gute Berater und Coaches zwar parat haben, aber der Scrum-„Otto-Normalverbraucher“ eben nicht. Die Befürworter von Prince2, einem eher für sehr große Projekte geeigneten Framework waren begeistert, weil sie endlich einen „kleinen Bruder“ entdeckt haben, der für kleinere Projekte geeignet ist, den Kunden aber nicht durch extreme Agilität abschreckt.

Im Endeffekt hat man sich gütlich darauf geeinigt, dass es sehr entscheidend von der Projektgröße abhängt, welches die beste Methode ist. Für kleine Projekte mit bis zu 30 Entwicklern und einer überschaubaren Laufzeit mag Scrum die beste Methode sein, für echte Großprojekte mit mehreren Hundert Beteiligten ist ganz sicher Prince2 die vorteilhafteste Wahl und dazwischen ist man mit DSDM Atern optimal bedient. Endscheidend ist doch, dass die Teams darin unterstützt werden, durch agile Praktiken kreativ und selbstorganisiert tolle Software im geplanten Zeitrahmen produzieren können.

Den runden Abschluss des Abends bildete ein Snack aus belegten Brötchen, Kaltgetränken und guten Gesprächen. So macht Weiterbildung Spaß!

Die SEACON ist Norddeutschlands größte Konferenz rund um aktuelle Themen der Softwareentwicklung und des Software Engineerings. Sie beinhaltet einerseits klassische Fachvorträge und Erfahrungsberichte namhafter und gestandener Experten. Andererseits bietet die Konferenz mit Formaten wie Open Space, Fishbowl oder Business Meetings die Möglichkeit, sich miteinander auszutauschen und selbst aktiv zu werden.
Die diesjährige SEACON hat eine klar gegliederte Trackstruktur mit den drei Bereichen Projektmanagement, Geschäftsprozesse und Softwarearchitektur, so dass es einfacher ist, sich gemäß seiner Interessen zu orientieren.

In diesem Jahr empfängt die SEACON ihre Besucher im Radisson Blu Hotel am Dammtor. Details über die Konferenz und die Agenda können Sie hier einsehen.

Wir würden uns sehr freuen, Sie an unserem Stand begrüßen zu dürfen!