Digitale Kompetenz

Ein Herzensprojekt. Digitale Kompetenz verpackt in einem (nicht ganz perfekten) Buch.

 

Als Druck oder E-Book bestellen

 

 

Die moderne Arbeitswelt – Leadership. Explained.

Hurra, Corona hat der modernen Arbeitswelt einen Schub verliehen. Mitarbeiter tauschen sich per Videokonferenzen aus, chatten und gehen selbst organisiert durch den Tag. Die schon lange gepredigte Form von „Servant Leadership“ kommt nun auch endlich in den Köpfen der Konzerne an.

 

Sollte man meinen.

 

Denn eigentlich hat sich in den meisten Unternehmen nur der Ort geändert, an dem die Tätigkeit verrichtet wird. Vom Großraumbüro in das heimische Wohnzimmer. Teamleiter kommen mit Worten „Wo und wann Du die Arbeit erledigst, ist mir egal. Hauptsache Du erledigst die Dir zugeteilten Aufgaben.“

 

Zauberhafte Freiheit, doch eigentlich schwebt in diesem Satz klassisches Führungsverhalten. Eine Führungskraft weist seinen Untertanen diverse Aufgaben zu und hofft auf effiziente Erfüllung derer. Das ist jedoch weit weg von dem Zielbild das New Work und agile Arbeitsweisen zeichnen:

 

Wir möchten selbst organisierte Teams und Menschen, welche Entscheidungen treffen, Fehler tolerieren und sich dadurch selbst Aufgaben zuweisen. Ob dies aus dem Wohnzimmer, dem Strand oder der alten Burgruine aus geschieht, ist dabei absolut nebensächlich. Die Führungskraft ist nun ein wichtiger Bestandteil um Entscheidungen herbeizuführen und zu unterstützen. In einer freien Arbeitswelt benötigt es keine „Erlaubnis“ einen Wert zu generieren.

Veranstaltungen online durchführen

Schon wieder ist Corona schuld. Viele Mitarbeiter sitzen zu Hause und verrichten hochmotiviert die tägliche Arbeit mit Webex, Microsoft Teams oder Zoom. Um nur wenige Tools, die sich für die Online-Kommunikation bewährt haben, zu nennen.

 

Aber der Verzicht ist spürbar. Veranstaltungen, Workshops und Messen kommen ohne die richtigen Tools und Planung nicht so richtig voran.

 

Ich stelle Dir zwei Modelle vor, die sich bewährt haben. Die Beispiele gehen von einigen Annahmen aus:

 

- Es treffen sich viele Menschen (>10)

- Es werden „Breakout“ Sessions stattfinden.

- Interaktion ist erforderlich

 

Modell 1: Räume, Menschen, Übersicht

 

Zunächst starten wir mit einer Übersichtsseite. Dort sind alle Themen und zur Verfügung stehenden Räume (Links auf Konferenzen) aufgelistet. Eine „Lobby“ ist immer offen und der Startpunkt der Session. Nicht zu vergessen sind Links auf digitale Whiteboards. Hier ist Kreativität gefragt – damit sich auch wirklich alle wohlfühlen.

 

Bewährte Tools sind hier Confluence (oder eine Wiki-Seite), Miro oder Mural als Whiteboard-Lösung, Mentimeter für Gaming oder Umfragen. Der große Vorteil: in der Regel reicht eine Subscription aus, um Teilnehmer per Link einzuladen. Separate Accounts sind hier nicht notwendig.

 

Modell 2: Virtuelle Welt

 

Frisch aus der Kreativschmiede habe ich mir virtuelle Räume angesehen. Es ist relativ einfach, einen 3D-Raum zu erstellen, durch welchen man sich per Mausklick oder dem Tablet bewegen kann. 

 

Der große Vorteil zu Modell 1: Mit überschaubarem Aufwand bietet man ein einzigartiges Erlebnis.

 

Auch hier können alle erdenklichen Medien wie in Modell 1 integriert werden. Zusätzlich besteht die Möglichkeit, interaktive Elemente wie Videos zu integrieren. So macht die Session richtig Spaß. Wirkliche Einschränkungen gibt es nicht, das richtige Tool verwendet, lässt sich das Ganze auf einem einfachen HTTP-Server im Firmennetzwerk hosten.

 

Der Kreativität sind keine Grenzen gesetzt, die Tools die sich hierfür eignen sind Blender (zum Erstellen eines einfachen 3D-Modells), 3DVista (virtuelle Tour) und für offene Kommunikationsräume Jitsi (einfache Webkonferenz-Lösung). Es ist natürlich auch jede andere Video-Call Lösung integrierbar.

 

Hier zwei Beispiele:

 

mehr lesen

Corona: Tipps für verteilte Teams

Die Teams sitzen nicht mehr an einem Ort, die Kommunikation und Zusammenarbeit muß auch über die Entfernung gewährleistet werden. Das ist zwar nicht nur in Krisenzeiten der Fall, jetzt aber umso wichtiger.

 

Daher hier ein paar wertvolle Tipps:

 

Remote-Arbeit ist nicht böse

 

Zunächst einmal: der innere Schweinehund muß überwunden werden. Remote-Arbeit ist nicht böse. Sofern sich die Tätigkeit der Mitarbeiter mit Computer & Co. erledigen läßt, ist es unwahrscheinlich, daß die Produktivität dadurch sinkt. Vertrauen und Verantwortung ist angesagt.

 

Selber machen ist nicht besser

 

Unternehmen wie Microsoft, Cisco, Google und andere digitale Pioniere stecken schon jahrelang Energie in eine zuverlässige Infrastruktur. Auch wenn es in Stoßzeiten Engpässe gibt, so wird schnell darauf reagiert, so daß die Anwendungen zuverlässig zur Verfügung stehen. Ein Eigenbau ist teurer und weniger ausfallsicher.

 

VPN als Flaschenhals

 

 

Die Infrastruktur für VPN-Zugänge zum Unternehmensnetz werden in der Regel vom Unternehmen selbst verwaltet und zur Verfügung gestellt. Knotenpunkte werden dabei schnell zum Flaschenhals, wenn die Nachfrage steigt. Nutzen sie das VPN nur für Anwendungen, die nicht ohne Firmennetz verwendet werden können. Die meisten Collaboration-Anwendungen können ohne VPN genutzt werden.

 

Tools für Besprechungen

 

 

Hier die wichtigsten Tools für Online-Meetings – egal ob mit mehreren oder zu zweit. Die Tools stehen als Abonnement zur Verfügung, damit können Sie flexibel umgehen und bei Bedarf wieder darauf verzichten.

 

Microsoft Teams: Für etwa 100,- EUR im Jahr / Benutzer können Sie schnell und flexibel Ihre Mitarbeiter mit einem Account ausstatten. In den Kosten dabei: Einwahl per Telefon in die Konferenzen. Die Mitarbeiter können Chatten, Telefonieren und Dokumente austauschen. Unkompliziert mit allen Endgeräten. Gäste können kostenlos an Besprechungen teilnehmen.

 

Haben Sie bereits ein Office 365 Abo für, so steht die Einwahl per Telefon für etwa 40,- EUR im Jahr / Benutzer zur Verfügung.

 

Cisco Webex: Für etwa 150,- EUR im Jahr können Sie ebenfalls flexibel Video- und Telefonkonferenzen mit Cisco Webex ermöglichen. Auch hier können Gäste kostenlos an Besprechungen teilnehmen. Über das Modul Cisco Webex Teams können Sie auch hier Chaträume einrichten und den einfachen Austausch von Dokumenten ermöglichen. Telefoneinwahl in Konferenzen ist bereits inklusive.

 

Mindmeister: Ideen sammeln, Brainstorming durchführen und Meetings organisieren. Mit Mindmeister steht Ihnen für etwa 70,- EUR im Jahr eine Web-Anwendung hierfür zur Verfügung. Die Mindmaps können mit einem Link freigegeben werden, so daß auch Gäste (ohne Anmeldung und Kosten) direkt im Webbrowser mitarbeiten können.

 

Und zum Schluß:

 

Traditionell telefonieren oder modern mit Facetime am Handy – alles ist möglich. Die Rufumleitung vom Bürotelefon nach Hause nicht vergessen.

 

Wir die Internetleitung eng, verzichten Sie auf die Übertragung von Video in den Besprechungen und wählen sich zeitgleich per Telefon in die Besprechung ein (deaktivieren Sie die Audio-Optionen am Computer oder Handy).

In diesem Sinne, gutes Gelingen!

 

 


Der IoT Zeppelin

 

Die Welt von IoT (Internet of Things) vernetzt Sensoren, Geräte und ermöglicht deren Steuerung via Anwendungen (automatisiert oder über Interfaces für Computer und mobile Endgeräte).

 

Wie Agilität den Zeppelin zum fliegen bringt, möchte ich in diesem Beitrag kurz durchleuchten.

 

Hierfür ein kleiner Exkurs in die Architektur von IoT Szenarien:

 

Auf der einen Seite befinden sich Geräte und Aktoren (z.B. Steckdosen, Lampen, Sensoren und Schalter) diese kommunizieren über diverse Gateways mit einem Rechenzentrum (oder einer Cloud). In diesem Rechenzentrum werden Gerätedaten (z.B. Typ, Funktionsumfang und Internetadresse) verwaltet. Zusätzlich werden dort auch alle anfallenden Daten (z.B. Temperatur, Luftfeuchtigkeit, Helligkeit oder Ein/Aus Zustand) von den Geräten in einem „Data Lake“ gesammelt. Je nach Anwendungsfall und Menge der Endgeräte können dort mehrere Millionen Datensätze im Minutentakt eintreffen.

 

Damit diese Daten ausgewertet werden können, werden diese standardisiert und in einem Data Warehouse aufbereitet. Alternativ kann man darauf natürlich auch verzichten und alle Auswertungen, wenn möglich, direkt auf dem Data Lake ausführen.

 

Auf der anderen Seite befinden sich zahlreiche Anwendungen und Services, die Daten auswerten und Aktionen durchführen (z.B. Berechtigungen prüfen, Analysen und Machine Learning).

Da auch das IoT keinen Selbstzweck erfüllt, sondern einen Kundennutzen bringen möchte, sind alle Schichten für den Kunden relevant. So hilft es dem Kunden beispielhaft nichts, wenn er eine sichere Cloud Anbindung bekommt, jedoch keine Steuerungsanwendung.

 

Ebenso betreten viele IoT Anwendungen absolutes Neuland, weshalb eine vorausschauend realistische Planung unmöglich wird (insbesondere über Funktionen und Möglichkeiten).

 

Daher ist eine iterative Produktentwicklung zielführend und anzuraten.

Im ersten Schritt werden Möglichkeiten in einem Prototyp validiert und erste lauffähige Anwendungen erstellt. Hier werden bereits möglichst viele Aspekte berücksichtigt, um ein „Minimum Valuable Product“ herzustellen, dass die Grundanforderungen an die Idee erfüllt. Das bedeutet, von der Datenhaltung bis zur Oberfläche auf dem mobilen Endgerät werden die Schritte auf ein Mindestmaß reduziert und ggf. später in der weiteren Produktentwicklung angepasst.

 

Das erste Vermarktungsreife Produkt wird in der nächsten Phase erstellt. Hier wird direkt gegen das Kundenfeedback validiert. Auch hier ist wichtig: alle horizontalen Schichten sind hier auf das Mindeste reduziert und auch hier wird im weiteren Verlauf der folgenden Iterationen Funktionalität und Architektur angepasst.

 

Die weiteren Iterationen verhalten sich nicht anders. Es wird stets geprüft und reduziert, welche Funktionalitäten sinnvoll und zum aktuellen Stand wichtig sind. Jedes Mal erneut werden dann notwendige Anpassungen vollzogen.

 

