Buzzwords: Was ist Zero Trust?

Im Zuge der digitalen Transformation ist es wichtiger denn je, wie zuverlässig Unternehmen und Dienste vor Cyberangriffen und Datenklau geschützt sind. Klassische, perimeterbasierte Sicherheitskonzepte zum Schutz von Unternehmensnetzwerken stoßen zunehmend an ihre Grenzen, weil sie davon ausgehen, dass interne Zugriffe keine Gefahr darstellen. Doch wem kann man noch vertrauen? Das Zero Trust-Konzept beantwortet diese Kernfrage schon im Wortlaut: niemandem.

„Vertraue niemandem, verifiziere jeden“

Bei Zero Trust handelt es sich um ein IT-Sicherheitsmodell, das grundsätzlich keinem Gerät und keinem Nutzer traut – weder innerhalb noch außerhalb des Netzwerks. Nach der Maxime „Never trust, always verify“ (zu Deutsch: „Vertraue niemandem, verifiziere jeden“) fordert es für jeden Zugriff und jeden Datenfluss eine Authentifizierung. Das heißt: Jede einzelne Anfrage muss neu verifiziert werden, bevor man Zugang zum System erhält.

Zum Vergleich: Bei traditionellen Sicherheitsarchitekturen genügt eine einmalige Verifizierung, um als vertrauenswürdig eingestuft zu werden. Das mag zwar eine komfortable Lösung sein, setzt aber voraus, dass Angreifer immer nur von außen und niemals von innen auftreten können – eine naive Annahme, die im heutigen digitalen Ökosystem keinen Bestand mehr hat. Zero Trust schiebt dem Ganzen einen Riegel vor und rückt den Schutz der Daten in den Mittelpunkt.

Die wichtigsten Grundsätze von Zero Trust

Wie jedes Konzept beruht auch Zero Trust auf einer Kombination verschiedener Prinzipien und Technologien zur umfassenden Abwehr von Cyberangriffen in digitalen Geschäftsumgebungen. Die wichtigsten davon sind:

Least Privilege: Das Least Privilege-Prinzip verlangt so wenige Zugriffsberechtigungen wie möglich. Menschliche als auch nicht menschliche Benutzer erhalten demnach nur so viele Privilegien und Informationen wie unbedingt nötig (Just-in-Time / Just-Enough-Access).
Datenzentrierung: Die Basis einer lückenlosen Sicherheit und Compliance bildet bei Zero Trust der Schutz der Daten und nicht des Perimeters. Daher liegt der Fokus des Ansatzes vorrangig auf der Sicherung, Verschlüsselung und Verwaltung der Daten sowie der Entwicklung von Datenklassifikationsschemata.
Zugriffskontrollen: Durch laufende Identitäts- und Datenprüfungen wird protokolliert, wer wann auf welche Ressourcen Zugriff hat, um interne und externe Bedrohungen rechtzeitig zu erkennen. Privilegierte Accounts gelten als besonders beliebtes Angriffsziel und müssen deshalb verstärkt geschützt und überwacht werden. Je mehr Datenpunkte (Identität, Standort, Datenklassifizierung, Workload etc.) in die Autorisierung einfließen, desto besser.
Mikrosegmentierung: Bei dieser Methode werden Sicherheitsperimeter in kleinere, voneinander getrennte Zonen aufgeteilt, die jeweils eigene Zugriffsautorisierungen erfordern. So soll sichergestellt werden, dass ein Benutzer oder ein Programm mit Zugriff auf eine der Zonen nicht automatisch auch auf alle anderen zugreifen kann. Sollte in einem der Segmente ein Angreifer entdeckt werden, lässt sich das kompromittierte Gerät sehr viel leichter unter Quarantäne stellen und vom Rest des Netzwerks trennen.
Multifaktor-Authentifizierung (MFA): Für den Zugriff auf geschäftskritische Ressourcen ist ein Passwort allein nicht ausreichend. Viele Online-Dienste und Plattformen nutzen daher eine MFA wie beispielsweise die 2-Faktor-Autorisierung (2FA), bei der Benutzer mehr als einen Identitätsnachweis angeben müssen. Nach der Eingabe des Passworts wird dazu ein Code an ein anderes Gerät versendet, der für die Zugriffsfreigabe erforderlich ist.

Fazit: Zero Trust als Paradigmenwechsel in der IT-Security

Das Zero Trust-Modell ersetzt zum Großteil den traditionellen IT-Sicherheitsansatz, nach dem sämtliche Zugriffe innerhalb des Netzwerkperimeters legitim sind und nicht als Bedrohung für das Unternehmen gesehen werden. Gemäß seiner Maxime „Vertraue niemandem“ muss bei Zero Trust jeder Zugriff verifiziert und überwacht werden. Die Implementierung dieses Konzepts kann auf ganz unterschiedlichen Wegen erfolgen, da es nicht „die eine“ Zero Trust-Strategie gibt. Wirksame Technologien sind zum Beispiel Mikrosegmentierung, Multifaktor-Authentifizierung (MFA) oder Identity and Access Management (IAM), um einen kontrollierten Zugriff von Benutzern und Identitäten zu gewährleisten. Klar ist, dass Zero Trust weiter an Bedeutung gewinnen wird, da die zunehmende Komplexität unserer IT-Landschaft ein grundlegendes Sicherheitsumdenken erfordert. Nicht das Netzwerk als solches, sondern seine Daten und Ressourcen müssen ins Zentrum gerückt und geschützt werden.

Was ist Scrum of Scrums?

1 Antwort

Projekte werden zunehmend komplexer und immer mehr Personen sind in ein Projekt eingebunden. Das agile Framework Scrum definiert jedoch eine eindeutige Teamgröße, die nicht überschritten werden soll. Stößt Scrum bei Großprojekten also an seine Grenze? Ganz bestimmt nicht. Die Lösung liegt im Scrum of Scrums.

Worum handelt es sich?

Laut Scrum liegt die optimale Teamgröße bei nicht mehr als 9 Personen. Untersuchungen haben gezeigt, dass 4,6 Personen perfekt wären. Abgesehen davon, dass dieser Wert in der Praxis schwierig umzusetzen wäre, zeigt die Erfahrung, dass Teams eher größer statt kleiner sind.

Große Organisationen und Projekte können dann das Scrum of Scrums, auch SoS genannt, nutzen. Dieses Format dient der Vernetzung und der Kommunikation mehrerer Scrum Teams, die gemeinsam an einem großen Ziel oder Projekt arbeiten.

Kurz gesagt: SoS ist eine agile Methode zur Zusammenarbeit mehrerer Scrum Teams. Ziel ist die Vernetzung zwischen den Teams, die Kommunikation und Förderung der Zusammenarbeit. Abhängigkeiten können hier schnell sichtbar gemacht werden um Lösungen gemeinsam zu entwickeln.

Wie funktioniert es?

Das SoS ist vergleichbar mit dem Daily Scrum eines Scrum Teams, mit dem Unterschied, dass dieses nicht standardisiert ist. Die Frequenz, Dauer und die Teilnehmer des Meetings können die Teams selber bestimmen. Jedes Scrum Team entsendet einen Botschafter in dieses Meeting, welcher aber auch wechseln kann.

Im Daily Scrum beantworten die Teammitglieder die drei klassischen Fragen, die sich auf das Sprintziel beziehen:

Was habe ich seit gestern getan?
Was erledige ich bis morgen?
Was behindert meine Arbeit?

Im Scrum of Scrums sind die Fragen auf das Team bezogen, die Fragen werden also leicht umformuliert und ergänzt:

Was hat mein Team seit dem letzten Meeting geschafft?
Was wird mein Team bis zum nächsten Meeting erledigen?
Welche Hindernisse behindern mein Team?
Hat eine Tätigkeit meines Teams Auswirkung auf eines der anderen?

Ist SoS nun die Lösung für alle Großprojekte? Nicht ganz, denn auch diese Methode ist auf eine Größe beschränkt. Es sollten nicht mehr als 9 Scrum Teams zum Scrum of Scrum zusammenkommen. Was ist aber, wenn es mehr Teams gibt? Bei großen Unternehmen arbeiten auch schon mal mehr als 20 Scrum Teams an einem Projekt.

Scrum bietet auch hierfür eine Lösung – bitte festhalten: Das Scrum of Scrum of Scrums. So einfach wie es sich anhört, ist es doch kein Wunder, dass sich dieser Begriff nicht durchgesetzt hat. Es ist dennoch eine sinnvolle Methode, die Teams auf einer höheren Ebene miteinander zu vernetzen.

Herausforderungen und Vorteile von Scrum of Scrums

SoS erfordert neue Rollen wie einen Chief Product Owner und einen Scrum of Scrums Master. Natürlich sollte nicht verschwiegen werden, dass die Scrum Teams zunächst mit neuen Herausforderungen rechnen müssen:

Der Scrum Master muss stärker auf die Abhängigkeiten zu den anderen Teams achten, da sich diese auch auf das Sprint Planning auswirken. Die Kommunikation in solch großen Strukturen ist aufwendig aber umso wichtiger. Die Arbeitslast kann beim Scrum Master und auch beim Product Owner steigen.

Dem Aufwand stehen aber große Vorteile gegenüber:

Die Teams vernetzen sich stärker miteinander und können Abhängigkeiten reduzieren. Gleichzeitig ist der Projektfortschritt für alle Beteiligten sichtbar und die eigene Rolle transparent. Damit reduzieren sich Risiken, denn die Teams achten stärker darauf, mit ihrer Arbeit nicht die anderen Teams zu behindern oder sich einfach kopflos in die Entwicklung zu stürzen. Die Vorgänge sind gut aufeinander abgestimmt und sollten Probleme auftreten, werden sie gemeinsam gelöst.

Tipps für das Scrum of Scrums

Damit die Implementierung gelingt und nicht für Frust sorgt, hier ein paar Tipps und Fragen, die Sie vorher klären sollten:

Welche Frequenz und Dauer ist die Richtige und wer nimmt teil?
Halten Sie sich an die 4 Fragen – anders als beim Daily Scrum sollte dieser Rahmen auch genutzt werden um Probleme zu besprechen um Lösungen zu finden
Eine Retrospective of Retrospectives kann helfen gemeinsame Prozesse und Arbeitsweisen zu verbessern

Was bedeutet WebAssembly für IT-Projekte?

Schreibe eine Antwort

Eine der jüngsten Entwicklungen in der Weblandschaft ist WebAssembly – ein Binärformat, das unter Web- und App-Entwicklern längst in aller Munde ist. Völlig zu Recht, denn es zeichnet sich ab, dass WebAssembly über kurz oder lang neue Maßstäbe in der Softwareentwicklung setzen wird. Doch was bedeutet das für zukünftige IT-Projekte?

Basics first: Was kann WebAssembly?

WebAssembly (Wasm) ist eine Low Level Assemblersprache, die nativ in Webbrowsern kompiliert werden kann. Im Vergleich zu JavaScript liegt das Format sehr viel näher am Maschinencode und unterscheidet sich in seiner Leistung kaum von nativen Apps. Es läuft in allen großen Browsern – Chrome, Firefox, Safari und Edge – und ist vom W3C als offizieller Web Standard anerkannt. Das Besondere an WebAssembly ist, dass man in der Regel nicht direkt damit programmiert, sondern dass es als Kompilierziel für andere Sprachen fungiert. Da es bereits im Binärformat vorliegt, erfolgt das Parsing deutlich schneller als bei JavaScript.

Konkret heißt das: WebAssembly bietet die Möglichkeit, gängige Hochsprachen (z.B. C, C++, Java, Python) in ein ladezeitoptimiertes Format zu kompilieren, das crossbrowser und crossplatform Einsätze möglich macht. Jede Desktop Anwendung, die sich in WebAssembly kompilieren lässt, können Sie auf diese Weise ohne Leistungseinbußen im Browser ausführen. Damit dient WebAssembly als ideale Ergänzung zu JavaScript, um dessen Overheads auszubügeln und auch komplexe, rechenintensive Anwendungen im Browser auszuführen.

Was bedeutet das für IT-Projekte?

Seit WebAssembly ist JavaScript nicht mehr einzige Option, um Code für den Browser zu schreiben. Und das hat Folgen: Denn statt sich auf die bisherigen Objektprototypen von JavaScript zu beschränken, haben Entwickler zum ersten Mal eine Auswahl. Im Grunde können Sie jede Funktion Ihrer Anwendung in einer beliebigen Sprache programmieren und diese im Anschluss zu Wasm kompilieren. Voraussetzung ist natürlich, dass die gewählte Sprache über einen WebAssembly-Compiler verfügt.

Ein weiterer Vorteil von WebAssembly: Sie können den Wasm Code wiederverwenden und damit eine Brücke zwischen C#-Backend (als Beispiel) und JS-Frontend bilden. Wenn Sie Ihre DLL mit WebAssembly als Ziel kompilieren, sparen Sie sich den Schritt sie in JavaScript zu implementieren – und das spart Entwicklungszeit.

IT-Projekte stehen damit vor ganz neuen Chancen, aber auch Herausforderungen. In Bereichen, in denen die Rechenleistung von JavaScript an ihre Grenzen stößt, kann zukünftig mit Wasm gearbeitet werden – zum Beispiel bei 3D Gaming, Image Editing oder Virtual Reality. Desktop und Mobile Apps, für die bisher keine webbasierte Variante geplant war, können mit Wasm problemlos im Browser kompiliert werden. Und ja, das betrifft auch Java Anwendungen und alle anderen „web-fernen“ Sprachen.

Wird zukünftig nur noch mit WebAssembly programmiert?

WebAssembly wurde mit dem primären Ziel entwickelt, leistungsstärkere Webanwendungen zu ermöglichen. Der Trend hin zu browserbasierten Applikationen wird dadurch natürlich verstärkt, denn der Vorteil ist: Web Apps haben ein breiteres Publikum. Gleichzeitig macht WebAssembly die Programmierung solcher Apps effizienter, schneller und günstiger. Da inzwischen alle großen Browser das Format unterstützen, ist es eigentlich nur eine Frage der Zeit, bis es sich komplett in der Webentwicklung etabliert hat – vor allem in jenen Bereichen, wo Performance eine große, wenn nicht sogar entscheidende Rolle spielt. Wiederum wird es JavaScript nicht ersetzen, allein schon deshalb, weil die Wasm Module mit JavaScript geladen werden. Es ist und bleibt daher eine Ergänzung, die die bisherigen bestehenden Grenzen in der Softwareentwicklung ein großes Stück aufbricht.

Zusammenfassung

WebAssembly mag in erster Linie für Performancesteigerungen konzipiert worden sein, doch das Format kann weitaus mehr. Entwicklungsteams, die plattformübergreifend oder mit einer Client-Server-Aufteilung arbeiten, profitieren zum Beispiel von kürzeren Lieferzeiten und mehr Flexibilität beim Programmieren selbst. So ist man nicht mehr an die lose Typisierung von JavaScript gebunden, sondern kann jede Hochsprache, die in Wasm kompiliert werden kann, für die gewünschten Funktionen nutzen – von Rust und C bis hin zu Java. Das Web von morgen wird Apps der Desktop-Klasse mit nativer Leistung ausführen, und WebAssembly macht es möglich.

Aus den Fehlern der Anderen lernen: Wege zum Erfolg im IT-Projektmanagement

Schreibe eine Antwort

3 Tipps, um auch große IT-Projekte erfolgreich zu steuern

Schon mal von einem großen IT-Projekt gehört, das in der geplanten Zeit und im Rahmen des vorgesehenen Budgets erfolgreich abgeschlossen wurde? Nein? Kein Wunder. In der IT-Welt haben Großprojekte, die ihr Ziel innerhalb der vorgesehenen Zeit und ohne Überschreitung des Budgets erreichen, Seltenheitswert. Wir zeigen drei typische Fehler, die in großen Softwareprojekten vorkommen und Wege, sie zu vermeiden.

Eine gemeinsame Studie von McKinsey und der Oxford-Universität hat gezeigt: Alle großen IT-Projekte (Startbudget über 15 Millionen USD) erfordern fast 50% mehr Budget als geplant und 7% davon überziehen die vorgesehene Projektzeit, während sie etwa die Hälfte der Ziele verfehlen. Die schwarzen Schafe sind die Softwareprojekte. Nichteinhaltung von Kosten- und Zeitrahmen sind hier fast schon vorprogrammiert.

Problem 1: Mangelndes Interesse des Managements

Zeigt das Management kaum Interesse, ist es kein Wunder, wenn das Projekt nicht fortschreitet. Wenn das Management nichts tut, mit der Behauptung, sich mit der IT nicht auszukennen, die ganzen „IT-Sachen” dem technischen Team überlässt, wird das Techniker-Team selbst die Führung übernehmen und alle Entscheidungen treffen. Dadurch können neue Probleme entstehen. Meistens fehlt dem technischen Team nicht das fachliche Know-How, sondern der klare Blick auf die geschäftlichen Ziele. So kann es dazu kommen, dass die Techniker Entscheidungen treffen, welche unbeabsichtigter Weise mit Geschäftsinteressen kollidieren.

Die Lösung: Durch Präsenz und Commitment sind Sie immer auf dem Laufenden und vermeiden so, dass „die Techniker“ die Projektführung übernehmen und prozessbezogene Belange oder Geschäftsinteressen übersehen. Management-Präsenz und regelmäßige Kommunikation mit dem technischen Team sind die Voraussetzung dafür, dass Prozesse und Geschäftsziele mit der technischen Umsetzung harmonieren. Das gesamte IT-Projekt profitiert von einer Kultur, die auf regelmäßigem Austausch zwischen Management und dem technischen Team beruht. Ein gutes technisches Team wird jederzeit in der Lage sein, klar darzustellen, was es tut. Anderenfalls gehen Sie davon aus, dass das Team gar nicht richtig weiß, was es tut.

Problem 2: Zu starker Fokus auf Kostenreduzierung

Gerade in Krisenzeiten sucht jeder Wege, um kostenreduzierend und effizient zu handeln. Einsparungen sind gut, doch kann der Schuss auch nach hinten losgehen: beispielsweise dann, wenn dafür Projektmitarbeiter eingespart werden oder weniger gut ausgebildetes Projektpersonal eingekauft wird. Projekte mit weniger spezialisierten Ressourcen sind bekannt dafür, den Zeitplan und das Budget nicht einzuhalten sowie für Qualitätsprobleme oder Abstriche bei der Umsetzung der Anforderungen.

Die Lösung: Berechnen Sie das Budget so, dass Sie die Kosten für gut ausgebildete, erfahrene Projektmitarbeiter einplanen. Dann finden Sie die richtigen Leute für die anstehenden Aufgaben viel leichter. „Quick and dirty“ rechnet sich selten. Sollten Sie an Outsourcing ins billigere Ausland denken, berücksichtigen Sie eventuelle Probleme durch Sprachhürden, unterschiedliche Kommunikations- und Arbeitskulturen, Erreichbarkeit, z.B. bedingt durch Zeitverschiebungen. Bedenken Sie auch, dass ein. erfolgreiches Projekt nicht nur Entwickler braucht. Die vernünftige Projektsteuerung und Zielverfolgung ist Aufgabe des Projekt-Managements. Erfolgsentscheidend sind auch die Ergebnisse der Business Analysten und der Tester. Bevor Sie den Rotstift ansetzen, überlege Sie, wie viele, für die anstehenden Aufgaben nicht ausreichend qualifizierte Mitarbeiter, das Projekt, bzw. das Unternehmen sich leisten kann.

Problem 3: Fehlende Zielklarheit

Technikfreaks neigen in ihrer Begeisterung dazu, Dinge sofort anzupacken. Was auch immer dieses Verhalten herbeiführt, es führt immer zu mangelhafter oder gar fehlendende Planung. Ohne den Umfang, die Zeile, und das erwartete Projektergebnis genau zu verstehen, kann der Versuch, auf dieser Basis ein Projekt zu lenken, nur scheitern. Ein erfolgreiches Projekt bedeutet mehr als die Lieferung des endgültigen Softwareprodukts. Es geht auch um das Erreichen des erwünschten Projektergebnisses innerhalb des geplanten Zeitraums und Budgets. Fehlt eine koordinierte Planung, tritt Folgendes auf:

Unklarheit über Umfang und Ziel
Verwirrung bezüglich Rollen und Verantwortlichkeiten
Ineffiziente Ressourcennutzung
Nichtverfügbarkeit von Ressourcen zu kritischen Zeiten
Ungleichmäßige Arbeitsbelastung des Teams
Falsche Zeit- und Kosteneinschätzungen (durch unerwartete Ereignisse)
Schwache Leistung u.a. durch Überarbeitung, Frust, verspätete Lieferung, fehlerhafte Ergebnisse etc.

Die Lösung: Es scheint banal: diese Nebenwirkungen fehlender Zielklarheit in einem Großprojekt sind mittels expliziter, klarer Festlegung und durch regelmäßige Zielkommunikation vermeidbar. Durch die engmaschige Verfolgung der Ziele und des Ist- Zustandes in jeder Phase, erkennen Sie frühzeitig Zielabweichungen und Unklarheiten Zielerreichung gesamt und im Detail zu betrachten verstärkt die Klarheit. Auch wenn ausschließlich Spezialisten am Werk sind, kann es bei Unklarheiten über das Ziel des Projekts zu Chaos und Frustration verursachenden Effekten kommen. Stellen Sie sich ein Orchester vor, in dem lauter Virtuosen der jeweiligen Instrumente spielen, aber der Dirigent fehlt. Das will keiner hören!

Fazit

In IT-Projekten ist engmaschige Kommunikation essentiell, um auf der Zielgeraden zu bleiben, wie überall, wo Menschen mit Menschen zusammenkommen und ein Gemeinschaftswerk zum Erfolg bringen wollen. Ohne ein gutes, engagiertes Management mit Leitbildcharakter sowie Absprachen und Zielklarheit in jeder Phase sind Chaos, Frust und Fehler vorprogrammiert. Ebenso, wenn Sie am falschen Ende sparen.

Das bringt 2022: Vier Trends im Projektmanagement

Schreibe eine Antwort

Die Corona-Pandemie hat Entwicklungen im Projektmanagement beschleunigt. Der weltweite Einfluss wirkt weiterhin wie ein Katalysator und spült neue Möglichkeiten und Fokusthemen ans Tageslicht. Wir blicken auf die Trends und Einflüsse, die das beginnende Jahr 2022 im Projektmanagement mit sich bringt.

Viele Trends sind nachhaltig

Business Agile, New Work, Scrum oder übergreifendes, digitalisiertes Projektmanagement: Viele Trends und Entwicklungen vergangener Jahre halten bis heute an, sind aktueller denn je oder längst zum Standard geworden.

Das Jahr 2022 hat das Potenzial, ebenfalls Maßstäbe im Projektmanagement zu setzen. Vermehrtes mobiles Zusammenarbeiten, eine zunehmende Relevanz der Soft Skills und hybrides Projektmanagement sind Schlagwörter, die Ihnen im Zusammenhang mit dem gerade begonnenen Jahr immer wieder begegnen werden.

Vieles davon wird bleiben, eines mit an Sicherheit grenzender Wahrscheinlichkeit: Die immer dominantere und wichtigere Rolle künstlicher Intelligenz und Automation.

Künstliche Intelligenz erleichtert die Zusammenarbeit

Eines ist klar: Digitalisierung, Automatisierung, künstliche Intelligenz – alle Begriffe und Entwicklungen sind nicht gänzlich neu und schon seit einigen Jahren im gedanklichen Zentrum aller langfristig denkenden Unternehmer und Unternehmerinnen.

Mit dem neuen Jahr entwächst dieser anhaltende Trend allerdings den Kinderschuhen und wird im Projektmanagement massentauglich. Wir sind uns sicher, dass auch Sie bereits Erfahrungen mit automatisierten Prozessen gemacht haben.

Wenn nicht, wird es allerhöchste Zeit. Mithilfe künstlicher Intelligenz lassen sich nicht nur große Datenmengen strukturiert erfassen und auswerten. Der direkte Einfluss auf das tägliche Tun ist ebenfalls stark und wird oft vernachlässigt. Projektteams gewinnen wertvolle Ressourcen durch Automatisierung und arbeiten effizienter dank smarter Datenanalysen.

Letztlich ermöglicht Ihnen die rasante Entwicklung in diesem Bereich zwei gleichermaßen wichtige Dinge: Die Optimierung interner Prozesse und Ressourcen – und vor allem kundenseitig eine Erhöhung der Produkt- oder Dienstleistungsqualität.

Mehr mobil, mehr remote, mehr zusammen

Ein Trend, der durch den fortschreitenden Einsatz künstlicher Intelligenz und der Technologisierung der Arbeitsumgebungen überhaupt erst ermöglicht wurde, ist die klassische Fernarbeit.

Während vor der Pandemie viele Projektteams stationär zusammengearbeitet haben, hat sich die Sichtweise auf die Art der Kollaboration verändert. Remote-Teams nutzen verstärkt die Möglichkeiten der ortsunabhängigen Zusammenarbeit und genießen dadurch zeitliche und projektbezogene Flexibilität.

Wussten Sie, dass die Anzahl der Menschen im Mobile Office von fünf Prozent vor, auf zeitweise knapp 30 Prozent während der Pandemie vervielfacht hat? Die Entwicklung ist nachhaltig, auch im Projektmanagement.

Dabei werden Sie selten vor eine Entweder-oder-Frage gestellt. Der Trend hybrider Teams, die gemeinsam vor Ort und digital zusammenarbeiten, wird sich 2022 festigen.

Soft-Skills werden immer wichtiger

Denken Sie kurz zurück an die erste Entwicklung, die wir vorgestellt haben: Künstliche Intelligenz und Automation. Dieser nachhaltige Trend bildet die Grundlage für eine Verschiebung der Kompetenzen von Führungskräften und Mitarbeitenden im Projektmanagement.

Die digitale Transformation schmälert viele der komplexen Anforderungen, für die Projektverantwortliche einst ausschließlich rekrutiert wurden. Mithilfe technischer Unterstützung bei komplexen Aufgaben werden weitere Fähigkeiten wichtiger, die unter dem Dachbegriff „Soft Skills“ zusammengefasst werden.

Sind Sie, sind Ihre Führungskräfte in der Lage, Konflikte innerhalb eines Teams zu schlichten? Wie steht es um die Kommunikationsfähigkeiten innerhalb der Organisation, aber auch darüber hinaus in Bezug auf relevante Stakeholder?

Emotionale Intelligenz wird 2022 im Recruiting geeigneter Arbeitskräfte eine zentrale Rolle einnehmen. Der Fokus verschiebt sich von einer rein fachlichen, hin zu einer mit relevanten Soft Skills angereicherten Jobanforderung im Projektmanagement.

Die Mischung macht‘s: Hybrides Projektmanagement im Kommen

Das Wort „Hybrid“ hat in den letzten Jahren Einzug in den Sprachgebrauch gehalten. Vor einiger Zeit noch rein mit Autos in Verbindung gebracht, findet der Begriff in der Arbeitswelt immer mehr Relevanz. Hybride Veranstaltungen, hybride Zusammenarbeit – und künftig auch hybrides Projektmanagement.

Der Trend geht hin zu einer Nutzung zweier oder mehrerer Methoden im Projektmanagement, um noch flexibler, noch agiler arbeiten und reagieren zu können. Künftig werden Sie also nicht mehr nur von klassischen oder agilem, sondern auch von hybridem Projektmanagement hören.

Wenn aus Trends neue Standards werden

Jeder Standard entspringt aus einem anfänglichen Trend. Ein gutes Beispiel aus dem Alltag ist Nachhaltigkeit. Oder würden Sie zustimmen, wenn wir Nachhaltigkeit als vorübergehenden Trend bezeichnen? Wohl kaum. Vielmehr ist solches Denken und Handeln zum Standard geworden.

Die vier vorgestellten Trends haben alle das Potenzial, ebenfalls zu einem Standard im Projektmanagement zu werden und nicht nur als leere Worthülsen im Gedächtnis zu bleiben. Das neue Jahr 2022 bringt spannende Entwicklungen mit sich. Wir sind bereit – Sie hoffentlich auch.

Dokumentation im Code – ja oder nein?

Schreibe eine Antwort

Programmcode wird zwar immer für Maschinen geschrieben, aber wirklich gut ist er erst, wenn ihn auch Menschen ohne Schwierigkeiten lesen können. Doch was heißt „ohne Schwierigkeiten“? Viele Entwickler setzen dazu auf eine mehr oder weniger detaillierte Dokumentation des Codes. Der Gedanke ist klar: Kommentare sollen helfen, den Code besser nachzuvollziehen und Nachfragen oder gar Missverständnisse zu vermeiden. Aber sollte ein guter Code nicht eigentlich selbsterklärend sein? Wir gehen der Frage nach.

Warum Code überhaupt dokumentiert wird

Kommentare zwischen den Codezeilen sind nicht per se schlecht. Sie haben ihre Daseinsberechtigung. Ein Beispiel: Sie möchten komplexe Funktionsabschnitte deklarieren. Oder Sie möchten erwähnen, warum Sie an einer bestimmten Stelle genau diese Parameter verwenden und keine anderen. Problematisch wird es dann, wenn Sie

mehr Augenmerk auf die Dokumentation legen als auf den Code selber, und
die Funktionalität des Codes statt seiner Intention kommentieren.

Hinter einer übereifrigen Dokumentation steckt oft die Angst, dass andere den Code falsch oder gar nicht verstehen könnten. Denken Sie umgekehrt: Wie lässt sich Code schreiben, damit er keiner weiteren Kommunikation bedarf? Denn dann kommen Sie schnell an den Punkt, an dem Ihnen klar wird, dass 99% aller Kommentare überflüssig sind.

Ein guter Code spricht für sich

Je weniger Sie kommentieren, desto stärker müssen Sie auf klare und strukturierte Anweisungen achten. Clean Code zwingt Sie gewissermaßen ganz von selbst dazu, möglichst simpel und effizient zu coden, weshalb dieses Prinzip in der Softwareentwicklung auch so hochgelobt ist. Versuchen Sie mit Ihren Codezeilen zu kommunizieren, statt sich in ausufernden Dokumentationen zu verlieren. Hier sind vier Gründe, warum Sie zukünftig weniger kommentieren sollten:

1. Kommentare lenken ab

Ein perfekter Code hat immer einen gewissen Fluss, wenn Sie ihn durchgehen, so als würden Sie einen flüssigen Text lesen. Kommentare unterbrechen diesen Fluss ausnahmslos und erschweren so in vielen Fällen – paradoxerweise – das Verständnis des Codes. Das ist vor allem dann der Fall, wenn es sich um redundante Kommentare handelt, die keine neuen Informationen liefern.

2. Kommentare kosten Zeit

Zeit ist die kostbarste Ressource in der Softwareentwicklung. Überschlagen Sie einmal in Gedanken, wie viel Zeit Ihnen das Verfassen der Kommentare kostet und wie viel Zeit andere damit verbringen, diese zu lesen und mit dem Code in Einklang zu bringen. Und wer pflegt und aktualisiert die Kommentare, wenn der Code zu einem späteren Zeitpunkt angepasst werden muss? Der Punkt ist: Dokumentieren geht immer zu Lasten der Produktivität. Wenn Sie dauerhaft schneller und effizienter arbeiten wollen, müssen Sie rigoros Kommentare einsparen.

3. Schlechte Kommentare verwirren Ihre Kollegen

Vielleicht kennen Sie das Szenario selbst: Jemand kommentiert etwas völlig Offensichtliches und Sie fragen sich insgeheim: Warum wird das kommentiert? Steckt noch mehr dahinter? Lässt sich das auch anders interpretieren? Redundante oder irreführende Kommentare können eine ganze Menge Probleme verursachen, die völlig unnötig sind. Vertrauen Sie Ihren Programmierfertigkeiten und denen Ihrer Kollegen. So oder so werden Kommentare Ihren Code nicht besser machen.

4. Kommentare überlagern die Neutralität des Codes

Programmiersprachen sind neutral, eigene Kommentare nicht. Denken Sie immer daran, dass Ihre Kommentare Teil des Quellcodes sind und von jedem, der damit arbeitet, eingesehen werden können. Besonders relevant ist dieser Punkt für jeden, der dazu neigt, Kommentare auch als eine Art Notizen zu verwenden. Gestern Nacht noch kurz etwas vermerkt, am nächsten Morgen längst vergessen – und Ihr Kollege amüsiert sich prächtig. Darum sollten Sie sich angewöhnen, so wenige Kommentare wie nur möglich zu hinterlassen.

Fazit: Gute Programmierer kommunizieren mit ihrem Code

Schreiben Sie Programmiercode so, dass man ihn auch ohne oder nur mit wenigen Kommentaren verstehen kann. Damit sparen Sie selbst und anderen eine Menge Zeit, arbeiten produktiver und fokussieren sich auf klare, einfache Strukturen. Erfahrungsgemäß lässt dies auch das Vertrauen in die eigenen Fähigkeiten wachsen, weil Sie lernen, ausschließlich mit Ihrem Code zu kommunizieren.

Retro…was? Retrospektive und wie ein Team daran wächst

Schreibe eine Antwort

Schon Mal was von einer Retrospektive gehört? Im Scrum ist es jedenfalls ein gängiger Begriff. Die Retrospektive oder kurz „Retro“ hat dabei nichts mit einer Design- oder Musikrichtung zu tun, sondern ist ein wichtiger Termin. Es lohnt sich, einen Blick darauf zu werfen, da sich hinter diesem Begriff großes Potenzial versteckt.

Die Retro – Was ist das Ziel?

Die Retro ist ein Termin der regelmäßig wiederholt wird und in welchem das Team sich die Zeit nimmt, ihre Zusammenarbeit zu reflektieren. Was ist das Besondere daran?

Die meisten Teams sind völlig in die Projektarbeit versunken. Das ist verständlich, schließlich ist Zeit kostbar und die Aufgaben neigen dazu, stetig mehr anstatt weniger zu werden. Aber was macht ein erfolgreiches Team aus? Die gemeinsame Performance und Zusammenarbeit!

Wie aber soll ein Team sich verbessern, wenn es sich keine Zeit nimmt, die aktuelle Art und Weise zu bewerten und zu überprüfen? Genau hier setzt die Retrospektive an.

Nach jedem Sprint zieht sich das Team zurück, um gemeinsam zu besprechen, was gut lief und wo sich das Verbesserungspotenzial versteckt. Konflikte, die ein Team lähmen können, werden so bereits frühzeitig aufgedeckt. Das Team kann gemeinsam daran arbeiten, effizienter zu werden, Arbeitsabläufe zu verbessern und ihre Qualität zu steigern.

Aller Anfang ist schwer

Bei all den Vorteilen stellt sich die Frage, warum nicht alle Teams zu dieser Methode greifen. Die Antwort darauf ist simpel: Viele Führungskräfte legen mehr Wert darauf, dass Aufgaben schnell umgesetzt werden. Die Zeit, die sich das Team für die Reflektion nehmen würde, sehen sie an anderer Stelle besser eingesetzt.

Diese Auffassung ist gefährlich und zeigt eine kurzfristige Denkweise. Natürlich kann die Zeit für den Termin dazu genutzt werden, Themen weiter voranzutreiben. Langfristig gesehen bleibt das Team jedoch auf der Strecke und verpasst Gelegenheiten, sich zu verbessern. Außerdem wird hier etwas Wichtiges vergessen: Dadurch, dass sich ein Team stetig weiter entwickelt, steigt die Effizienz und Zeit kann sogar eingespart werden.

Widerstand kommt aber nicht immer von den Führungskräften, auch Teammitglieder können diese Argumente bringen.

Sie können mit Aussagen rechnen, wie:
– Unsere Zusammenarbeit ist doch schon super
– Dafür haben wir gerade keine Zeit

Sie sind dennoch von den Vorteilen der Retro überzeugt und wissen, dass sowohl Sie, das Team, aber auch das Projekt langfristig davon profitieren? Legen Sie die richtigen Grundsteine!

Nehmen Sie die Tür, anstatt durch die Wand zu brechen!

Führen Sie ein Auftaktmeeting durch, um das Team von der Retro zu überzeugen. Erklären Sie, was eine Retro ist und wie Sie gemeinsam davon profitieren können. Sie haben in der Regel mit weniger Widerstand zu rechnen, wenn Sie die Einführung gemeinsam planen, anstatt das Team vor vollendete Tatsachen zu stellen.

Wie sieht eine Retro aus?

Eine Retro wird immer vorbereitet, moderiert und hat Grundregeln, die jeder beachten muss:
– Las Vegas Regel: Alles, was in diesem Termin besprochen wird, bleibt im Termin!
– Goldene Regel: Wertschätzender und respektvoller Umgang ist das A und O!

Eine beliebte Retro, für die Sie nicht viel vorbereiten müssen, ist die 4-L-Retro (Liked, Learned, Lacked, Longed for).

Auf einem realen oder digitalen Whiteboard sind 4 Spalten oder Raster vorgezeichnet: Was lief gut? Was habe ich gelernt? Was hat gefehlt? Und was hätte ich mir gewünscht?

Geben Sie dem Team Zeit, kurz darüber nachzudenken und in jedes der Raster mindestens ein Post-it zu schreiben. Sind alle fertig, kann jeder seine Antwort vorstellen. Es hilft, wenn der Moderator zusammengehörende Themen schon mal clustert.

Nach einer Diskussion kommt der wichtigste Teil der Retro: Leiten Sie gemeinsam Maßnahmen ab, welche Sie nachhalten.

Es gibt unzählige Tools und Formen von Retros, Sie müssen nicht jedes Mal die gleichen Fragen verwenden. Ob kurz und effizient, oder etwas verspielter – schauen Sie, welche Methode besser beim Team ankommt. Mit etwas Abwechslung wird es garantiert nicht langweilig und Erfolge sind vorprogrammiert.

Serverless: Vorteile für IT-Projekte

Schreibe eine Antwort

Warum sollten IT-Projekte auf Serverless setzen? Für Teams, die bereits auf eine Cloud-Infrastruktur (AWS, Azure, IBM etc.) setzen, ist die Argumentation im Grunde ein No-Brainer: Wer bereits den Cloudgedanken akzeptiert hat, also dass der Cloudanbieter die Virtualisierung, die Serverfarmen, die Skalierung und anderes übernimmt, so gilt die gleiche Argumentation für Serverless. Serverless folgt daher dem Servicegedanken und wir nennen es auch (FaaS = Function as a Service).

Wie kommen wir von der Cloud zu finanziellen Vorteilen?

Ganz einfach: Für gewöhnlich kümmert sich ein weiterer Infrastrukturdienstleister oder spezielle Leute im Team darum, auf dem Cloudservice z.B. Container zu betreiben, die letztlich die Anwendungen ausführen, also bereitstellen. Das Gleiche gilt für die Veröffentlichung der Software: Jemand kümmert sich darum.

Doch durch den Servicegedanken IaaS und PaaS (Infrastructure as a Service und Platform as a Service) ist uns bereits das Konzept klar, solche Low-Level-Aufgaben als Standardpaket zu nutzen.

Wir setzen also Cloudservices ein, weil dies zu mehr Standardisierung, zu mehr Skalierbarkeit, zu effizienteren Abrechnungsmodellen führt. Damit erhöhen wir die Zuverlässigkeit unserer Softwareprodukte, die Planungssicherheit und erzielen daraus letztlich finanzielle Vorteile.

Geringere Time-to-Market

Function as a Service (FaaS = Serverless) minimiert die Time-to-Market weiter. Container müssen nicht explizit auf Funktion getestet werden. Die Containerisierung schlägt nicht fehl. Wir haben weniger Risiken. Eine Softwarelieferung (ein Release) wird daher einfacher bzw. zuverlässiger. Weniger manuelle Aufwände und Zwischenfälle bei Inbetriebnahmen führen zu kürzerer Iteration bzw. Features können schneller ausgeliefert werden.

Kosteneffizienz durch Skalierbarkeit

Schon bei Evolutionsschritten in die Cloud haben wir verstanden, dass wir die Ressourcen an unseren tatsächlichen Bedarf anpassen können. Diese Effekte und Vorteile der Cloud sind bekannt. Konkret gesprochen: Unsere IT muss nicht erst neue Server bestellen, anliefern, montieren lassen und so weiter, damit mehr Last, mehr User, höherer Bedarf unserer Kunden gedeckt werden kann. Mit wenigen Klicks in den Konsolen des Cloudanbieters kann die IT nun Ressourcen loswerden, wenn diese nicht mehr benötigt werden, bzw. neue Ressourcen dazunehmen, sobald sich der Bedarf erhöht. Durch das sogenannte Auto-Scaling ist dies sogar automatisch möglich. Beispielsweise an verschiedenen Werktagen oder bei gewissen Ereignissen, wie Produktvorstellungen oder saisonalen Ereignissen.

Dieses Konzept lässt sich mit Serverless noch effizienter gestalten. Kosten fallen nun nur noch an, wenn gewisse Funktionen auch tatsächlich verwendet werden.

Angenommen Ihr Team betreibt einen Blog. In diesem Blog können Artikel auf Social Media Plattformen geteilt werden, Artikel gesucht, gelesen und kommentiert werden. Nach dem ursprünglichen Konzept fallen Kosten für einen bestimmten Server an, auf dem eine Software vorliegt (die Blog-Anwendung), die all diese Funktionen ermöglicht.

Egal ob 10.000 User oder 100 Ihren Blog pro Monat aufrufen und egal welche Funktionalität sie davon verwenden. Die Skalierbarkeit der Cloud ermöglicht es nun, dynamisch in einem Monat die Ressourcen für 10.000 Nutzer zur Verfügung zu stellen, während die Ressourcen im nächsten Monat so reduziert werden können, dass sie die 100 Nutzer bestmöglich versorgt, allerdings die Kosten der nicht benötigten Ressourcen einspart. Für Teams, die bereits auf die Cloud setzen, ist dies nichts Neues.

Was aber, wenn die in einem Monat, in dem 10.000 User ihren Blog verwenden, nur knapp 1.000 davon, ihre Artikel kommentieren, 9.000 von ihnen aber nicht? Sie bezahlen das Feature „Artikel kommentieren“ für 9.000 Nutzer, die es nicht nutzen.

Mit Serverless ist es nun möglich, ausschließlich für die Ausführung der reinen Funktionalität zu zahlen. Die 9.000 Nutzer im Beispiel oben würden demnach für das Kommentieren keine Kosten erzeugen, lediglich für andere Aktionen, wie Lesen und Teilen.

Der ROI (Return on Investment) ist an der Stelle natürlich erst mit konkreten Zahlen zu erreichen, die den Betrieb der Instanzen (also der Ressourcen, die eine Anwendung wie den Blog in unserem Beispiel) für 10.000 Nutzer in dem Monat pauschal verfügbar machen, den Kosten für die Nutzung der jeweiligen Features gegenüberstellen. Das ist vielleicht Stoff für einen weiteren Artikel. Kommentiert doch bitte, falls dies interessant wäre.

Mehr Uptime durch Skalierbarkeit

Wie im Beispiel oben, fallen natürlich nicht nur Kosten in ungenutzten Zeiten (Idle-Times) an, Server laufen, sind in Standby und verbrauchen währenddessen Ressourcen. Nicht bei Serverless. Die Technologie verteilt die Ausführung der Funktionalität optimal auf die entsprechende Infrastruktur, sodass die entsprechenden Funktionalitäten stets zur Verfügung stehen – bei jeder Bedarfssteigerung und Minderung.

Weniger Aufwand für das DevOps-Team

In Teams, die Container verwenden, braucht es Mitglieder im Team, die sich darum kümmern, dass die Anwendungen korrekt in Container verpackt werden, dass die Anwendungen der QS unterzogen werden, dass die Releases automatisiert funktionieren etc. Diese Aufgabe geht nicht auf Null, denn weiterhin müssen die allgemeinen Zyklen wie Planung, Entwicklung, Test, Release etc. automatisiert durchgeführt werden. Doch diese Themen werden schlanken. Es muss weiterhin entwickelt und getestet werden, soweit ist klar. Doch Container müssen nicht hergestellt, versioniert und verwahrt werden. Dadurch werden Routineaufgaben bzw. Wartungsaufgaben vermindert, weniger Fehler treten auf und es fallen weniger Lizenzgebühren an.

Fazit

Die Vorteile für IT-Projekte und Teams durch Serverless sind somit recht deutlich. Die feinere Skalierbarkeit auf der Ebene der Funktionalitäten und nicht auf Anwendungsebene ermöglicht eine weitere Steigerung von Verfügbarkeiten und geringere Kosten durch weniger Aufwand. Es gibt aus meiner Sicht keinen Grund, nicht auf Serverless setzen.

Planning-Poker: Pause, Stabilität, Mitspieler kicken und mehr

1 Antwort

Oft nachgefragt: Abwesende Spieler soll man kicken können, also aus dem Raum entfernen. Ob diese Funktion wirklich gut für das Spielerlebnis ist, bleibt abzuwarten. Wir haben dieses und andere Features in die neue Version eingebaut.

Nach weiteren Sprints und somit Plannings und Schätzrunden im Home-Office konnten wir weitere Informationen über unser Planning-Poker-Tool sammeln (welches wir auch kostenlos zur Verfügung stellen). Teammitglieder wünschten sich weitere Features, Verbindungsprobleme fielen auf und es gab Ideen zur Verbesserung des User Interface. In der aktuellen Version haben wir ein paar Dinge davon realisiert.

Zurückkehren in den Raum

Nach längeren Diskussionen, nach der Mittagspause mussten einige Kollegen einen neuen Spielernamen wählen, wenn sie den Browser zwischenzeitlich geschlossen hatten. Entsprechend ist es jetzt möglich, den Link zum Raum einfach erneut aufzurufen und gleich wieder den eigenen Spieler einzunehmen.

Stabilität: Verbindungsproblem behoben

Die Verbindung brach teilweise ab, sodass neue Spielstände nicht aktualisiert wurden. Die Zweiwegekommunikation (WebSockets) zwischen Scrumpoker und Server war nicht stabil. Ein Update des Kommunikationsmoduls (Sock.js zu STOMP) ermöglicht nun über sogenannte Heartbeats, also regelmäßige Lebenszeichen, die Agile Casino und Server miteinander austauschen (Pings technisch gesehen), die Verbindung sofort neu aufzubauen, falls sie abbricht.

Feature: Pause und automatische Pause ☕️

In den meisten Kartensets für Planning-Poker gibt eine Karte mit dem Wert „Kaffeetasse“. Eher eine Scherzkarte. Natürlich kommt es in einer Remote-Session vor, dass jemand zeitweise nicht am Planning teilnimmt, weil z.B. in einen anderen Call muss oder einfach mal kurz zur Tür. Wir haben beides miteinander verbunden. Der Spielt kann die Kaffeetassenkarte spielen und zeigt so den anderen Spielern an, dass er bewusst nicht mitschätzt. Der Pausemodus wird auch für die Folgerunden automatisch beibehalten. Solange der Spieler keinen anderen Wert spielt, wird automatisch die Kaffeetasse gespielt.

Überigens: Spielt ein Spieler in einer Runde keinen Wert (weil er z.B. sträflich versäumte, die Kaffeetasse expliziet zu wählen), wird er automatisch in den Pausemodus versetzt und spielt für die nächsten Runden automatisch die Kaffeetasse (bis er etwas anderes spielt).

Feature: Mitspieler kicken 😧

Auch dieses Feature wurde desöfteren angefragt. Ich bin mir noch nicht sicher, ob es wirklich notwendig ist und ob alle Spieler verantungsvoll mit dieser Option umgehen können. Spieler haben die Möglichkeit, andere Spieler im Pausemodus aus dem Spiel zu entfernen. Fährt man in der Spielstandsanzeige mit der Maus über den Wert des Spielers, erhält man die Möglichkeit, den Spieler zu entfernen. Nutzt es weise.

Feature: Spielfeld „Pokertisch“ verschönert ♥️

Bisher lagen die gespielten Karten einfach so in der linken Bildschirmhälfte herum. Wir haben die Karten jetzt an einen angedeuteten Tisch plaziert. Das Spielgeschehen wirkt so aufgeräumter und gemeinschaftlicher. Auf sehr kleinen Geräten müssen wir diese Darstellung in Zukunft noch anpassen (z.B. den Tisch in die Vertikale drehen).

Ausblick in Zukünftige Features

Die im Artikel zum letzten Update bereits erdachten neuen Features erstmal noch hinter dieser aktuellen Iteration an. Für Min- und Maxwerte wurde bereits alles vorbereitet. Außerdem solle eine Jira-Integration geben, einen zwischen allen Spielern synchronisierten Timer und die Punktereihen (Fibonacci, T-Shirtgrößen, etc.) sollen anpassbar werden.

Unser Planning Poker findet ihr unter https://agilecasino.kehrwasser.com und könnt dort einfach kostenlos und ohne Registrierung einem Raum beitreten. Nutzt es gerne und vor allem sagt mir, was ihr davon haltet. Die Regeln für Planning-Poker haben wir hier nochmal zusammengefasst (auch als PDF zum Download).

Planning Poker Regeln auf einer Seite erklärt [PDF]

3 Antworten

Die Planning Poker Regeln sind einfach. Planning Poker ist eine spielerische, aber durchaus ernstgemeinte Methode Aufwände in agilen Teams zu schätzen. Wir haben die Regeln mal zusammengefasst. Sechs einfache Phasen gibt es. Die Spielregln haben wir auf einer Seite zusammengefasst, zum Download. Auf einen Blick leicht verständlich. Daraus ist eine ganz nette Infografik, ein Cheat Sheet geworden, das sich gut im Team, bei der nächsten Remotesession teilen lässt. Auch ideal zum Ausdrucken und um es ins Office zu hängen.

Als Onlinetool für Planning Poker empfehlen wir das kostenfreie Agile Casino. Das online Planning Poker lässt sich ohne Registrierung in unbegrenzten Runden und mit mehr als 7 Spielern spielen.

Regeln für Schätzpoker

Schritt 1: Das Deck. Jeder Schätzer hält einen Stapel Planungspoker-Karten mit den Werten 0, 1, 2, 3, 5, 8, 13, 21 oder ? in der Hand, was der von uns empfohlenen Reihenfolge entspricht. Die Werte stehen für die Anzahl der Story Points, der idealen Tage oder anderer Einheiten, in denen das Team schätzt.

(Hier können natürlich andere Varianten bevorzugt werden. Zu erwähnen sind T-Shirtgrößen wie S, M, L, XL etc. oder „The Power of 2“, also 1, 2, 4, 16, etc.)

Schritt 2: Diskussion. Die Schätzer diskutieren ein Feature und stellen dem Product Owner bei Bedarf Fragen. Wenn die Funktion vollständig diskutiert wurde, wählt jeder Schätzer für sich eine Karte aus, die seine Schätzung darstellt.

Schritt 3: Aufdecken. Die Runde deckt alle Karten gleichzeitig auf.

Schritt 4: Fertig falls Konsens. Wenn alle Schätzer denselben Wert gewählt haben, wird dieser zum Schätzwert.

Schritt 5: Weiterdiskutieren. Wurde noch kein Konsens erzielt, diskutieren die Schätzer ihre Schätzungen. Insbesondere die Schätzer mit dem höchsten und dem niedrigsten Wert sollten ihre Gründe mitteilen. Nach einer weiteren Diskussion wählt jeder Schätzer erneut eine Schätzkarte aus und alle decken ihre Karten erneut gleichzeitig auf.

Schritt 6: Wiederholen: Der Prozess des Planning Poker wird so lange wiederholt, bis ein Konsens erreicht wurde. Ausnahme: Falls das Team zu der Einschätzung gelangt, über unzureichende Informationen zu Verfügen, kann es die Schätzung eines bestimmten Elements verschieben, bis zusätzliche Informationen vorliegen.

PDF zum kostenfreien Download

Kein Newsletterabo, keine Registrierung: Einfach so downloaden. Es wäre schön, wenn ihr das kostenfreie Scrum-Poker-Tool Agile Casino mal ausprobiert. Es gibt eine deutsche und eine englische Version. Schreibt gerne in die Kommentare, was ihr dazu denkt.

Vorschau Cheat Sheet Planning Poker — Vorschau des Cheat Sheets

scrum-poker-planning-infographic-cheat-sheet.pdf Download [EN-Version]

DE-scrum-poker-planning-infografik-cheat-sheet.pdf Download [DE-Version]