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!

Wenn Druck in ein Projekt reinkommt: Trotzdem Dinge richtig tun

In meiner Projektpraxis kommt es immer wieder vor, dass trotz großer Anstrengungen die Ergebnisse weit hinter den Plänen oder Erwartungen nachhinken. Nachfolgend finden Sie einige Empfehlungen, die in der Praxis helfen.

Die Ausgangslage: Alle im Projekt arbeiten mit großem Einsatz und dennoch sind Ziele, selbst wenn sie realistisch dimensioniert sind, was nicht immer der Fall ist J, nicht und nicht erreichbar. Die Projektleitung bzw. der Auftraggeber werden immer unzufriedener, wesentliche Entwicklungsziele werden re-priorisiert, Überstunden und Urlaubsverzicht eingefordert, die Projektmitarbeiter verlieren das Vertrauen an die Zielerreichung und die Projektleitung, … die Spirale dreht sich steil und eng nach unten.

Hier ist es wichtig, sich nicht vollständig vom Panik-Modus diktieren zu lassen und aktionistisch Maßnahmen zu setzen, die lediglich eine hektische Betriebsamkeit nach außen (zum Auftraggeber) vermitteln. Es gilt durch eine klare und strukturierte Vorgehensweise Maßnahmen in der richtigen Reihenfolge zu setzen.

In meiner Praxis haben sich folgende Prioritäten und Reihenfolgen als richtig herausgestellt:

  1. Abgestimmte Vorgehensweise der Entscheider
  2. Fokus auf Qualität
  3. Work in Progress-Limits einführen und einhalten
  4. Häufige Lieferungen
  5. Nachfrage und Durchsatz balancieren
  6. Das Richtige priorisieren
  7. Vorhersagbarkeit erhöhen

Wenn Sie nun „Work in Progress-Limits einführen“ oder „Häufige Lieferungen“ lesen, so ist das ein Indikator für agiles Vorgehen. Aber gleich an dieser Stelle der Widerruf: Nein, auch in der traditionellen Vorgehensweise kann man die Anzahl der gleichzeitig durchzuführenden Arbeiten sinnvoll dimensionieren und Zwischenergebnisse in Form von in sich abgeschlossenen Artefakten liefern und mit den betroffenen Stakeholdern bzw. Projektleitern, Fachbereich, Analysten, Programmierer und Testern besprechen.

Trotz Druck die richtigen Dinge tun

Trotz Druck die richtigen Dinge tun

1. Abgestimmte Vorgehensweise der Entscheider

Neben den klassischen Rollen, wie beispielsweise dem Projektleiter, gibt es eine Vielzahl von steuernden Personen im Projekt. Product Owner, Featureteam-Leiter, Release Manager, Delivery Manager, usw. Oft genug verfolgen alle Beteiligten unterschiedliche Prioritäten, ein gemeinsamer Plan existiert nicht.

Ein enger Schulterschluss der „Entscheider“ ist in solchen Situationen dringend notwendig. Es gilt, den Kreis der Entscheider zu identifizieren und zu einer engen, zyklischen Abstimmung auf Basis eines abgestimmten Plans zu bringen. Aus dieser Gruppe kommen die wesentlichen Impulse und next steps für das gesamte Projekt. Es empfiehlt sich, den Kreis der Entscheider klein zu halten (max. 5-6 Personen), sich mindestens 1 x pro Woche ernsthaft zu einer Abstimmung zu treffen – pünktlich, ohne Störungen, ohne überboardender Dominanz des Tagesgeschäfts (sonst kommen strategische Punkte zu kurz!), usw.

In meiner Praxis hat sich auch eine 70-100-Regel bei Entscheidungen als günstig erwiesen: Wenn im Entscheiderteam jeder zumindest zu 70% hinter einer Entscheidungen stehen kann, dann wird diese Entscheidung zu 100% getragen. Politisches Kleingeld á la „Ich will das ja auch nicht, aber die da haben so entschieden“ zu machen schwächt das Entscheiderteam nachhaltig.