So ist sichergestellt, dass jede Iteration ein für den Kunden brauchbares Gesamtpaket bereithält, das er im vereinbarten Umfang nutzen kann. Iteration für Iteration werden auch die horizontalen Schichten angepasst und an aktuelle Bedürfnisse ausgerichtet – z.B. den Umzug in eine Cloud-Umgebung, falls die Datenverarbeitung mehr Zeit als notwendig beansprucht.

 

Der IoT Zeppelin gibt Ihnen eine Richtschnur, wie ein vertikaler Durchstich in jeder Umsetzungsphase möglich ist – und vor allem, wie sich Product Owner, Architekten, Softwareentwickler und andere Beteiligte auf einen gemeinsamen Nutzen verständigen können.

 

 


Fokus von selbst organisierten Teams

In der agilen Welt haben wir es mit „dezentralen Systemen“ zu tun, also mit Teams welche autonom diversen Aufgaben gegenüberstehen. Wie wichtig es ist, dass sich diese Teams auf einen Bereich fokussieren sollten, beschreibt eine Studie der George Washington University im Februar 2019:

 

Demnach funktionieren dezentrale Systeme am besten, wenn jedes einzelne Teil im System weniger intelligent ist. Nun kann man Teams nicht einfach die Intelligenz verweigern, man kann jedoch dafür sorgen, dass weniger Intelligenz benötigt wird, um Aufgaben zu erledigen. Man kann den Fokus auf eine konkrete Problemstellung lenken, ohne dass man über andere Teile des Systems nachdenken muss.

 

Mittel zum Zweck sind der Produktschnitt (auch Domain Modell genannt) in welchem sich die Teams bewegen und die daraus folgenden Anforderungen, die klein genug sind, um einen Mehrwert zu bieten.

 

Missachtet man dies, so führt die Studie weiter aus, ist das gesamte System – also alle Teams, die im System arbeiten – besonders fehleranfällig und es wiederholen sich auch Fehler aus der Vergangenheit.

 

Genau diese negativen Auswirkungen versuchen wir mit agilen Modellen zu vermeiden. Die Studie zeigt, dass es also umso wichtiger ist die Rahmenbedingungen und Verständnis dafür zu schaffen, so dass agile Teams die optimalen Ergebnisse erbringen können.

mehr lesen

Definition of Ready (DoR)

Die traurige Wahrheit, es gibt sie wirklich – die „Definition of Ready“. Es ist eine Sammlung an kurzen Punkten, welche beschreiben, welchen Zustand eine User Story haben muss, bevor sie in einen kommenden Sprint geplant werden kann.

Soweit klingt das vollkommen in Ordnung. Eine klassische DoR sieht daher wie folgt aus:

  • Die Story muss im Format „Als <Benutzer> möchte ich <Funktion> damit <Mehrwert>“ beschrieben sein
  • Die Story muss von jedem Teammitglied verstanden werden
  • Akzeptanzkriterien sind erfasst
  • Testkriterien sind bekannt
  • Performancekriterien sind bekannt
  • Es ist bekannt wie das Ergebnis demonstriert werden kann
  • Story ist geschätzt

Nun neigen viele Projektteams dazu diese Definition zu erweitern. So findet sich dann häufig folgende DoR wieder:

  • Die Story muss im Format „Als <Benutzer> möchte ich <Funktion> damit <Mehrwert>“ beschrieben sein (falls es nicht anders geht)
  • Die Story muss verstanden werden
  • Akzeptanzkriterien sind klar definiert und umsetzbar
  • Testkriterien sind bekannt (geht leider nicht immer)
  • Performancekriterien sind bekannt (müssen wir noch klären)
  • Es ist bekannt wie das Ergebnis demonstriert werden kann
  • Story ist geschätzt (StoryPoints)
  • Ressourcen sind verfügbar und einsatzbereit
  • Story ist analysiert
  • Story ist klein genug für einen Sprint
  • etc.

Nun haben wir den Salat. Die Diskussionen, ob die DoR nun wirklich auf jede Story im Sprint angewendet werden kann – jeder kennt sie.

Doch warum kommt es nun dazu?

Häufig wird die Definition of Ready (und eigentlich so ziemlich jedes Artefakt im agilen Umfeld) als Vertrag behandelt. Bei der DoR einem Vertrag zwischen Entwicklungsteam und Product Owner. Hält man sich nicht an die DoR wird entweder der PO oder das Team an die Wand gestellt.

Die DoR (und jedes andere Artefakt im agilen Umfeld) sind jedoch Hilfsmittel. Nicht mehr und nicht weniger. Das bedeutet: der klare Verstand, die Experten und die Stakeholder arbeiten wohlwollend für das gleiche Ziel. Die DoR unterstützt dabei, einige Punkte zu hinterfragen und so zu einem Informationsfluss zu kommen. Mitnichten ist es ein Vertrag, im entferntesten Sinne könnte man es als Absichtserklärung benennen – aber es ist ein „Talk maker“ – über wichtige Dinge sprechen und Entscheidungen gemeinschaftlich treffen.

Die Story kann nicht im angegebenen Format beschrieben werden? Gut, dass wir darüber gesprochen haben. Akzeptanzkriterien benötigen wir nicht? Schön, dass wir uns über die Beschreibung einig sind. Performancekriterien benötigen wir für den Service nicht? Traumhaft, wir haben intensiv darüber nachgedacht!

Weiter vorwärts: sechs Fakten

Willkommen in der agilen Welt. Ihr macht Scrum, Kanban und Design Thinking? Sehr gut!

 

Das Lehrbuch geht nun zurück ins Regal und folgende sechs Fakten helfen wirklich dabei Agilität zu leben:

 

1. Flow

Jedes Team findet seinen Punkt, an dem es wirklich performant arbeiten kann und verfällt in einen Zustand wie es Aufgaben gleichmässig abarbeitet. Ist das nicht so, ist es nicht agil.

 

2. Skills

Personen mit dem passenden Skillset sind obligatorisch. Es ist auch vollkommen egal an welchem Standort sich diese befinden. Ist das nicht so, ist es nicht agil.

 

3. Ship

Rollout-Prozesse, Branches und vielleicht dedizierte Teams dafür? Ist das so, ist es nicht agil.

 

4. Values

Spricht das Team immer noch darüber was gestern für Probleme aufgetreten sind? Ist das so, ist es nicht agil.

 

5. Knowledge

Der Product Owner schreibt immer alleine UserStories? Ist das so, ist es nicht agil.

 

6. Sell

Das Produkt wird angepriesen und verkauft? Ist das so, ist es nicht agil.

 

 


Gedankensprung: The point of no Schätzung

Aufwand, StoryPoints, Velocity und weitere Themen bewegen die agile Welt der Schätzungen. Fakt ist, eine Schätzung ist und bleibt eine unbekannte. Das liegt in der Natur der Sache. Mit agilen Methoden versuchen wir möglichst wenig Zeit zu verschwenden, aus Erfahrung zu lernen und Entscheidungen auf mehrere Menschen zu verteilen.

 

Bei der agilen Schätzung kann man mehr Zeit verschwenden als man denkt. Wie viele Einzelheiten muss ich kennen um eine aussagekräftige Zahl zu finden. In Bezug auf dessen Nutzen jedoch – der besteht meistens „nur“ daraus eine zeitliche Roadmap zu erstellen – wird oft sehr viel Zeit verschwendet.

 

In beinahe jedem Projekt kommt die Annahme auf: wir benötigen eine Referenzstory welche als Grundlage für weitere Schätzungen dient.

 

Um das ganze zu vertiefen hier ein Beispiel. Wir legen eine Referenz in welcher der Bau einer Rakete beispielhaft der Zahl 13 entspricht.

 

Über viele Iterationen hinweg lernen wir, dass wir vielleicht zwei oder drei Raketen in einer Iteration herstellen können. Soweit so gut.

 

In der Entwicklung von komplexen Dingen kommt es nun aber äusserst selten vor, dass wir jedesmal die gleiche Rakete bauen. Was passiert also, wenn wir nun eine Rakete bauen möchten, die selbständig wieder landet – so wie es SpaceX schon seit einigen versuchen erfolgreich demonstriert hat?

 

Das Umsetzungsteam wird nun sehr wahrscheinlich von einer höheren Zahl ausgehen – beispielhaft einer 21. Durch das zurechtlegen der Referenzrakete kommt es nun unweigerlich zu einer massiven Zeitverschwendung – da nun mit hoher Wahrscheinlichkeit jemand sagen wird: eine Rakete ist aber eine 13 und deswegen schafft ihr zwei oder drei.

 

Nun beginnen technische Analysen und Details werden sorgsam ausgearbeitet. Doch für welchen Nutzen? Um irgendwann festzustellen, dass sich der Plan unter Umständen ändert. Ok, das währe ohne die Zeitverschwendung aber auch passiert.

 

Das eigentliche Ziel muss es daher sein, die Schätzung als das zu akzeptieren was sie ist. Eine unbekannte Richtschnur welche als Anhaltspunkt für Planungen herbeigezogen werden kann. Das letzte Wort zur Leistungsfähigkeit hat das Umsetzungsteam, welches auch ständig aus den vorherigen Erfahrungen lernt.

 

 

Wenn mir heute das Umsetzungsteam mitteilt, dass es in der nächsten Iteration eine Rakete bauen kann, dann ist das so. Wenn es mitteilt, dass es fünf oder mehr sind – auch wenn die Statistik sagt es müssen zwei sein – dann ist das nunmal so. Wenn sich das Team dabei verschätzt hat, dann ist das auch unweigerlich so. Und genau hier beginnen die Verbesserungsprozesse. Nun könnte ich noch weitererzählen wie versucht wird die Schätzungen zu verbessern – aber auch hier sei vorweggenommen, auch das ist Zeitverschwendung. Schliesslich verkaufen wir Ergebnisse und keine Schätzungen.


Das etwas andere Interview

Thorsten Huber beantwortet wichtige Fragen, jeden Tag – in jedem Projekt. Stets das Ziel vor Augen, einfache Antworten zu finden, stellen wir Thorsten heute auf die Probe.

 

Wir haben drei Personen gebeten, drei Fragen an Thorsten zu stellen.

 

Da ist Lara, fünf Jahre alt, sie interessiert sich für Tiere und wird zu Hause von Ihrer Mutter tagsüber betreut. Abends kommt ihr Papa von der Arbeit nach Hause und freut sich auf die kurze gemeinsame Zeit.

 

Aus einer Personalvermittlung haben wir Simone (29 Jahe alt) gebeten, drei Fragen zu stellen. Sie arbeitet als Recruiting Consultant und versucht geeignete IT Experten für namhafte Unternehmen zu finden und zu vermitteln. Sie hat zwei Kinder im Alter von 7 und 9 Jahren.

 

Als letztes baten wir Frank (46 Jahre alt) um drei Fragen. Er arbeitet bei einem Grosskonzern und ist derzeit für die Entwicklung einer Plattform für User-Interaction an einer Robotik-Steuerung verantwortlich. Er ist derzeit alleinstehend und sportlich sehr aktiv.

 

Thorsten hat alle drei besucht und stellt sich der Herausforderung:

 

Lara: Kommst Du auch immer so spät zum spielen?

Thorsten: Mir geht es ein bisschen wie Dir. Ich verbringe den ganzen Tag mit Dingen die mir Spass machen und freue mich, wenn auch andere – wie Dein Papa – Zeit mit mir verbringen und wir gemeinsam Dinge tun die allen Spass machen.

 

Lara: Kannst Du reiten?

Thorsten: Reiten kann ich leider nicht, ich habe es mal versucht – aber mir fehlt ein bisschen der Mut. Ich finde es aber sehr spannend, wie man ein Pferd dazu bringt Dinge zu tun, die es nicht von sich aus nicht tun würde. Je nachdem wer auf dem Pferd sitzt, kann man manchmal sehen wie es dem Pferd gefällt.

 

Lara: Hast Du viele Freunde?

Thorsten: Ich kenne sehr viele Leute und es ist ganz wichtig für mich, dass wir uns gut verstehen. Manchmal entsteht daraus echte Freundschaft – aber das ist nicht immer so.

 

Simone: Meine Kunden fragen immer mehr nach Mitarbeitern mit agiler Erfahrung. Wie kann ich das beim Bewerber verifizieren?

Thorsten: Agilität ist eine Grundeinstellung zur Arbeit und deren Wertschöpfung. Man kann Erfahrung in agilen Teams sammeln und sich darin entwickeln. Man kann Grundsätze und Methoden erlernen und anwenden. Im Kern muss man jedoch „Open Minded“ die täglichen Aufgaben bewältigen. Dies kann man durch Fragetechniken gut verifizieren.

 

Simone: Welche Weiterbildungsprogramme würdest Du empfehlen, damit Mitarbeiter für die Digitalisierung gut gerüstet sind?

Thorsten: Eine Herausforderung der Initiativen zur Digitalisierung ist das Unbekannte. Wenn wir heute wüssten wie sich die Revolution ausprägt, könnten wir losrennen und das Ziel treffen. Wir haben es jedoch mit vielen unbekannten Bedingungen zu tun, welche rechtzeitiges Handeln und stetigen Wandel erfordern. Heute würde ich daher Weiterbildungen in Programmiersprachen, generelle Softwareentwicklung- und Architektur empfehlen.

 

Simone: Häufig spreche ich nicht mehr mit den Entscheidern über neues Personal, sondern muss das Feedback aus dem Team abwarten. Hast Du hierfür Tips für mich?

Thorsten: Im agilen Umfeld übernimmt das Team, anders als früher, sehr viel Verantwortung für das Produkt. Statt Entscheidungen auf wenige Köpfe zu verteilen, entscheiden die Macher heute über Technologien und das Arbeitsumfeld. Es ist daher richtig und wichtig, dass genau diese Personengruppen entscheiden, welche Unterstützung sie benötigen und diese auch gemeinschaftlich verantworten. Als Tip kann ich mitgeben: Stelle immer die Frage welche Probleme es gilt es zu lösen. Klassisches Rollendenken, z.B. in Entwicklung und Tester, hat bereits ausgedient.

 

Frank: Ich habe über 40 Menschen die für das Projekt arbeiten, wie bekomme ich das mit agilen Methoden organisiert?

Thorsten: Das arbeiten mit vielen Menschen in einem Projekt erfordert einen hohen Kommunikationsbedarf und die Organisation von fachlichen Anforderungen. Mehrere kleine Teams sind meist effektiver. Um die Zusammenarbeit zu gewährleisten, können Modelle zur agilen Skalierung helfen.

 

Frank: Ich kenne meine Anforderungen ganz genau, warum empfiehlst Du dennoch den Einsatz von Scrum?

Thorsten: Scrum ist nicht nur eine Basis für sich ändernde Anforderungen. Es ist ein Framework welches von Werten für einzelne Teammitglieder lebt. Das Team ist das wichtigste Element, welches dem Projekt zur Verfügung steht – Scrum schafft einen Rahmen in welchem sich dieses verantwortungsvoll bewegen kann.

 

Frank: Ich habe schwierige Personen im Projekt, was würdest Du tun?

 

Thorsten: Dass jemand im Projekt mitwirkt, hat meistens einen Grund. Genau diese Stärken sollten durch das Team gefördert und vor allem genutzt werden. Schwächen muss man kennen, respektieren und im Alltag damit umgehen. Man kann respektvollen und motivierenden Umgang im Team fördern, so dass das Team in die Lage versetzt wird, Konflikte und Probleme dieser Art selbst zu lösen.