HomeopathicCocoa
(c) by Michael Coghlan, er meint:

Homöopatischer Kakao? Ich wusste gar nicht, dass es so etwas gibt. Aber man lernt immer dazu… 😉

In den paar Jahren, in denen ich nun bereits Unternehmen coachen darf, ist mir immer klarer bewusst geworden, dass Coaching ähnlich wie Medizin wirkt. Wenn die Dosis zu klein ist, dann ist der Nutzen für das gecoachte Unternehmen gleich Null.

Die Unternehmensgrösse spielt, wie die Körpermasse eines Patienten auch eine Rolle. Je grösser das Unternehmen, desto grösser müsste eigentlich die verabreichte „Coaching-Dosis“ sein.

Nicht nur in der „agilen“ Welt gibt es Probleme mit der Dauerhaftigkeit der guten Ratschläge, die man gibt, wie folgende Artikel im Bereich anderer Verbesserungsansätze zeigen:

Die folgende Aufstellung ist nach grösser werdender Wirkung priorisiert:

  1. 100%-ige (zeitlich) Mitarbeit in einem Projekt, mit mindestens 50% Anteil von „Coaches“ im Team, über einen Zeitraum von mindestens 6 Monaten (bei grösseren Unternehmen mindestens für ein Jahr).
  2. 100%-ige (zeitlich) Mitarbeit in einem Projekt als „ScrumMaster“ oder in einer ähnlichen Rolle, über einen Zeitraum von mindestens 6 Monaten (bei grösseren Unternehmen mindestens für ein Jahr).
  3. Begleitung eines Teams über mindestens 6 Monate als Coach, mindestens einen Tag pro Woche, mit Schulungen und „Hands-on“-Mitarbeit bei einzelnen Tätigkeiten.

Einige zusätzliche Pointer:

 

Es scheint wie gestern gewesen zu sein, aber nun ist es schon bald ein Jahr her, dass wir in Luzern das erste Agile Breakfast (damals noch Scrum Breakfast) mitveranstalten durften.

Nun wollen wir unser einjähriges Jubiläum mit einer besonderen Veranstaltung begehen. Wir wollen für einmal etwas mehr Interaktion bieten und hoffen allen Interessierten etwas praktisches mit auf den Weg geben zu können.

Deshalb wird das Breakfast vom November auf den ganzen Vormittag ausgedehnt und zusätzlich zum Vortrag zwei interaktive Workshops bieten.

Dabei wollen wir uns lose von einem Thema leiten lassen, dass man „Vom grundsätzlichen, über analytisches hin zu synergistischem Denken“ nennen könnte.

„(Wie) mache ich ‚richtig‘ Scrum?“

Der provozierende Vortrag von Joseph Pelrine, DEM agilen Pionier in Europa, will unser Verständnis, davon, voran es bei Scrum im besonderen, bzw. Enwicklungsprozessen im allgemeinen, wirklich ankommt, fundamental hinterfragen.

Joseph ist der erste in Europa, der erkannt hat, dass Scrum als Rahmenwerk von Wert ist. Als erster ScrumMaster und Scrum Trainer hat er seine Expertise nicht nur als Berater – sondern auch längerfristig – in vielen Unternehmen einbringen können, von eBay, Nokia bis hin zu Ferrari.

Neben dem Vortrag sind auch zwei kostenlose Workshops von je 80 Minuten geplant, die von den Moderatoren des Breakfasts geführt werden:

„Cho pI tUp!“

Dieser Workshop allen Interessierten vermitteln, wie man Anforderungen (im Rahmen eines fiktiven Projektes), systematisch analysieren kann, indem man von groben Anforderungen kommend kontinuierlich so schneidet, dass nach Geschäftswert beurteilt, Einheiten entstehen, die schnellstmöglich dem Unternehmen, wenn implementiert, Gewinn bringen.

Der Workshop ist auch ein Beispiel analytischen Denkens, dass ein Problem auf Teilprobleme aufteilt, um die einzelnen Probleme leichter lösen zu können.

Jiri Lundak (REDpill) und Philipp Enstler (PeerUp!) werden diesen Workshop moderieren.

„Design Thinking

Design Thinking Prinzipien und Prozesse ermöglichen radikal nutzerzentrierte Innovationen zu entwerfen und ganzheitliche Lösungen zu entwickeln. Die Nähe der zentralen Idee des Design Thinking zum agilen Denken, erlaubt das Design Thinking als erste Phase in einem agilen Entwicklungsprozess zu nutzen. Der Workshop bietet einen Praxis-Crashkurs bezüglich der wesentlichen Elemente des Design Thinking.

Der Workshop ist auch ein Beispiel einer Denkweise in der die Synthese im Vordergrund steht, wobei verschiedene Lösungsansätze kombiniert und zu einer finalen Lösung kombiniert werden.

Marcel Altherr (Inventique) und Cem Kulac (pragmatic solutions) werden diesen Workshop moderieren.

Die Anmeldung für den Event findet direkt bei SwissICT statt. Der Jubiläums-Event verspricht eine spannende und anregende Sache zu werden.

Ich war vor kurzem bei einem Kurs und bin so mal wieder mit der „Aussenwelt“ in Kontakt gekommen. Man unterhielt sich und plauderte auch über die eigene Arbeit, das Unternehmen und später sogar darüber was einen störte.  Ich war überrascht in was für Umgebungen so mancher meiner „neuen Kollegen“ arbeitet und wie Unternehmen mit ihren Mitarbeitern und Teams umgehen. Hier einige Beispiele:

  • Vor /während/ nach jedem Projekt werden die Mitarbeiter in neue Teams verschoben, weil dort „Not am Mann“ ist.
  • Während eines Projekts müssen sie sich prozentual aufteilen (20% hier, 10% dort, 30% ganz woanders), da das Wissen sonst nicht vorhanden ist.
  • Sie werden in Technologiekatekorien unterteilt, da jemand der Meinung ist so das Beste aus dem Team herauszuholen.

Schon 1965 beschrieb Bruce Tuckman die verschiedenen Phasen der Teambildung. Zu allererst wird das Team gebildet. Dabei versucht jeder keinem anderen auf die Füsse zu treten, sich anzupassen und akzeptiert zu werden (Forming). Nach einiger Zeit gibt es die ersten Reibereien und jeder versucht seine Ideen/Perspektiven den anderen näher zu bringen (Storming). Sollte das Team es schaffen in die nächste Phase überzugehen, steht das gemeinsame Ziel an oberster Stelle (Norming) und die eigenen Ziel treten in den Hintergrund. Einige der Teams schaffen es noch eine Stufe weiter: Performing – das Team funktioniert als eine Einheit und erledigt die Aufgaben reibungslos.

Somit sollte auch klar sein, das es nicht möglich ist Teams auf dem Papier zu erschaffen und zu hoffen, das daraus „High-Performance-Teams“ werden.

  • Jeder Mensch braucht Zeit um sich in Gruppen/Teams zurecht zu finden
  • Jeder einzelne in einem Team sollte zu 100% in diesem arbeiten.
  • Das Team sollte eine Technologie beherrschen, nicht nur Einzelne im Team.

Aber auch jedes „gestandene“ Team ist nicht vor diesen Veränderungen gefeit. Ein neues Teammitglied, ein neuer Vorgesetzter oder andere Umstrukturierungen innerhalb des Unternehmens können dazu führen, das ein Team alle Phasen erneut durchleben muss. Aus diesen Gründen sollten man allen Teams auch Zeit geben, um sich zu finden und die Chance zu erhalten ein „High-Performance-Team“ zu werden.

Immer wieder werde ich gefragt, ob es besser ist einen agilen Prozess mit einem „Big Bang“ in eine Organisation einzuführen, oder ob es nicht besser ist ganz langsam kleine Veränderungen  vorzunehmen, die man im Vorfeld mit der bestehenden Organisation austariert.

Ich will hier nicht sagen: „it depends“. Stattdessen ein paar Grundsätze, die sich aus der Erfahrung mit verschieden grossen Unternehmen ergeben:

  1. „Big Bang“ funktioniert selten.
  2. „Big Bang“ funktioniert nur, wenn das Top-Management voll dahinter steht und alle gemeinsam anpacken.
  3. „Alle gemeinsam“ bedeutet nicht nur eine kleine Schar von Eingeweihten.
  4. Ohne Einbezug aller (und vor allem derer, die die Hauptlast der Arbeit tragen, oder von der Veränderung am meisten Betroffen sind), ist der Effort zum Scheitern verurteilt.
  5. Man kann nicht nur eine Softwareentwicklungsabteilung in Isolation „transformieren“. Ohne den Einbezug des Fachs (sprich der Fachabteilungen, bzw. des Kunden) funktioniert gar nichts.
  6. Ohne Freiraum geht es nicht. Man kann nicht von seinen Mitarbeitern erwarten, dass sie den Entwicklungsprozess ändern, ohne dass sie die Zeit und Musse haben, sich selbst aktiv in die Veränderung einzubringen. Keiner wird dafür seine Freizeit opfern. Das kann man von niemandem erwarten!

Die Veränderung von Arbeitsweisen, von Gewohnheiten und das Schlachten von „heiligen Kühen“ stösst bereits selten auf Gegenliebe. Erschweren wir den Prozess nicht unnötig, sondern suchen nach Wegen, um das Unmögliche möglich zu machen!

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.