2. Fokus auf Qualität

„Wir nehmen uns gerne die Zeit, Dinge immer wieder zu machen – statt sie einmal richtig zu tun.“ Natürlich ist bei fehlender Qualität (Defects, nicht erfüllte Requirements, usw.) ein deutlicher Mehraufwand, der durch Korrektur, neuerlicher Q-Sicherung, Deployment, Einführung, usw. entsteht, mehr Zeit in die Entwicklung eines Features gelaufen. Auch das Vertrauen in die Akteure sinkt („Die produzieren nur Mist“). Gerne unterschätzt wird auch, dass alle an der Korrektur beteiligten Personen immer wieder und wieder aus den laufenden Arbeiten herausgerissen werden um den oder die Fehler zu beseitigen. Dadurch kommt man in den gefährlichen Multitasking-Modus, mit dem daraus resultierenden Mehr an neuen Fehlern und deutlichem Mehr an Zeitbedarf für alles.

3. Work in Progress-Limits einführen und einhalten

Kommt ein Projekt unter Druck, wird durch schlechte Projektleitungen noch mehr Öl ins Feuer gegossen, indem noch mehr gleichzeitige Tasks beauftragt werden („Schlagzahl erhöhen“) oder der vorliegende Plan ohne Feedback aus den Ergebnissen des Projekts stumpfsinnig eingehalten wird. Die Projektleitung ist von außen oberflächlich betrachtet fein raus – sie hat ja alles getan, was möglich und geplant war („Alles ist im Laufen, jetzt müssen die Teams nur noch liefern“).

Eine professionelle Projektleitung konzentriert sich auf die optimale Aus- bzw. Belastung der Teams und die Beseitigung von Schwachstellen und Bottlenecks. Auch wenn es an dieser Stelle bedeutet, ein re-planning zu machen. Je früher klar ist, wie es um den Projektplan wirklich bestellt ist, desto mehr Zeit hat das Projekt Maßnahmen zur Zielerreichung zu ergreifen.

Zur Optimierung des Outputs hat sich die Einführung von Work in Progress-, kurz WiP-, Limits herauskristallisiert. Man belastet die Teams mit wenigen, gleichzeitigen Tasks, verkürzt aber damit substanziell die Durchlaufzeit der einzelnen Tasks, da Overheads durch Taskswitching vermieden werden und zwei weitere Super-Effekte entstehen: Es gibt für den Auftraggeber (Product Owner und Co) rascher Feedback (à häufige Lieferungen) und für neuerliche Tasks kann sich der Auftraggeber später entscheiden, was er genau haben will („late commitment“).

4. Häufige Lieferungen

Die Basisüberlegung dazu: Vertrauen in Akteure wird dann etabliert, wenn diese oft Zugesagtes einhalten. Im Gegensatz zu ein bis zwei Lieferungen pro Jahr hat man durch Lieferungen alle zwei bis vier Wochen öfters die Chance Vertrauen zu gewinnen.

In einem kritischen Projektverlauf ist es besser, öfters nachzuweisen, dass alles im Lot ist. Sich für 6 Monate wegzusperren und nichts zu liefern erhöht die Unsicherheit beim Auftraggeber.

Ein weiterer Vorteil, der sich durch häufige Lieferungen ergibt: Integration wird bei der Herstellung der einzelnen Artefakte im Rahmen der Definition-of-Done (DoD) erledigt und ein späteres Scheitern aus Integrationsproblemen, insbesondere wahrscheinlich bei großen Projekten, verhindert.

5. Nachfrage und Durchsatz balancieren

Gerade wenn unterschiedliche Auftraggeber, z.B. verschiedene Fachbereiche, Anforderungen an das Projekt stellen (können), ist ein Gatekeeping an der Eingangsseite des Projekts wichtig. Es ist notwendig, die eigene Kapazität als Kennzahl parat zu haben und im Zweifelsfalls die Auftraggeber selbst entscheiden zu lassen, welche Anforderung welche Priorität hat. Natürlich wird der Fachbereich damit argumentieren, dass wenn „Feature X nicht bis Datum Y fertig wird die Ziele des Fachbereichs nicht erreicht werden können“ und daran „die Projektleitung Schuld hat!“. Dieser Schlagabtausch ist normal und im Regelfall, wenn die Kapazitätsplanung fundiert vermittelt wird, schnell wieder vorbei. Schafft es die Projektleitung zwischen den einzelnen Gruppen der Anforderer ein wechselseitiges Geben-und-Nehmen zu etablieren, ist das perfekt. Jedoch fokussiert sich in der Praxis die Projektleitung leider zu sehr darauf eher mehr reinzunehmen und die eigene Mannschaft die sprichwörtliche Suppe auslöffeln zu lassen.

Schafft man es, Nachfrage und Durchsatz zu balancieren, wird das Projekt in Richtung optimaler Auslastung mehr Output schaffen. Durch kontinuierliche Verbesserung des projektinternen Wertschöpfungsprozesses, weniger Störungen durch Überlastung und etablierten Teams, die wissen, was sie wie leisten können, wird die Kapazität des Projekts kontinuierlich wachsen – was wiederum zu mehr Nachfragen führen wird.

6. Das Richtige priorisieren

Es gilt, die aus Sicht des Business Value hochwertigsten Features zu priorisieren. Hauptproblem: Oft ist die Bewertung des Werts durch die jahrelange Rechtfertigungspolitik in den Unternehmen wertlos geworden („Für jede Änderung lässt sich ein Business Case berechnen!“). Nach der Realisierung ist eine Total-Cost-of-Ownership (TCO) Berechnung für das Projekt ziemlich wertlos: Das Feature wurde ja bereits realisiert und hat das Projekt belastet. Oder es werden Listen mit Kriterien, wie „potentieller Gewinn“ und „potentieller Schaden“ geführt – allerdings ohne gemeinsames Spielverständnis.

Also, wie damit umgehen? Eine Möglichkeit ist das Schaffen einer klaren Business Value Bewertung, die die zugrundeliegenden Strategien (mehr Umsatz, mehr Kunden, mehr…) berücksichtigt und Änderungen der Strategie mitnehmen kann. Diese Bewertung ist mit den Auftraggebern und den planungsverantwortlichen im Projekt gemeinsam zu schaffen.

Weiteres Aspekte in Richtung das Richtige zu tun:

  • Durchstich-Strategie, d.h. zuerst das Feature in einer funktionalen Basis herzustellen und es erst in Folge zu „behübschen“; damit gibt es die Funktion in der Basis und falls letztendlich Ressourcen knapp werden, gibt es die Funktion zumindest in einer einfachen Variante
  • Risikobasierte Priorisierung, d.h. jene Features mit der größten Wahrscheinlichkeit zu Scheitern, zuerst schaffen: Zuerst Unbekanntes und Neues angehen, Bekanntes ist ja leichter herzustellen
  • Silobildung vermeiden, d.h. Prüfungen aus fachlicher oder technischer Architektur bei allen Anforderungen gewährleisten, insbesondere dann wichtig, wenn im Projekt in einzelnen Teams entwickelt wird

7. Vorhersagbarkeit erhöhen

Ein guter Witz basiert darauf, überraschend zu sein à ohne Überraschungsmoment gibt es keinen guten Witz. Aber: Ein Projekt ist jedoch kein Witz. Je vorhersagbarer Lieferungen des Projekts werden – und es geht hier im Kern um Termine, Kosten und Qualität – desto mehr Vertrauen werden alle Stakeholder in die Leistungen des Projekts haben. Abstimmungen zwischen Auftraggebern werden dadurch vereinfacht – diese brauchen keine überdimensionierten Sicherheiten in ihre Pläne einchecken und reduzieren daher die Anforderungen an das Projekt, das deshalb auch entspannter wird. Die mit der Umsetzung betrauten Projektmitarbeiter des Teams werden ebenfalls durch bessere Vorhersagbarkeit profitieren (Optimierungen der Arbeiten bis hin zu verlässlicheren Freizeiten, usw.) und sich besser auf die jeweilige Situation einstellen können.

Abhängig davon, in welchem Projektmanagement-Framework entwickelt wird (Scrum, DSDM, FDD, Kanban, Wasserfall, V-Modell, etc.) werden Schätzungen und Messungen dabei helfen, vorhersagbarer zu werden. Wichtig ist in allen Fällen, dass die Zielerreichung auch wirklich projektinterne Kultur ist.

Referenzen:

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

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

„Nicht reproduzierbare Defects sind reproduzierbar!“ – Serie: „Aus der Praxis – für die Praxis― weixis Beitrag für bessere Software

Nicht reproduzierbare Defects können die teuersten Probleme sein, mit denen sich Tester beschäftigen sollten.

Worum geht‘s?

Manchmal (?) verhält sich ein Testobjekt so, dass ein erkannter (?) Defect nicht mehr (einfach) nachgestellt werden kann. Hoffentlich tauchen zu diesem Zeitpunkt viele Fragen auf: War die Beobachtung korrekt? Hat mein Test das Ergebnis verändert? Was waren die Bedingungen für die Abweichungen? Hab ich was übersehen? Was soll ich machen – einfach ignorieren oder trotzdem als Defect melden?

Gehen wir davon aus, dass Sie sich auf andere Punkte konzentrieren wollen und Sie ignorieren das Problem als einmaligen „SW-Ausrutscher, der nur viel Aufwand kostet“. Die möglichen Konsequenzen? Die Software wird an den Endkunden geliefert und dann taucht dieses Problem dort auf. Die Auswirkung des Problems korreliert im Regelfall mit dem entstandenen Schaden: Von einer Kleinigkeit, die nicht mehr kommt, bis hin zum Problem, dass die SW nicht eingesetzt werden kann („Blocker“). Spätestens jetzt tritt das Supportteam auf den Plan, will Zugriff zur Kunden IT und Betriebsführung, Datenabzügen usw. – viele Dinge, um das Problem vor Ort nachzustellen, aber eben auch viele Dinge, die den Kunden weiter beanspruchen und damit verärgern. Es ist klar: Hier ist dem Problem bereits im Test kreativ nachzusetzen!

Was tun?

Mehr von diesem Beitrag lesen

„Der beste Tester…“ aus der Serie: „Aus der Praxis – für die Praxis“ – weixis Beitrag für bessere Software

Oder: „Abweichungen sind die Trüffeln der Software-Tester-Suche“

Für uns bei SEQIS steht diese Einstellung zu Abweichungen seit sicher 10 Jahren bereits fest: Der beste Tester ist nicht der, der die meisten Fehler findet (→ rein destruktiver Fokus). Der beste Tester ist jener, der die meisten Probleme gelöst bekommt (→ konstruktiver Ansatz)!

Doch was kann ein Tester tun, damit er „die Probleme gelöst bekommt?“ – Nun, hier haben sich in den letzten Jahren einige gute Standards etabliert, allen voran natürlich auch Normen wie die IEEE 1044-2009 (= IEEE Standard Classification for Software Anomalies). Kurz beschrieben definiert dieser Standard die Abweichungsklassifikation in vier Schritten (Erkennen, Analysieren, Beheben und Abschließen (i.S. von Lösen, Verwerfen oder Konservieren)). Soweit, so gut.

Doch was macht mich als Tester und „meine Abweichungsbeschreibung“ zum Freund der Entwicklung? Eigentlich auch einfach: Objektivität, Klarheit und ein bisserl G‘fühl für die Sache. Mehr von diesem Beitrag lesen

%d Bloggern gefällt das: