Teambuilding-Konzepte für verteilte Teams

APIs, der digitale Klebstoff – damit verbinden wir Komponenten oder Systeme zu einem Ganzen, sind Cloud-aware, flexibel, skalierbar, modular. Durch das Angebot gut dokumentierter Programmierschnittstellen (API) kann unsere Software einen erheblichen Wettbewerbsvorteil für sich verbuchen, wenn Skalierung durch teamfremde (ggf. externe) Entwickler realisierbar ist.

Soweit, so gut. Schaut man hinter die Kulissen auf die Akteure, so haben wir es oft mit „virtuellen Teams“ zu tun. Synonyme gefällig? Gerne: „verteilte Teams“, „Homework“ oder „Telearbeit“. Wenn wir aber eines aus den agilen Werten und Prinzipien gelernt haben, dann sind Kommunikation und Nähe zwischen den Akteuren die Ausgangspunkte erfolgreicher Projekte. Technologien, wie APIs, die eine Verteilung unterstützen, sind generell neutral – aber es kommt darauf an, wie man den damit verbundenen Herausforderungen begegnet. Klar, je weiter entfernt die Menschen von einander arbeiten, sei es aus Sicht der Örtlichkeit, der Zeitzonen, der Kultur, der Sprache – die Kommunikation wird bei verteilten Teams bedeutend schwieriger und ja, die zwischenmenschliche Nähe leidet besonders.

Teambuilding – mehr als nur  gemeinsam auf ein Bier

Was ist falsch am gemeinsamen Bier? Vordergründig: Nichts, passt gut und gehört klarerweise dazu! Ich werde selbst nach Jahren immer wieder zu einem gemeinsamen Bier mit ehemaligen Kollegen eingeladen und nutze diese Gelegenheiten sehr gerne :-). Aber mal ehrlich: Worüber spricht man beim gemeinsamen Bier? Den Projektstatus und Co. Wenn’s gut läuft, dann redet man auch über Fußball und/oder über’s Kino, weil man eben neben der gemeinsamen Arbeit auch noch andere Interessen teilt. Auf den zweiten Blick wird aber klar, dass man sich kaum über sich, das Team selbst, unterhält. Vergessen wir nicht: Jedes Team, egal ob co-located oder verteilt auf den ganzen Planeten, macht nach -> Bruce Tuckman initial oder nach Teamänderungen mehr oder weniger intensiv die vier Phasen „Forming“, „Storming“, „Norming“ und „Performing“ durch.

Teambuilding-Phasen nach Tuckman

Teambuilding-Phasen nach Tuckman

Es macht sich bezahlt in diesen Teambuilding-Prozess aktiv einzugreifen und dabei zu helfen, das Team in die nächste Phase zu heben. Eine in meiner Praxis bewährte Methode sind teaminterne Diskussionen, unterstützt z.B. durch Metaplantechniken, in denen sich das Team zu folgenden Fragen austauscht:
    • Was erwarte ich – an Prozessen und Rahmenbedingungen?
    • Was kann ich einbringen – an Programmiersprachen, Requirements Engineering Techniken, im Test, etc.?
    • Wie sollten wir miteinander umgehen – Klärung zu Aspekten wie Fehlerkultur, Offenheit, usw.
Performing Team

Performing Team

Es hilft auch, wenn man den Team’s Vorträge über Konfliktbewusstsein anbietet oder auch in diesem Kontext auf Retrospektiven setzt: Nicht nur prozessual und arbeitstechnisch sich zu fragen, was läuft gut und „was wollen wir verbessern“, sondern auch nochmals einen Blick auf die Metaplan-Antworten und checken, ob das auch noch passt.

Für bewusstes Teambuilding muss man die Teambuilding-Phasen bewusst machen und Aktivitäten setzen, die die Team-Irritationen so gering wie möglich halten.

In einem Projekt vor einiger Zeit hatten wir z.B. immer bei Abstimmung- und Planungsterminen auch die Frage: „Wie geht es uns als Team?“ Ein fortschrittlicher Ansatz, wie gesagt, auch schon vor einiger Zeit gelebte Praxis.

Physical closeness -> Mental closeness
Eine weitere Methode um „Nähe“ zwischen den Teammitgliedern herzustellen, habe ich von Jürgen Apello („How to Improve Team Collaboration with Personal Maps“1) gelernt: Er empfiehlt verteilten Teams die Erstellung von sogenannten Personal Maps. Jeder erstellt eine Mindmap über sich selbst und thematisiert darin Hobbies, Ausbildung und weiteres Wissenswertes über sich. Im Anschluss stellt jeweils ein Teammitglied ein anderes auf Basis der Personal Map vor. Er adressiert damit eine mentale Nähe zwischen den Teammitgliedern …

Wir bei SEQIS stehen ebenfalls vor der Herausforderung, dass die einzelnen (organisatorischen) Teams bei jeweils unterschiedlichen Kunden im Einsatz sind – und trotzdem soll und muss der Teamspirit passen und die Zusammenarbeit in den Teams stimmen. Daher haben wir diese Methode bei unserem letzten 4-tägigen Geschäftsjahres-KickOff -Meeting im Selbstversuch ausprobiert. Im Gegensatz zu einer Skype-Session konnten wir das in einem gemeinsamen Meeting-Saal machen. Den konkreten Setup können Sie beiliegender Abbildung entnehmen. Ergebnis: This rocks – und wurde von nahezu allen SEQISANERN im Rahmen des Gesamtfeedbacks zum Treffen thematisiert.

Personal Map - Setup

Personal Map – Setup

Das war noch nicht alles…
Neben den oben stehenden Empfehlungen nachfolgend noch eine Sammlung zur Verbesserung der Kommunikation und zur Förderung von Nähe bei verteilten Teams und Teammitgliedern, die in meinen Projekten funktioniert haben:

  • Definition einer Team Charter (= Teamroadmap, Absicherung, dass alle auf das Richtige fokussiert sind) inkl. Rollen, Verantwortlichkeiten, Ziele und Art-und-Weise, wie gearbeitet wird
  • Strenge Kommunikationsstrategie: Besonders wichtig, wenn das Team in unterschiedlichen Zeitzonen beheimatet ist und unterschiedliche Sprachen spricht
  • Ordentlicher technischer Support: Videokonferenzen, Instant Messaging, VoIP, … sind super, wenn sie auch wirklich funktionieren
  • Genaue Beobachtung der Individual-Performance: Bei Veränderung des Outputs, geringerer Mitarbeit, etc. kann auch im Hintergrund ein Burnout oder anderes lauern. Denken Sie daran: Sie sehen die Kollegen nicht, nonverbale Kommunikation fällt nahezu flach
  • Schaffen Sie Raum für Gemeinsames: Setzen Sie eine Intranet-Teampage auf, verwenden Sie ggf. Webcams
  • Vergessen Sie nicht auf Feedback: Ein Kollege hat ins Projekt-Social Network einen interessanten Artikel gepostet? Geben Sie Feedback!
  • Belohnen Sie außergewöhnliche Leistungen: Etablieren Sie teaminterne Punkte-/Leistungssysteme und vergessen Sie nicht darauf, dass physische Belohnungen gerne durch Post und Co. rund um den Planeten geliefert werden

… diese Liste ist natürlich nicht abschließend!

Haben Sie weitere Empfehlungen? -> Ich freue mich auf Ihre Kommentare!

Advertisements

Agile Projekte – potentiell gesünder als andere!

Passend zum Jahresstart kommen Vorsätze immer wieder gerne ins Gespräch: „Na, wie gehst du 2015 an? Was hast du dir vorgenommen?“ An dieser Stelle trennen sich die Feedbacks leider selten in Streu und Weizen. Üblicherweise erfährt man Begeisterung für eine Sache („Ich werde mehr Sport machen.“, „Ich werde endlich das Rauchen aufgeben.“) oder Resignation („Macht eh alles keinen Sinn – die Projektleitung plant ohnehin was sie will!“). Ob erstere Vorhaben wirklich nachhaltig sind, sieht man üblicherweise nach 3 Wochen bis 6 Monaten. Was gibt es über die „Macht-eh alles- keinen-Sinn“-Seite zu sagen? Die meisten Neujahrs-Vorsätze haben etwas mit Zeit zu tun – Zeit für sich (Sport, Ausbildung, Hobbies,…), Zeit für die Familie oder einfach weniger Stress im Sinne von weniger Arbeiten.

Lösen wir die Frage, wie wir besser mit unserer Zeit umgehen, so lösen wir diesen Knackpunkt und haben gute Aussichten auf ein wirklich gutes, neues Jahr!

Schauen wir uns also den Aspekt eines nachhaltigen Arbeitstempos an. Ein nachhaltiges Arbeitstempo für die IT entspricht mindestens folgenden Kriterien:

  1. Die 40h-Woche als Ausgangsbasis
  2. Gezielter Einsatz von Überstunden
  3. Vermeiden von Task-Switching und „schnell mal was einschieben“
  4. Verstehen, dass Softwareentwicklung kein Sprint, sondern ein Marathon ist. Die Teams müssen durch entsprechende Planungen geschützt werden

Die 40h-Woche für die Planung des Arbeitstempos/-umfangs sollte als Ausgangsbasis ausreichend sein. Dies entspricht u.a. auch der Forderung der agile Community im Jahre 2002. [Beck2000] Natürlich gibt es immer wieder Aussagen dazu, dass diese Arbeitseinstellung in Europa lächerlich wäre: „[…] erfolgreiche Unternehmer in China arbeiten 80 oder 100 Stunden pro Woche.“ [Meyer-2012] Diese Aussagen kommen zumeist von Personen, die auch wissen: „[…] Zugegeben: Auch ich sähe besser aus, wenn ich weniger arbeiten, mehr Sport treiben und mehr schlafen würde.“ [Meyer-2012] Wie weit man gehen will/kann, sollte jeder für sich selbst entscheiden. Für andere zu planen bedeutet jedoch Verantwortung zu übernehmen und darf nichts mit übertriebener Geltungssucht zu tun haben. Nachhaltiges Arbeitstempo bedeutet nicht, dass die Teams kontinuierlich auf gleichem Arbeitsniveau weiter arbeiten – kurz vor der Ziellinie muss auch mal, im wahrsten Sinnes des Wortes, ein Sprint hingelegt werden können. Werden für die eine Woche Überstunden angeordnet, sollten sie auf keinen Fall für die folgende Woche wieder angeordnet werden müssen.

Agile Prinzipien für Optimierungen: Gerade im agilen Methodenstack werden durch eine Reihe von Grundprinzipien Werkzeuge etabliert, die ernsthafte Optimierungen zulassen:

  • Pull, statt Push: Ich hole mir Arbeit, wenn ich wieder frei bin
  • Team-Commitment: Wir stimmen Zielen zu und laufen gemeinsam dafür
  • Eigenverantwortung im Team: Wir wissen, was wir wie können und machen müssen, damit der Plan, den wir kennen, halten kann
  • Forderung nach ausschließlicher Belastung der Teams mit Entwicklungen, die „Business-Value“ schaffen
  • Flexibel für späte/kurzfristige Änderungen durch „Late-Commitment“
  • Analyse und Reduktion von Engpässen (Retrospektiven)
  • Realisierung in Inkrementen – Reduktion von Skalierungsrisiken und die Möglichkeit, kontinuierlich zu lernen

Sonst liegt ein Problem vor, dass allgemein nicht durch Leisten von Überstunden zu lösen ist. [Beck/Andres-2004] Ein weiterer Irrglaube in der heutigen Be- und Auslastung von IT-Ressourcen liegt in der Überlegung, Personen mit vielen und oft unterschiedlichen Arbeiten gleichzeitig (!) zu belasten und dabei implizit Task-Switching zu verlangen. (Hintergrund der Überlegung: Durch „schnell mal was einschieben“ Ziele erreichen). Der Blick in John Medina’s Buch „Gehirn und Erfolg“ macht’s klar: Multitasking bedeutet 50% mehr Zeit bei 50% geringerer Qualität (im Sinne von mehr Fehler!). Die gleichen Basisüberlegungen finden wir auch bei flussbasierten Sys temen, wie z.B. Kanban, wieder. Dort spricht man von „Stop starting, start finishing“ und meint, dass Begonnenes zu beenden ist, bevor man etwas Neues beginnt. Natürlich durch sogenannte Work-in-Progress-Limits („WiP-Limit“) optimiert für die jeweilige Tätigkeit oder Person.

Verfolgt man David Andersons Suche nach dem nachhaltigen Arbeitstempo, so kommt bei ihm sehr rasch die Empfehlung, Teams vor „verrückten Zeitplänen und absurden Verpflichtungen“ zu schützen. Mehr Features oder weitere Produkte zu verlangen, obwohl die Entwicklungskapazität bereits voll ausgelastet ist, ist Unsinn. [Anderson-2012] 40h-Woche, überlegte Überstunden, Multitasking vermeiden und Teams vor Übermenschlichem schützen – ist das realistisch? Nun, ich meine ja. Wir müssen verstehen, dass ein 18-Monate Projekt mehr einem Marathon als einem 100m-Lauf entspricht. Ob und wie diese und andere (agile) Aspekte zum Wohl des Teams und zu ordentlicher Wirtschaftlichkeit im Projekt oder der Abteilung führen, hängt vom Willen zur (Prozess-) Optimierung, einem klaren methodischen Vorgehen zur Analyse der Situation und einem fundierten Change-Management der Organisationen ab.

Referenzen:

[Beck/Andres-2004] – Kent Beck, Cynthia Andres, „Extreme Programming Explained“, 2004

[MEYER-2012] – http://www.welt.de/finanzen/article13863020/Unsere-40-Stunden-Woche-in-Europa-ist-laecherlich.html, 17.1.2015, 07:55

[Anderson-2012] – David Anderson, „Kanban – Evolutionäres Change Management für IT-Organisationen“, 2012

Moderne Business Analyse schreit nach Agilität! Der CABA-Zertifikatskurs ist das Echo!

Neue Herausforderungen in der Business Analyse

Angesichts der sich immer rapider verändernden Marktbedingungen stehen Unternehmen vor neuen Herausforderungen, wenn sie Kundenwünsche weiterhin erfüllen wollen. Prozesse, Organisationsstrukturen, konkrete Projektanforderungen sowie die Unternehmensstrategie müssen berücksichtigt und Kundenbedürfnisse frühzeitig erkannt werden. Hochkomplexe Technologien und Programme unterstützen Unternehmen bei allen Geschäftsprozessen. Die Komplexität der Anforderungen an diese Systeme verlangt nach erfahrenen Business Analysten. Nicht nur die Probleme zu analysieren, sondern auch Lösungen vorzuschlagen und zu entwerfen sowie die Bedürfnisse der verschiedenen Stakeholder im IT-Projekt zu berücksichtigen – das ist das Ziel in der professionellen Business Analyse. Verschiedene Standardisierungen haben dieser Profession darüber hinaus einen gewaltigen Qualitätsschub gebracht.

Business Analyse in agilen Teams

Die Schnelllebigkeit der Technologien, kurze Produktlebenszyklen und kurzfristige Anforderungsänderungen in IT-Projekten lassen die IT-Projektleiter in Sachen Agilität aufhorchen. Der Trend geht klar in Richtung agiler Methoden. Diese beeinflussen auch wesentlich die Rolle des Business Analysten. Die  Zusammenarbeit in agilen Teams eröffnet für jede Position im Projekt eine Vielzahl an neuen Möglichkeiten und Verbesserungen. Agilität verändert die Sicht auf Anforderungen und den Zeitpunkt, wann diese im Prozess definiert werden. Team- und Begeisterungsfähigkeit, Problemlösungskompetenz, Leadership und Coaching werden zu noch gefragteren (Soft) Skills-Anforderungen für Business Analysten in agilen Teams.

CABA (iSQI® Certified Agile Business Analysis): Business Analyse agil gemacht, statt auf die leichte Schulter genommen!

Genau auf diese Anforderungen an die moderne Business Analyse geht CABA ein. Bei CABA geht es um die Umsetzung bewährter Standards in der Business Analyse in Kombination mit den innovativen Methoden einer agilen Arbeitsweise. Agile Methoden werden in den professionellen Analyseprozess integriert. Damit kann der Output von Unternehmen deutlich gesteigert werden.

iSQI®, das International Software Quality Institute, hat auf diesen Trend reagiert und die Zertifikatsausbildung CABA (iSQI® Certified Agile Business Analysis) entwickelt. Für SEQIS, dem Agilitätsvorreiter und Spezialisten in der Business Analyse, ist es naheliegend, Business Analysten und Requirements Engineers eine Einführung in die beiden Steckenpferde des Qualitätsprofis zu ermöglichen. Die langjährige Expertise im Bereich Business Analyse und die Best Practices aus unzähligen, aufregenden IT-Projekten bilden das Fundament für diese empfehlenswerte Zertifikatsausbildung, die jeden Business Analysten und Requirements Engineer, aber auch jeden agilen Entwickler bereichert.

SEQIS: Erster CABA-Trainingsprovider in Österreich

Ich habe als erster SEQISANER die Ausbildung zum CABA-Trainer absolviert und gebe nun meine Erfahrung bei den SEQIS CABA-Kursen weiter. Der Kern der Schulung basiert auf der „Agile Extension to the BABOK® Guide“ vom International Institute of Business Analysis (IIBA). Sieben Prinzipien der agilen Business Analyse begleiten den Business Analysten im agilen Umfeld von der Erhebung der Anforderungen bis zur Auslieferung des Produkts. Auch die Analyse des Unternehmens und deren Prozesse spielt dabei eine entscheidende Rolle. Zu jedem dieser sieben Prinzipien werden Techniken und Methoden vorgestellt, welche mit zahlreichen Übungsbeispielen praxisnah trainiert werden.

Der Zertifizierungskurs zur iSQI® Certified Agile Business Analysis ist ein echtes Muss für alle Business Analysten, da die erlernten Methoden nicht nur im agilen, sondern auch im klassischen Umfeld angewandt werden können. Auch agile Entwickler können mit der CABA-Zertifizierung ihr Generalisten-Knowhow weiter verbreitern, um so noch wertvoller für das agile Team zu werden.

Agile rocks Business – Test Driven Development in der Praxis

Agile rocks Business.

Flexibel auf geänderte (Business-)Anforderungen reagieren können, die Forderung nach raschen time-to-market erfüllen können, trotzdem im Umgang mit Menschen respektvoll sein und Spaß an den Erfolgen des Teams haben können! So oder so ähnlich kann man agile Entwicklung zusammenfassen. Wichtig bei all dem ist die Identifikation des gesamten Teams mit der geteilten Aufgabe der Qualitätssicherung („collective quality ownership“). Eine der mittlerweile immer interessanter werdenden Standard Methoden die hierbei zum Einsatz kommen ist Test Driven Development, kurz TDD. Hierbei geht es um  das entwicklungsnahe Testen bzw. das testnahe Entwickeln. Bei dieser testgetriebenen Entwicklung erstellt der Programmierer die Tests bevor er die jeweiligen dazu gehörige Business Logik erstellt.

TDD in der Praxis – „Red, Green, Refactor“

Test Driven Development wird oft zu Unrecht als „unnötiger zusätzlicher Aufwand“, sowohl bei Entwicklern als auch im Management, eingeschätzt. TDD zwingt den Entwickler vor der eigentlichen Umsetzung der Business Logik die zugehörigen Unit Tests zu schreiben – „Es darf keine Business Logik implementiert werden ohne zugehörigen, fehlschlagenden Unit Test“. Zusätzlich ist eine fixe Verbesserungsphase, so genanntes „Refactoring“ eingeplant, die für qualitativ hochwertige Ergebnisse sorgen soll. Diese drei Phasen der Entwicklung – Unit Test schreiben, Business Logik umsetzen, Code verbessern – werden iterativ bis zur fertigen Lösung fortgesetzt.

Das führt im ersten Blick zu mehr Aufwand, aber auch nur aus dem Grund, dass Unit Tests im Allgemeinen viel zu wenig Aufmerksamkeit in der Vergangenheit bekommen haben. Aber TDD geht noch viel weiter als einfach nur die Testfälle vor der Business Logik zu schreiben: TDD ist eine Methode, die den Fokus auf qualitativ hochwertige Ergebnisse legt! Naming, Duplication und ein gutes Design sind nur einige wichtige Punkte, die in TDD groß geschrieben werden.

Die Vorteile von TDD

Ein Vorteil liegt auf der Hand: Durch den Einsatz von TDD erreicht man eine theoretische Code Coverage der Business Logik von 100%. Oben drauf bekommt man mit dem Fokus auf Naming und Design einen auf Lange Sicht wartbaren Code. Die Entwickler können durch das dicht gewebte Sicherheitsnetz der Unit Tests ohne Gefahr große Teile der Business Logik bei Bedarf neu erstellen, denn: Die Anforderungen an die Business Logik sind in den Unit Tests persistiert und die korrekte Umsetzung kann laufend sichergestellt werden.

Ein weiterer und nicht unwesentlicher Vorteil wird durch TDD erreicht: die Entwickler sollen wieder zufrieden und stolz auf deren Machwerk blicken können. Software Craftsmanship wird groß geschrieben, weg von Programmiermaschinen. Und zufriedene Arbeiter leisten doch zu meist auch gute Arbeit.

%d Bloggern gefällt das: