deepseed ist eine Vorgehensweise, die berücksichtigt, dass das Einführen von agilen Praktiken in Unternehmen auf verschieden Probleme stösst, die in normalen Coaching-Ansätzen nicht zu lösen sind.

deepseed_phases

Unser Ziel ist es deshalb nicht primär „nur“ zu beraten, sondern wir wissen, wie man in einem hocheffektiven Team zusammenarbeitet und wir geben dieses Wissen direkt an Mitarbeiter von Ihnen weiter, in dem sie nicht nur gesagt bekommen, wie man Software effektiver und effizienter entwickelt, sondern indem sie auch zu spüren bekommen, wie es sich anfühlt in einem hochperformanten Team mitzuarbeiten.

Unser Ansatz verfolgt genau diesen Zweck. Möchten Sie mehr erfahren, dann lesen sie hier weiter.

Wann standst Du zum letzten Mal vor einem grossen Berg an Programmcode und hast versucht ihn zu verstehen? Wie bist Du da vorgegangen? Durch wie viele Klassen Java- oder .NET-Code hast Du dich gewühlt? Hast Du alle Referenzen auf den schlechten Code gefunden? Bist Du sicher, dass Du sie alle gefunden hast? Und wie lange hast Du dafür gebraucht? Oder ist der Debugger dein bester Freund?

Obwohl die Entwicklingsumgebungen in den letzten Jahren immer mächtiger geworden sind, hat es bisher nur für eine relativ bescheidene Navigation durch den „Abstract Syntax Tree“ (AST) gereicht, und sonst behilft man sich mit einfachen grep- und regex-Suchen.

Doch die Menge an Code und die Fülle an Medienbrüchen nimmt stetig zu, und es wird immer schwieriger sich einen guten Überblick über die Codebasis zu verschaffen, um informierte und fundierte Entscheidungen bezüglich Design und Problembeseitigung zu treffen.

Selbst testgetrieben entwickelter Code, der aktuell mit zum Besten gehört, dass wir Softwerker produzieren, wird mit zunehmendem Umfang tendenziell unerbittlich komplexer und schwieriger in seiner Gesamtheit versteh- und manipulierbar. Besonders wenn mehrere Leute an einer gemeinsamen Codebasis arbeiten, die über mehrere Generationen von Mitarbeitern gepflegt werden muss, stehen sie vor ebensolchen Herausforderungen.

Da wurde es Zeit, dass sich jemand um die manchmal verloren geglaubte Kunst der Code-Analyse, d.h. die systematische Musterung von Code, ernsthaft bemüht. Dieser Schritt ist nun mit der Lancierung des „humane assessment“ getauften Ansatzes getan.

the humane assessment method
the humane assessment method

Tudor Girba hat es nicht dabei belassen, ein als Open Source publiziertes Tool zur mächtigen Code-Analyse in die Welt zu setzen, sondern sich darüber hinaus überzeugend Gedanken gemacht, wie ein solches „Assessment“, die Beurteilung von Code, in agile Entwicklungsverfahren, ergänzend eingebracht und verankert werden kann.

Seine Argumentation zugunsten eines kontinuierlichen Code-Assessments stützt er dabei auf viele Erfahrungen, die er und andere „Mooser“, in unterschiedlichsten Projektkontexten gemacht haben. Dabei stechen dem geneigten Entwickler zwei fundamentale nutzbringende Anwendungen ins Auge:

  • Die Möglichkeit grosse Mengen an Code gezielt zu filtern und auf dem reduzierten Set an selektierten Stellen im Code, selbst komplexe Analysen und gar Transformationen durchzuführen. Durch die Freiheit eigene Parser, Filter, Transformatoren und Visualisierungen zu implementieren, sind den Möglichkeiten fast keine Grenzen gesetzt.
  • Eine weitere interessante Option besteht in der Möglichkeit wiederkehrend, z.B. im Build-Prozess, die Einhaltung von Architektur- und Design-Regeln automatisiert zu überprüfen, und so eine Bastion gegen die stete Entropie von gutem Code zu errichten.

Mehr über „humane assessment“ erfährst Du auf der einschlägigen Website.

Scrum, als agile Vorgehensweise, kennt einen eingebauten kontinuierlichen Verbesserungsprozess. Dies ist einer der elementaren Vorteile des Rahmenwerks, vorausgesetzt natürlich, man führt Retrospektiven tatsächlich durch und handelt anschliessend aufgrund der dort aufgebrachten Probleme.

thinkingoutofbox

Ein nützliches Werkzeug Retrospektiven inhaltsvoller und auch zielgerichteter zu gestalten, stellen die in Rolf Smith’s Buch „The 7 Levels of Change: Different Thinking for Different Results“ (3rd Edition, Tapestry Press 2007) beschriebenen Ebenen des Nachdenkens dar. Sie helfen Probleme aus verschiedenen Blickwinkeln zu betrachten. Dadurch kann man mehr alternative Ansätze zur Lösung eines Problems generieren.

Die 7 Ebenden des Nachdenkens sind: Effektivität, Effizienz, Verbesserung, Reduktion, Nachahmung, Originalität und Unmögliches.

Wir wollen uns im Folgenden einen Überblick schaffen, wie wir sie in der Praxis verwenden können. Wir können die 7 Ebenen wie Kategorien von Fragen betrachten, die wir uns im Team stellen und beantworten sollten.

Ebene 1: Effektivität

Ziel: Die richtigen Dinge tun

Fragen, die wir uns stellen können:

  • Was hat Priorität?
  • Was ist dem Kunden wichtig?

Ebene 2: Effizienz

Ziel: Die Dinge richtig tun

Fragen, die wir uns stellen können:

  • Wie schreiben wir gute Tests?
  • Wie können wir eine gemeinsame Sprache mit dem Kunden finden?

Ebene 3: Verbesserung

Ziel: Die Dinge besser tun

Fragen, die wir uns stellen können:

  • Wie optimieren wir die Laufzeit unserer Tests?
  • Wie können wir die Kommunikation zum Kunden verbessern?

Ebene 4: Reduktion

Ziel: Dinge nicht mehr tun

Fragen, die wir uns stellen können:

  • Auf welche Dokumente können wir gefahrlos verzichten?
  • Welche Features können weggelassen werden?

Ebene 5: Nachahmung

Ziel: Dinge tun, die andere tun

Fragen, die wir uns stellen können:

  • Können wir den Testansatz des anderen Teams übernehmen?
  • Wie können wir dieses bewährte Design Pattern bei unserem Problem anwenden?

Ebene 6: Originalität

Ziel: Dinge tun, die sonst niemand tut

Fragen, die wir uns stellen können:

  • Können wir Behavior-Driven Design ausprobieren?
  • Können wir unser Projekt-Portfolio mit Kanban verwalten?

Ebene 7: Unmögliches

Ziel: Dinge tun, die unmöglich scheinen

Fragen, die wir uns stellen können:

  • Kann der Direktor der Behörde, die unser Kunde ist, unser agile Vorgehensweise für uns verkaufen?
  • Wie schaffen wir es, ein grosses Softwaresystem 26-mal im Jahr an 10 Kunden gleichzeitig in Produktion auszuliefern, ohne dass sie je einen Betriebsausfall haben?
  • Wie überzeugt man nichtagile Unternehmen zusammen mit uns agil vorzugehen?

Auf Seite 138ff meines Buches „Agile Prozesse: Fallstricke erkennen und vermeiden“ gehe ich mehr ins Detail, wie
dieses Tool in der Praxis angewendet werden kann.

Der Product Owner ist der Herr des Product Backlogs in Scrum. Er trägt die Verantwortung, dass der Kunde das bekommt, was er auch tatsächlich benötigt (nicht unbedingt, was das, was er möchte! – aber das ist eine andere Geschichte).

Die Rolle des Product Owners kann sich je nach Projekt und Firma in andere Richtungen bewegen, als sie ursprünglich gedacht war. Hier einige mögliche Entwicklungen (die sich meist negativ auf das Projekt auswirken).

PO maximiert Geschäftswert

Product Owner als Projektleiter

Der Product Owner kann unter Umständen sehr leicht in die Falle tappen, sich „nur“ als Projekleiter oder Koordinator zu sehen. Dies manifestiert sich darin, dass er an allen Meetings (auch Team-internen, oder sonstigen Leitungs-Meetings) teilnimmt.

Dabei kommen seine Kernaufgaben (die Pflege und Priorisierung des Backlogs, die Überwachung der finanziellen Mittel, die enge Zusammenarbeit mit dem Kunden) zu kurz. Häufig zieht ein Product Owner in solchen Momenten weitere Personen zur Hilfe heran, z.B. Business Analysten, um ihm zu helfen seine Kernaufgaben zu lösen.

Product Owner als Business Analyst

Der Product Owner kümmert sich in dieser Konstellation vor allem um Details der Anforderungen/User Stories und vergisst dabei gerne das Planen und Priorisieren gemäss den Wünschen des/der Kunden. Das Festhalten von Anforderungen fällt ihm auch deshalb einfacher, weil es bei dieser Arbeit weniger Konflikte mit dem Kunden gibt.

Dem Kunden andererseits zu entlocken, dass er eventuell auf gewisse Anforderungen verzichten sollte oder ihm klarzumachen, dass er Prioritäten setzen sollten, obwohl er den ganzen Funktionsumfang haben möchte, ist hingegen der Ort wo in der Regel die meisten Schwierigkeiten für den Product Owner liegen.

Product Owner als Administrator

Ich beobachte immer wieder, dass Product Owner (wie übrigens auch schlechte Projektleiter) zu reinen Administratoren verkommen können. Sie sind fern des Kunden, fern des Teams und organisieren lediglich Meetings oder koordinieren Leute. Dies ist ein Hinweis darauf, dass nicht nur mit dem Product Owner etwas nicht stimmt, sondern mit dem ganzen Projekt und den daran Beteiligten.

Product Owner als ScrumMaster

In Scrum gibt es eine bewusste Gewaltenteilung zwischen Product Owner und ScrumMaster. Letzterer ist verantwortlich für das bestmögliche Funktionieren des Prozesses und nicht der Product Owner. Übernimmt der Product Owner auch diese Rolle, kann dies verschiedene Ursachen haben. Zwei der häufigsten sind: Entweder der Product Owner ist sehr dominant oder der ScrumMaster nimmt seine Aufgabe nicht war.

Dies waren nur einige wenige Anti-Patterns, die mir bisher begegnet sind. In einem spätern Post mehr zu diesem Thema.

Zum vierten Mal jährt sich die, von der Fachgruppe „Lean Agile Scrum“ der Swiss ICT organisierte, Konferenz mit Fokus auf der Anwendung von modernen Entwicklungsvorgehensweisen. Dabei stehen einerseits die Erfahrungen von Anwendern von agilen Methoden im Vordergrund. Andererseits kommen Experten zum Wort, die über aktuelle Praktiken, die sich bewährt haben hinausschauen und neue Ansätze und Werkzeuge entdecken und vorstellen.

Als einer der Gründer der REDpill GmbH, darf ich in meiner Rolle als langjähriger Entwicklungsleiter der Löwenfels Partner AG, aus meiner Erfahrung plaudern, die sich doch nun schon über einen Zeitraum von 8 Jahren angesammelt hat.

Die LAS-Konferenz verspricht eine Plattform für den Austausch von Erfahrungen mit agilem Vorgehen, aus dem deutschschweizer Raum zu sein.

Ein Besuch lohnt sich. Zur Konferenz: http://www.lean-agile-scrum.ch/

Mein Vortrag: http://www.lean-agile-scrum.ch/sessions/in-8-jahren-und-128-releases-vom-grossprojekt-zum-produkt/