Seit mehr als drei Jahren beschäftigen wir uns bei IT-Logix nun mit dem Thema „Agile“. Dabei steht die Frage im Vordergrund, wie man agile Grundsätze im BI/DWH-Umfeld anwenden kann. Agilität als solches kann man sich dabei nicht direkt erwerben, sondern sie ergibt sich vielmehr als Nebenprodukt einer vielschichtigen Kombination spezifischer, auf Agilität ausgerichtete Methoden, Konzepten und Technologien. Ausgangslage ist meist – so auch für IT-Logix – das Agile Manifesto: http://agilemanifesto.org/ Die dort beschriebenen Aspekte skizzieren das „Mindset“, welches als die wichtigste Komponente bezeichnet werden kann auf dem Weg zu mehr Agilität. Denn keine Methode, kein Konzept und kein Tool lösen irgendein Problem, wenn nicht die darin involvierten Menschen erfassen, um was es eigentlich geht, was der „Sinn“ dahinter ist.
Wer Agile hört, denkt in der Regel an Scrum. Scrum ist eine Projektmethodik, welche sich im Bereich der Softwareentwicklung schon länger etabliert hat und nun zunehmend auch in anderen (IT-) Disziplinen Einzug hält, so auch in BI und DWH-Projekten. Allein der Umstand, dass viele Leute Agile mit Scrum gleichsetzen, zeugt von einem glücklichen Händchen der Scrum-Erfinder in Sachen Marketing. Aus meiner Sicht gilt es dabei aber drei Dinge zu berücksichtigen:
- Was heute in verschiedenen Unternehmen als Scrum bezeichnet wird, hat häufig nichts mehr mit der Grundidee von Scrum, eben dem agilen Mindset, zu tun. Michael James hat es auf Twitter kürzlich so beschrieben:
Das führt häufig zu Frustrationen – ein amüsanter und zugleich interessanter Blog, bringt es auf den Punkt: http://antiagilemanifesto.com/ - Mit dem starken Marketing rund um Scrum geht auch eine proprietäre Terminologie einher. So heisst eine Iteration Sprint, ein tägliches Koordinationsmeeting „Daily Scrum“, eine ToDo-Liste wird zum Backlog etc. Hier besteht die Gefahr von Verständnis- und damit auch Verständigungsproblemen zwischen den Stakeholdern innerhalb der Projektorganisation und ausserhalb, typischerweise dem Senior Management.
- Scrum ist nur eine von verschiedenen agilen Praktiken – und für sich alleine nicht immer die am besten geeignete Methode, wenn es um deren Anwendung im BI/DWH-Umfeld geht.
In meinem Kundenumfeld erlebe ich immer wieder Aspekte, die einer iterativen Vorgehensweise entgegenlaufen. Allein schon nur das Projektsetup erfordert in den meisten Fällen einen Projektantrag mit Aufwandschätzung, Projektplan und Meilensteinen. Aus Architektursicht muss man sich meist an einer Gesamtarchitektur orientieren, häufig bereits bestehenden Datenmodellen etc. Bei der Umsetzung sind oft mehrere Teams aus der Organisation involviert, es gibt immer wieder Abhängigkeiten und dadurch (ungeplante) Wartezeiten. Wie gelingt es, diese Rahmenbedingungen konstruktiv in ein gewähltes Vorgehen zu integrieren und dennoch die Werte des Agile Manifestos hochzuhalten?
Im letzten Herbst bin ich auf das Disciplined Agile Delivery (DAD) Framework von Scott Ambler aufmerksam geworden (http://www.disciplinedagiledelivery.com/). Ihm und seinen Mitstreitern gelingt es aus meiner Sicht ausgezeichnet, den Gap zwischen Scrum als reine Entwicklungsmethode und den Bedürfnissen eines Enterprise-Umfeldes zu adressieren. Dabei erfindet DAD die Sachen nicht neu, sondern gibt ganz im Sinne des Framework-Begriffs eine Struktur vor, um verschiedene Methoden in einen Gesamtkontext zu stellen.
DAD kennt verschiedene Lifecycles für die Projektabwicklung. Der grundlegende „Agile“ Lifecycle beinhaltet viele Elemente aus Scrum, verzichtet aber weitestgehend darauf, eine proprietäre Sprache zu verwenden. Ebenfalls ein wichtiger Aspekt ist die Inception Phase, wo u.a. die im Enterprise-Umfeld benötigte Abstimmung „mit dem grossen Ganzen“ stattfinden kann.
Iterationen basieren grundsätzlich auf einem Timebox-Ansatz. Das heisst, man fixiert bewusst die Zeitspanne und variiert den Scope für eine Iteration so, dass er umgesetzt werden kann. Je nach Ausgangslage kann die Umsetzung eines solchen Verfahrens aber schwierig werden, vor allem wenn andere Teams, von denen man abhängig ist, nicht nach diesem Ansatz arbeiten. Aus diesem Grund beinhaltet DAD weitere Lifecycles, u.a. einen Lean-Lifecycle:
Die Grundstruktur bleibt gleich, jedoch fehlen die fixen Iterationen. Damit wird die Flexibilität grösser – jedoch auch die Gefahr, sich zu verzetteln. Es braucht an dieser Stelle einiges an Disziplin – der Name „Disciplined“ Agile Delivery kommt nicht von ungefähr.
Um DAD genauer kennen- und anwenden zu lernen, luden wir Ende Januar Scott Ambler für einen zweitägigen Workshop zur IT-Logix ein. Damit verbunden war auch die erste Zertifizierungsstufe – neben weiteren acht IT-Logix Mitarbeitern darf auch ich mich jetzt mit einem DAD Yellow-Belt schmücken ;-)
Fazit: Einmal mehr ist gesunder Menschenverstand gefragt und nicht Methodengläubigkeit – was in der Praxis funktioniert zählt. Das DAD-Framework gibt uns und unseren Kunden sinnvolle Leitplanken, um die Mehrwerte eines agilen Mindsets zu realisieren. Gleichzeitig ist es im Sinne eines Frameworks offen genug, um unterschiedlichen Kundensituationen individuell gerecht zu werden. Unser Beitrag ist, die geschilderten Prozesse im BI-spezifisch auszuprägen und in der Praxis zu leben.
Event-Hinweis 1: Als Mitglied des Scrum Breakfast Club treffe ich mich einmal im Monat zu einem Austausch mit anderen Interessierten. Der Event findet stets unter einem bestimmten Themenstellung im OpenSpace-Format, mehr Infos hier: https://scrumbreakfast.club. Sind Sie interessiert an einer Teilnahme? Beim ersten Mal kann ich Sie als Gast kostenlos zum Workshop mitnehmen. Kommen Sie dafür einfach auf mich!
Event-Hinweis 2: Besuchen Sie meine Session an der sapInsider BI2015 Konferenz, wo ich erläutere wie ich das DAD-Framework auf ein SAP BusinessObjects Migrationsprojekt angewendet habe. Mehr Infos hier.
Zum Schluss dieses Beitrags noch ein paar Eindrücke aus unserem Workshop:
