Schlagwort-Archive: projektmanagement

AARRR Pirate Metrics Framework – Was ist das?

Softwareprodukte auf ihre Monetarisierung zu optimieren, benötigt objektive Messungen um den Fortschritt zu sehen. Der Weg vom ersten User bis zum zahlenden Kunden ist praktisch ein Blindflug. Die AARRR-Metriken geben ein Maß für den Fortschritt auf diesem Weg. Es gibt eine Reihe von Metriken, die als „Pirate Metrics“ bekannt sind. Diese Metriken bieten einen umfassenden Überblick über den Kundenlebenszyklus und helfen Unternehmen dabei, ihre Wachstumsstrategien zu optimieren. Der Begriff „Pirate Metrics“ wurde von Dave McClure geprägt und bezieht sich auf die fünf entscheidenden Schritte, die ein Kunde durchläuft: Acquire (Gewinnen), Activate (Aktivieren), Retention (Binden), Referral (Empfehlen) und Revenue (Umsatz). Lassen Sie uns diese Metriken genauer betrachten.

AARRR oder andere Innovationsmetriken unabdingbar für Innovation

Eric Ries spricht auch gerne von „Innovation Accounting“ als Mittel gegen sogenannte „Vanity Metrics“. „Vanity“ = Eitelkeit. Er meint also geschönte Metriken, die dem Team zwar ein gutes Gefühl geben, die Stakeholder und Geldgeber besänftigen, aber letztlich nicht zeigen, ob sich das Team auf Kurs befindet. Sie eigenen sich daher nicht um Entscheidungen zu treffen und zu steuern. Das Gegenteil sind „Actionable Metrics“ – die wollen wir haben.

Es braucht diffizile Metriken die wirklich einen Kausalzusammenhang herstellen. Zum Beispiel folgt aus viel Traffic noch nicht unbedingt, dass dieser auch ein Interesse an dem Produkt hat. Es ist ein Leichtes eine Googleanzeige auf ein Keyword wie „Team“ zu schalten und tausende von Besuchern auf eine Seite mit Büroartikeln zu schicken. Sicherlich kann man annehmen, dass einige der Menschen, die sich in irgendeiner Form für Teams interessieren, auch für Büroartikel interessieren, doch ist damit nicht direkt die Intention verbunden, sich über Büroartikel zu informieren, sich an einer Plattform zu registrieren oder gar Büroartikel zu kaufen.

Unklarer wird dieser Zusammenhang noch bei Produkten, die Features haben, die bisher nicht gekannt sind. Wie hoch das Interesse ist, wie das Interesse geweckt werden kann, ist vollständig unbekannt.

Hier bringen die AARRR-Metriken Orientierung, wo ansonsten keine ist.

Bedeutung von Metriken für die Team Motivation

Leadership: Teams ohne Metrik sind wie Rudern in einer Galeere — Sklaven in einer Galeere

Übersehen wird, dass Metriken der Schlüssel zur echten Motivation sind. Nicht die falsch verstandene „Team Building“-Motivation, mit Pizzaessen, Bowlingabend und Kletterwand. Metriken – richtig umgesetzt – führen dem Team kontinuierlich vor Augen, wofür es arbeitet, ob es sich auf Kurs befinden. Man stelle sich vor in einer Galeere zu rudern und nie zu wissen, ob sich das Schiff überhaupt bewegt. Oder auch: Ob es sich in die richtige Richtung bewegt.

Das Abarbeiten einer Roadmap verhält sich in diesem Gleichnis, wie das Wissen um die Anstrengung die braucht, um zu rudern: Abarbeiten Aufgabe für Aufgabe sagt einem Team nur, dass es Rudert. Oder die Aufgaben auch wirklich das Schiff nach vorne treiben und ob das gesamte Team auch in die richtige Richtung steuert, weiß niemand, wenn der Erfolg nicht ausgewertet wird.

Acquire (Gewinnen)

Der erste Schritt auf dem Weg zum Wachstum ist die Gewinnung neuer Kunden. Die „Acquire“-Metrik konzentriert sich darauf, wie erfolgreich ein Unternehmen potenzielle Kunden erreicht und sie auf seine Plattform bringt. Hier spielen Marketingstrategien, Werbekampagnen und Conversion Rates eine entscheidende Rolle. Unternehmen sollten analysieren, welche Kanäle die meisten qualifizierten Leads liefern und ihre Ressourcen entsprechend ausrichten.

Activate (Aktivieren)

Die nächste Etappe ist die Aktivierung der Nutzer. Es reicht nicht aus, Kunden zu gewinnen; sie müssen auch aktiviert werden, um den vollen Nutzen aus dem Produkt oder der Dienstleistung zu ziehen. Die „Activate“-Metrik misst, wie effektiv ein Unternehmen neue Benutzer in zahlende Kunden umwandelt. Ein übersichtliches Onboarding, klare Anweisungen und ein reibungsloser Startprozess sind entscheidend, um die Aktivierungsrate zu maximieren.

Siehe auch die Definition von Active User. Die Monthly Active User sind eine belibte Kennzahl bei Investoren.

Retention (Binden)

Die langfristige Kundenbindung ist entscheidend für den nachhaltigen Erfolg eines digitalen Produktes. Die Retention Rate misst, wie gut ein Unternehmen Kunden über einen bestimmten Zeitraum behält. Um Kundenbindung zu fördern, ist exzellenter Kundenservice, regelmäßige Kommunikation und die Bereitstellung von Mehrwert entscheidend. Unternehmen sollten Feedback nutzen, um ihre Produkte und Dienstleistungen kontinuierlich zu verbessern und Kunden langfristig zu binden.

Referral (Empfehlen)

Zufriedene Kunden sind die besten Botschafter für ein Produkt. Die „Refer“-Metrik misst, wie viele Kunden bereit sind, die Software ihren Freunden und Kollegen weiterzuempfehlen. Mundpropaganda ist eine kraftvolle Marketingstrategie und Unternehmen sollten Anreize schaffen, um ihre Kunden zu motivieren, das Unternehmen weiterzuempfehlen. Ein positives Image und Kundenbewertungen können dazu beitragen, die Empfehlungsrate zu steigern.

Der Virale Koeffizienz: Für Apps, Software, Websites mit sozialen Netzwerk- oder Community-Funktionen stellt „viral gehen“ oder das Erreichen eines viralen Koeffizienten von mehr als 1,0 sozusagen den heiligen Gral der Trafficgewinnung dar. Was steckt dahinter? „Viral gehen“ bedeutet, dass die Kosten für die Neukundengewinnung im Wesentlichen auf 0 gesunken sind.

Revenue (Umsatz)

Das Wichtigste ist das Unwichtigste. Natürlich ist der Umsatz letztlich das was zählt. Doch der größte Fehler ist, von Anfang an nur auf den Umsatz zu schauen. Denn da in der Innovationsphase der Umsatz oder Umsatzzuwachs 0 sein muss, kann man an ihm keine Tendenzen ablesen. Er bewegt sich nicht und zeigt daher nicht an, ob unsere Maßnahmen, Verbesserungen Wirkung zeigen. Am Ende der Kette entscheidet aber natürlich der Umsatz, wie gut das neue Feature, das digitale Produkt monetarisiert ist. Erst jetzt wird es möglich und wichtig, die Umsatzentwicklung kontinuierlich zu überwachen.

Schlussfolgerung

Die AARRR Metriken oder „Pirate Metrics“ bieten eine einfachen Startpunkt für Produktteams und Startups, einzelne Innovationsprozesse zu steuern. Indem sie diese fünf Metriken analysieren und optimieren, können Teams ihr Budget gezielt investieren, ungewollte Features vermeiden. Ihre Erfolgswahrscheinlichkeit steigt immens. Letztendlich geht es darum, den Kundenlebenszyklus zu verstehen und sicherzustellen, dass jeder Schritt reibungslos und effektiv abläuft.

Remote Arbeit: Motivierte Teams zuhause

1 Antwort

Remote Arbeit ist trotz der Erfahrungen der Pandemie weiterhin kontrovers. Es ist möglich, professionelle und hochmotivierte Teams aufzubauen, die vollständig remote arbeiten. Was sind die aktuellen wissenschaftlichen Beiträge dazu?

Sind Teams in Remote Arbeit wirtschaftlich sinnvoll?

Es gibt gute Gründe ins Büro zu gehen. Jedenfalls für einige Teams. Es gibt aber auch gute Gründe für einige, reine Remote Teams zu sein. Die Frage ist nicht, ob die Zukunft der Arbeit entweder in der Remote Arbeit liegt oder vorort. Es geht um die Frage, ob reine Remote Teams von der Performance her mit Offlineteams mithalten können. Ist Homeoffice ein Benefit wie das Jobrad oder eine BahnCard es ist? Ein Herz für Stubenhocker sozusagen? Oder kann man Teams aufbauen, die am Ende produktiver sind, als sie es wären, wenn sie in Präsenz arbeiten müssten. Und sind sie vielleicht dazu weniger oft krank, motivierter, effizienter und allgemein zufriedener? Wie gesagt: Nicht alle Teams und Menschen, aber einige.

Man kann in Remote Arbeit eine Gemeinschaft schaffen

Eine besonders kontroverse Frage ist wohl, in wie weit sich aus der Ferne, in einem Team, das sich physisch nie oder fast nie sieht, eine Verbindung herstellen lässt. Das bedeutet nicht, dass Freundschaften, Kollegialität, Loyalität sich nicht in ausreichendem Maß über die Ferne aufbauen ließe.

Es gibt einige Anzeichen, warum das stimmen könnte und die die Hoffnung auf großartige Remote Teams aufrechterhält und sogar nährt.

Ich sehe Omas und Opas die ihre Enkelkinder die meiste Zeit über die Ferne begleiten. Ich sehe dort starke Bindungen trotz Distanz und Virtualität. Freundschaften, die über Jahre über eine weite Strecke halten, kenne ich aus eigener Erfahrung. Mehrfach.

Viele introvertierte Menschen scheuen sich geradezu vor physischen Teamereignissem im Reallife. Ist es ein Verbrechen, sich hinter einem Computerbildschirm sicherer und wohler zu fühlen? Sicherlich jene sogar besser, wenn man sie nicht umerzieht.

Gamer machen es seit Jahrzehnten vor. Noch als ich vor Jahrzehnten zur Schule ging gab es die ersten Kameraden, die sich zu sogenannten Klans und Gilden zusammengeschlossen haben – teilweise Menschen die sich nie physisch begegnet sind, sich aber dennoch regelmäßig im virtuellen Raum getroffen haben um ein gemeinsames Ziel zu erreichen. Interessant ist, dass heute im Trend ist, Gilden, Chapter und Task Forces in der allgemeinen Arbeitswelt einzuführen.

Ich habe Exsoldaten in Wohnheimen kennenlernen dürfen, die nicht im Verdacht standen, den echten Kontakt mit Menschen zu scheuen. Dennoch verzog er sich mit kindlicher Freude teilweise samstagabends mit einem Sixpack und einem Headset vor den Rechner um der Spielfreude ausgiebig zu nachzugeben.

Das sind alles noch keine wissenschaftlichen Belege, aber doch gute Anhaltspunkte, dass sich eine starke Bindung aufbauen lässt. Es kommt dabei sehr auf die Teamstruktur an. Habe ich viele Mitarbeiter, die ständig auf die Rampe müssen? Aber sein wir doch mal ehrlich: In welchen Bereichen ist das heute noch so? Vielleicht in Salesteams. Die meisten sind doch eher kopflastig – gerade in Innovationsteams.

Remote Team Building

Remote Team Building funktioniert hervorragend. Es hat schon etwas mit einer gewissen Gamification zu tun und darf nicht konstruiert sein (letzteres gilt genauso für Teams die zu 0% remote arbeiten).

Auch ein Remote Team muss erst ein Team werden. Ein Team verfolgt ein gemeinsames Ziel. Die Mitglieder müssen die gemeinsame Vision verstehen, ihre Wichtigkeit, ihren Zweck. Sie müssen verstehen, dass sie keine Einzelkämpfer sind und jedes Teammitglied eine wichtige Aufgabe erfüllt. Ein Team muss in gewisserweise eine Bruderschaft werden. Man muss zusammen durch etwas gehen.

Dabei reden wir gerade nicht über gemeinsame digitale Bowlingabende, Pokerrunden oder tatsächlich irgendwelche gemeinsam gespielten hardcore Games. Das kann man natürlich zusätzlich machen, sofern es den Geschmack des Teams trifft. Soetwas ist nicht jedemanns Sache und kommt teilweise sogar eher als lästige Pflicht daher.

Viel wichtiger: Ist Remote Team Building zu konstruiert, wirken solche Teamevents künstlich. Diese Wirkung wiederum verstärkt den Eindruck, dass das Team es nötig hat, ein künstliches Szenario aufzubauen. Das sät Zweifel daran, ob die eigentliche gemeinsame Aufgabe wirklich wichtig genug ist, um sinnvoll zu sein. Eine Herausforderung bei der man aufeinander angewiesen ist, um sie zu meistern. Gemeinsam an Dokumenten arbeiten, gemeinsame Brainstormings oder auch eine Runde Planning Poker ist organisch.

Und genau dabei geht es beim Teambuilding nicht nur im Remote Team: Die Abhängigkeit der Teammitglieder untereinander und das gegenseitige Vertrauen aufzubauen.

Hybrides Arbeiten

Hybride Meetings sind nur okay, wenn die technische Ausrüstung buchstäblich hervorragend ist. Große Bildschirme und exzellente Soundqualität sind notwendig, um die Mitarbeiter gleichwertig zuschalten zu können. Trotz bestem Equipment kommt es dazu, dass die Remotekollegen nicht dieselbe Präsenz haben, wie die Kollegen Vorort. Sie können leicht abgeschnitten und ignoriert werden. Teams mit Remotekollegen sollten die Meetings entweder gemeinsam vollständig online oder konsequent offline durchführen, wann immer es möglich ist. Es ist immer mal notwendig, dass jemand nicht persönlich dabei sein kann. Dann sollte man sich überlegen, ob der Kollege nicht evtl. komplett aussetzt. Ausnahme kann man ihn natürlich virtuell dazu holen. Eventuell auch nur als Telefonjoker.

Das heißt alles nicht, dass es nicht förderlich wäre, sich ab und an im Office zu treffen. Eine gemeinsame Retro, einen Hackathon, ein Brainstorming an der Pinnwand oder so etwas kann helfen, wenn die eigenen vier Wände zu eng werden. Auch ein gemeinsames Abendessen ist manchmal Gold wert – aber das gilt ohnehin für alle Teams. Doch vorsicht: Ist das Team sehr verteilt, kann es zu ungesunden Grüppchenbildungen und in der Folge zu Lagerkämpfen im Team kommen. Teammitglieder fühlen sich ausgeschlossen. Das ist das Schlimmste, was dem Teamgefüge aus meiner Sicht passieren kann.

Wissenschaftliche Sachlage zur Remote Arbeit

Laut Fachhochschulprofessor Prof. Dr. Carsten C. Schermuly gibt es kaum Daten. Viele Arbeiten und Studien sind noch aus der Vorcoronazeit. Die Studien zeigen nur Ergebnisse, die auf vergangenen, damit zumindest improvisierten, Remotepraktiken aufbauen. Sprich Organisationen machen genau die oben beschriebenen Fehler bei der Remote Arbeit und die Studien messen darauf die Motivation und Produktivität der Teams. Natürlich sind die Ergebnisse dann mies.

Ein Setting für eine Studie wäre es, drei statt nur zwei Gruppen zu vergleichen. Nicht nur reine Offlineteams mit Situationen, in denen einige Teammitglieder eben von Zuhause aus arbeiten. Es müssen wirklich Remote Teams im Sinne der obigen Beschreibung ebenfalls untersucht werden. Also Kontrollgruppe: Offlineteams und dann die Varianten „Offlineteam mit Homeofficeregelung“ und „Vollständiges Remote Team“. Erst dadurch kann nach Ceteris Paribus ein Kausalzusammenhang zwischen der Hypothese, dass Remote Teams mindestens so wirtschaftlich sind wie klassische Teams.

Leider habe ich und Schermutly laut seinem Post bei Linkedin noch keine derartige Studienlage gefunden.

Klar ist für Schermutly, dass Homeoffice alleine nicht bereits NewWork bedeutet (das soll der vorliegende Artikel ebenfalls in keiner Weise suggerieren). Das erklärt er unter anderem in einem Gespräch mit Stefan Scheller.

Schermutlys Beschreibung, dass Remote Arbeit kein Fortschritt im Sinne von NewWork sei, da es sie schon im Mittelalter gab, halte ich für schwierig. Man bekommt den Eindruck, NewWork brauche das Office. Dagegen spricht schon die reine Definition: Wenn NewWork zu mehr Selbstbestimmung der Mitarbeiter führen soll, ist kann es weder einen Zwang für Homeoffice noch für das Office geben. Der Mitarbeiter muss selbstbestimmt entscheiden können, ob er eher in einem Remote Team arbeiten möchte, oder es vorzieht, mit den Kollegen im Office.

Ich werde die Entwicklung der empirischen Fakten aus der Wissenschaft im Auge behalten und berichten, sobald sich Studien ergeben, die analysieren, wie echte Remote Teams im Vergleich abschneiden.

Konklusion zum Thema Remote Arbeit

Ein reines Remote Team konnte ich selbst bereits erfolgreich aufbauen. Will man in harten Metriken ausdrücken, was Erfolg bedeutet, so sind es wohl Werte wie Zusammenhalt, Befinden, Motivation, Krankheitszahlen, Produktivität, Zuverlässigkeit. In dem Remote Team um unser agiles Planungtool sind all diese Werte top. Die sogenannte „Lead Time for Changes“ ist in diesem Team zum Beispiel sogar weit überdurchschnittlich.

Ich sehe keinen Grund, dies nicht reproduzieren zu können. Auch wenn sich nicht jedes Team durch Change Management in ein reines Remote Team überführen lässt. Das muss es aber auch nicht.

Zusammengefasst: Softwareentwicklung nach Robert C. Martin

Schreibe eine Antwort

Ich stelle immer wieder fest, dass Projektleiter von Softwareprojekten dem Irrtum zum Opfer fallen, man könne einfach einen Softwareentwickler ins Projektteam packen und dann kommt Software heraus, die funktioniert, robust, erweiterbar ist und wartbar bleibt. Das ist nicht so. Robert C. Martin erklärt in verschiedenen Büchern, wieso das so ist.

Robert C. Martin, auch bekannt als „Uncle Bob“, ist ein bekannter Softwareentwickler und Autor, der vor allem durch sein Buch „Clean Code“ bekannt geworden ist. Martin hat eine klare Vorstellung davon, was er unter Softwareentwicklung versteht und wie sie richtig durchgeführt werden sollte.

Für Martin ist Softwareentwicklung der Prozess, bei dem wir Anforderungen an ein System in Form von Code umsetzen. Dieser Code sollte dann in der Lage sein, die Anforderungen des Systems zu erfüllen und zu einem späteren Zeitpunkt leicht wartbar und erweiterbar sein.

Martin betont die Bedeutung von Qualität in der Softwareentwicklung. Für ihn bedeutet dies, dass der Code einfach zu lesen und zu verstehen ist, gut strukturiert und modular aufgebaut ist und frei von Fehlern und Inkonsistenzen ist. Er glaubt, dass die Qualität des Codes direkt proportional zur Qualität und zur Wartbarkeit des Systems ist.

Ein wichtiger Aspekt der Softwareentwicklung, den Martin betont, ist die Kommunikation. Er betont die Bedeutung von klaren und präzisen Anforderungen und glaubt, dass effektive Kommunikation zwischen Entwicklern, Kunden und anderen Stakeholdern entscheidend für den Erfolg eines Projekts ist.

Martin ist auch ein Verfechter von professionellem Softwareengineering und glaubt, dass Softwareentwickler professionell ausgebildet und zertifiziert werden sollten. Er betont die Bedeutung von Prozessen und Methoden wie agile Methoden und Code-Reviews, die dazu beitragen, die Qualität des Codes zu verbessern und Fehler zu minimieren.

Schließlich betont Martin die Bedeutung von Weiterbildung und Lernen in der Softwareentwicklung. Er glaubt, dass es wichtig ist, sich ständig weiterzubilden und sich über neue Technologien und Entwicklungen auf dem Laufenden zu halten, um am Puls der Zeit zu bleiben und die bestmögliche Arbeit zu leisten.

Insgesamt versteht Martin unter Softwareentwicklung einen Prozess, der auf Qualität, Kommunikation, professionellem Softwareengineering und ständigem Lernen ausgerichtet ist. Er glaubt, dass diese Aspekte entscheidend sind, um erfolgreich Software zu entwickeln, die zuverlässig, wartbar und erweiterbar ist.

4 bewährte Verfahren für Sprint Plannings

1 Antwort

In diesem Artikel gehen wir vier Grundsätze der Sprintplanung durch, die wir für besonders hilfreich halten.

Die agile Zeremonie des sogenannten Sprintplannings oder schlicht „Plannings“ dient in jedem Sprint dazu, die Ausführung neu zu fokussieren, Überraschungen zu minimieren und eine insgesamt höhere Codequalität zu garantieren.

Überprüfen Sie Ihre Roadmaps, bevor Sie sich treffen

Die Zeit vergeht schneller als wir denken. Daher ist es eine gute Idee, die Roadmap Ihres Projekts in den ersten zwei Wochen des neuen Jahres zu überprüfen. Die Roadmap bildet den Kontext für zwei wichtige agile Konzepte: Epics und Versionen, die das Rückgrat für die agile Programmplanung bilden und dabei helfen, die Lieferung längerfristiger Arbeit zu verfolgen. Vergewissern Sie sich, dass die Roadmap aktuell und für das gesamte Team sichtbar ist und dass Epics und Versionen vor dem Sprint Planning Meeting korrekt in Jira aufgelistet sind.

Halten Sie eine Besprechung vor der Besprechung ab

Die Sprintplanung umfasst zwei wichtige Aufgaben: die Pflege des Backlogs und die Entscheidung, welche Arbeiten im kommenden Sprint abgeschlossen werden sollen. Bei Atlassian haben wir die Erfahrung gemacht, dass das Backlog Grooming am besten in einem separaten Meeting mit dem Product Owner und dem Scrum Master vor dem eigentlichen Sprint Planning Meeting stattfindet. Für das gesamte Entwicklungsteam ist diese Vorbesprechung optional.

Was ist Backlog Grooming?

Backlog Grooming stellt sicher, dass das Backlog gesund ist. Wie sieht das aus? Gut, dass Sie fragen. Ein gesundes Backlog:

priorisiert jedes Arbeitselement, wobei die wichtigste Arbeit an erster Stelle steht
enthält vollständig ausgearbeitete User Stories, mit deren Umsetzung das Entwicklungsteam beginnen kann
Enthält eine aktuelle Schätzung für jedes Arbeitselement

Die Teams bei Atlassian halten einige Tage vor der Sprintplanung kurze Backlog Grooming Meetings ab. Planen Sie 30 Minuten für dieses Meeting ein, um die Aufgaben zu sichten, die Sie in den nächsten zwei Sprints am ehesten angehen werden. Manchmal werden Sie Punkte finden, die nicht detailliert genug sind, um ausgeführt zu werden, oder die mehr kontextbezogene Informationen vom Product Owner benötigen. Das ist das Schöne an der Erstellung des Backlogs im Voraus. Diese Lücken können zwischen den Meetings gefüllt werden, so dass sie während der eigentlichen Sprint-Planung keine Hindernisse (oder Zeitfresser) darstellen. Durch die Erstellung des Backlogs im Vorfeld hat das Team während der Sprintplanung mehr Zeit, seine Optionen für den Sprint zu prüfen und bei Bedarf Elemente für den nächsten Sprint zu markieren.

Team-Aktivität: Manche Teams haben Probleme mit der Schätzung. Story Points bieten einen soliden Rahmen für die Schätzung der Arbeit. Binden Sie das Team in eine Aktivität namens stille Schätzung ein. Legen Sie zu Beginn der Übung die Story-Point-Werte (0,5, 1, 2, 3, 5, 8, 13, 20, 40, 100) in Spalten auf eine weiße Tafel. Bitten Sie dann das Team, die Benutzergeschichten in der Spalte zu platzieren, die sie für am genauesten halten. Die meisten Geschichten werden sich auf eine Zahl konzentrieren, und wenn es Unstimmigkeiten über den Punktwert der Geschichte gibt, ist es an der Zeit, eine Diskussion darüber zu eröffnen, warum. (Siehe auch unseren Artikel zu: Die 6 besten Planning Poker Tools zur freien Verfügung)

Informieren Sie die Sprintplanung mit Daten

Der Schwerpunkt des Sprint Planning Meetings liegt auf der Festlegung und Vereinbarung des Sprint-Ziels – der Menge an Arbeit, die das Team glaubt, während des Sprints erledigen zu können. Der Product Owner, der Scrum Master und das gesamte Entwicklungsteam müssen dabei anwesend sein. Wir bei Atlassian empfehlen ein Minimum von einer Stunde für jede Woche des Sprints, die Sie in der Besprechung abdecken wollen. Beginnen Sie beispielsweise mit einem zweistündigen Sprint Planning Meeting, um einen zweiwöchigen Sprint abzudecken. Idealerweise sollten Sie die Sprintplanung zu Beginn der Woche ansetzen. Dann werden der Kontext und der Arbeitsfluss des Teams weniger durch das Wochenende gestört.

Tipp: Planen Sie die Sprint-Retrospektive und das Sprint-Planning-Meeting nicht zusammen. Geben Sie dem Team genügend Zeit, um die Retrospektive zu verdauen und effektiv zur Sprintplanung beizutragen – vielleicht indem Sie dazwischen ein Teamessen einschieben.
Aus Erfahrung

Zu Beginn der Besprechung stellt der Scrum Master alle relevanten Aktionspunkte aus der Retrospektive des Teams vor. Als Nächstes gibt der Product Owner Produkt- oder Markt-Updates, damit alle auf dem gleichen Stand sind und den breiteren Kontext noch im Kopf haben.

Nach der Nachbesprechung ist es Aufgabe des Product Owners, das eigentliche Planungsgespräch zu beginnen. Zu Beginn verwendet der Product Owner die durchschnittliche Geschwindigkeit des Teams (die Menge an Arbeit, die typischerweise in einem Sprint abgeschlossen wird), um einen Vorschlag für eine Reihe von Storys für den Sprint, den so genannten „Sprint Forecast“, zusammenzustellen, der den Wert für den Kunden maximiert. Der Product Owner sollte auch diese drei Faktoren berücksichtigen:

Feiertage, persönlicher Urlaub und teamweite Ereignisse
Priorität der Stories im Backlog (idealerweise schlagen sie die am höchsten eingestuften Elemente vor)
Wie (und ob) diese Arbeit das Produkt seinem Endziel näher bringen wird

Tipp: Product Owner können den Sprint Marker verwenden, um die Velocity zu berechnen.

Wenn das Team neu ist und keine etablierte Geschwindigkeit hat, sollte der Product Owner keine Sprintprognose vorschlagen. Stattdessen sollte dies eine Übung für das gesamte Team sein, da es wichtig ist, dass jedes Mitglied zustimmt. Zunächst wird das Team die Vorhersage nach bestem Wissen und Gewissen treffen und ein paar Sprints nach dem Prinzip „Versuch und Irrtum“ durcharbeiten. Sobald die Geschwindigkeit des Teams – die durch das Velocitydiagramm in Jira sehr schön veranschaulicht wird – numerisch festgelegt ist, verwenden Sie diese Metrik, um die Sprint-Prognose zu erstellen.

Sobald der Product Owner seine Ideen für den Sprint Forecast vorgestellt hat, kann das Team diesen validieren (und/oder anpassen) und sich auf einen Aktionsplan für den Sprint einigen.

Tipp: Das Team sollte bei jedem Sprint darüber nachdenken, wie die technischen Schulden reduziert werden können. Die Erstellung eines Schnellfilters, der Bugs im Backlog des Teams hervorhebt, ist eine einfache Möglichkeit, wichtige Bugs zu markieren, die in den Sprint aufgenommen werden sollen, während das Team an User Stories in verschiedenen Bereichen der Codebasis arbeitet. Der Schnellfilter „tech debt“ verwendet die JQL-Abfrage „type in (bug)“, um die Ansicht auf Bugs zu beschränken. Erweitern Sie einfach die JQL-Abfrage, um bei Bedarf weitere Fehlertypen einzubeziehen.

Der nächste Schritt in der Sprint-Planung besteht darin, die Stories durchzugehen und zu beschreiben, welche Arbeiten zur Fertigstellung jeder Story erforderlich sind. Während das Team plant, sollten Sie sicherstellen, dass jemand die wichtigsten Punkte in jedem Jira-Ticket festhält. Auf diese Weise sind sowohl die Entscheidung als auch die Begründung später leicht zu erkennen. Das Team sollte sich Fragen stellen wie…

Hat sich die Definition der Story geändert, seit sie geschrieben wurde? Gibt es neue kontextbezogene Informationen, die das Team berücksichtigen muss?
Ist die Schätzung für die Story noch gültig? Ist das gesamte Team mit der Schätzung einverstanden? Wenn nicht, sollte der Scrum Master das Team bei der Neuschätzung anleiten.
Welche Aufgaben sind für die Fertigstellung dieser Story erforderlich? Verwenden Sie Teilaufgaben, um die Arbeit zu parallelisieren und den Ablauf zu optimieren. Wenn das Team bei der Aufteilung der Arbeit auf einzigartige Stories stößt, sollten diese Aufgaben zu völlig unabhängigen Stories erhoben werden.
Welche Auswirkungen hat das Testen auf diese Story? Wie können wir das Testen automatisieren? (Denken Sie daran, dass manuelle Testskripte im Wesentlichen technische Schulden sind).
Sind spezielle Fähigkeiten erforderlich? Wie können wir die Zeit des Spezialisten optimieren, ohne den Rest des Teams zu behindern?
Wie wirkt sich diese Geschichte auf die Architektur des Produkts aus? Gibt es bestimmte Personen, die das Team in den Entwurf und die Codeüberprüfung einbeziehen muss?
Gibt es Abhängigkeiten zwischen den Stories? Können wir angesichts dieser Abhängigkeiten die gesamte Arbeit während des Sprints abschließen?

Die Versuchung ist groß, diese detaillierte Übung überstürzt durchzuführen. Aber eine gute Planung zahlt sich aus, sobald der Sprint beginnt. Hier geht es vor allem darum, zu verstehen, wie die Arbeit erledigt werden soll, wobei der Scrum Master die Diskussion im Team fördert. Es ist wichtig, dass jeder gehört wird, damit sich das Team verantwortlich fühlt, sobald der Plan steht.

Tipp: Während der Sprint-Planung ist es einfach, Stories in den Sprint hinein- und wieder herauszuschieben, während das Team seine Sprint-Prognose erstellt. Klicken Sie einfach mit der rechten Maustaste auf ein Issue, um es in den oder aus dem Sprint zu verschieben.

Auf die Plätze, fertig, Sprint!

An diesem Punkt des Meetings sollte das Team mit dem Sprint Forecast zufrieden sein. Am Ende der Sprintplanung empfiehlt es sich, von allen Anwesenden mündlich zu bestätigen, was das Team am Ende des Sprints tatsächlich ausliefern wird. Stellen Sie außerdem sicher, dass jedes Teammitglied mindestens eine Aufgabe hat, mit der es beginnen kann, und dass niemand doppelte Arbeit leistet.

Das Engagement und die Moral des Teams schwanken natürlich von Sprint zu Sprint. Diese Schwankungen zeigen sich oft während der Sprint-Planung, aber widerstehen Sie der Versuchung, sich sofort damit zu befassen. Nutzen Sie stattdessen die Retrospektive des Teams, um alle Probleme zu verstehen, die sich auf die Moral auswirken. Teams, die schnell auf Kultur- und Entwicklungsprobleme reagieren, sind zufriedener, produktiver und schreiben besseren Code.

Überblick: Voraussetzungen für skalierbare Softwaresysteme

Schreibe eine Antwort

Die Skalierbarkeit von Software ist ein wichtiges Thema, da sie dafür sorgt, dass ein System in der Lage ist, sich an die wachsenden Anforderungen anzupassen und auch bei hoher Nutzung stabil zu bleiben. Es gibt verschiedene Techniken und Best Practices, die man beachten kann, um sicherzustellen, dass ein Softwaresystem skalierbar bleibt.

Eine der wichtigsten Maßnahmen ist die Verwendung von modularen und wiederverwendbaren Komponenten. Indem man das System in kleine, wiederverwendbare Bausteine unterteilt, kann man es leichter warten und erweitern. Zudem ermöglicht es die Verwendung von Komponenten, das System leichter zu testen und zu debuggen.

Eine weitere wichtige Maßnahme ist die Verwendung von Caching. Caching beschleunigt das System, indem es häufig verwendete Daten und Ergebnisse zwischenspeichert, anstatt sie jedes Mal neu zu berechnen. Auf diese Weise kann das System schneller auf Anfragen reagieren und weniger Ressourcen verbrauchen.

Eine weitere Möglichkeit, das System skalierbar zu halten, ist die Verwendung von Microservices. Bei Microservices wird das System in kleine, unabhängige Dienste unterteilt, die einzeln entwickelt, getestet und bereitgestellt werden können. Dies ermöglicht es, das System leichter zu warten und zu erweitern, da man sich auf einen kleineren Teil des Systems konzentrieren kann.

Eine weitere Technik, die bei der Schaffung skalierbarer Systeme hilfreich sein kann, ist das Load Balancing. Beim Load Balancing werden Anfragen auf mehrere Server verteilt, um die Belastung zu verringern und die Verfügbarkeit zu erhöhen. Es gibt verschiedene Möglichkeiten, wie man Load Balancing einsetzen kann, wie zum Beispiel das Round-Robin-Verfahren oder das Least-Connection-Verfahren.

Eine weitere Technik, die bei der Schaffung skalierbarer Systeme hilfreich sein kann, ist die Verwendung von Datenbank-Sharding. Bei Datenbank-Sharding werden die Daten auf mehrere Datenbanken verteilt, um die Belastung zu verringern und die Verfügbarkeit zu erhöhen. Es gibt verschiedene Möglichkeiten, wie man Datenbank-Sharding einsetzen kann, wie zum Beispiel das Horizontal-Sharding, bei dem Daten nach bestimmten Schlüsselwerten auf verschiedene Datenbanken verteilt werden, oder das Vertical-Sharding, bei dem bestimmte Spalten auf verschiedene Datenbanken verteilt werden.

Eine weitere wichtige Maßnahme ist die Verwendung von geeigneten Tools und Technologien. Es ist wichtig, dass man für das System geeignete Tools und Technologien auswählt, die gut skalierbar sind und den Anforderungen des Systems entsprechen. Dies kann beispielsweise die Wahl eines geeigneten Datenbanksystems oder eines geeigneten Load Balancers sein.

Abschließend ist es wichtig, das System regelmäßig zu überwachen und zu optimieren. Durch die Überwachung des Systems kann man frühzeitig mögliche Probleme erkennen und entsprechend reagieren. Zudem kann man durch die regelmäßige Optimierung sicherstellen, dass das System stets auf dem neuesten Stand bleibt und gut skalierbar bleibt.

In Zusammenfassung gibt es verschiedene Techniken und Best Practices, die man beachten kann, um sicherzustellen, dass ein Softwaresystem skalierbar bleibt. Dazu gehören die Verwendung von modularen und wiederverwendbaren Komponenten, Caching, Microservices, Load Balancing, Datenbank-Sharding und die Verwendung von geeigneten Tools und Technologien. Auch die regelmäßige Überwachung und Optimierung des Systems sind wichtig, um sicherzustellen, dass das System gut skalierbar bleibt.

Was ist FTE im Projektmanagement?

Schreibe eine Antwort

Viele Projektmanager kennen das Problem: Die Ressourcen sind begrenzt, aber die Aufgaben wachsen. Wie soll man da den Überblick behalten? Eine Methode, die immer häufiger angewendet wird, ist FTE. In diesem Artikel erfahren Sie, worum es sich handelt und wie es Ihnen helfen kann, Ihre Ressourcen besser zu verwalten.

FTE – Was ist das?

Die Abkürzung FTE steht für Full-Time Employee und bedeutet auf Deutsch Vollzeitangestellter. Es gibt verschiedene Definitionen von Vollzeit, aber in der Regel wird es als Arbeit definiert, die 40 Stunden pro Woche umfasst. Die Abkürzung FTE kann auch verwendet werden, um die Anzahl der Vollzeitäquivalente (VTE) anzugeben, die aufgrund von Teilzeitarbeit oder Arbeit mit unterschiedlichen Stundenplänen erforderlich sind, um eine Aufgabe zu erledigen.

FTE ist ein wichtiger Begriff in der Personalwirtschaft – kurz gesagt, er hilft dabei, die geleistete Arbeit von Mitarbeitern zu quantifizieren. Auf diese Weise können Unternehmen etwa feststellen, wie viele Vollzeitstellen sie anhand der tatsächlich geleisteten Arbeitszeit besetzen müssen. Aber FTE ist auch nützliches Instrument zur Planung von Projekten oder zur Ermittlung des Personalschlüssels in verschiedenen Abteilungen.

Wie wird FTE berechnet?

Der Wert berechnet sich ganz einfach: Man nimmt die Anzahl der geleisteten Arbeitsstunden und dividiert diese durch die Anzahl der Wochenstunden einer Vollzeitkraft. Daraus ergibt sich ein bestimmter Wert, der die Stellenbesetzung angibt. 40 Wochenarbeitsstunden entsprechen damit 1 FTE, während 20 Stunden 0,5 FTE entsprechen.

Aber auch in Teams lässt sich der Bedarf an FTE ermitteln:

Das Team umfasst 4 Mitarbeiter, die jeweils folgende Arbeit leisten: 25, 50, 40 und 45 Stunden. Alle Mitarbeiter zusammen haben 160 Stunden gearbeitet, dieser Wert wird durch 40 geteilt, da diese der Arbeit einer Vollzeitkraft entsprechen. Trotz Teilzeit oder Mehrarbeit kommt das Unternehmen auf einen Bedarf von 4 FTE.

Sehen wir uns das Ganze nun auf Projektebene an. Hier erkennt man, dass die tatsächliche Anzahl der arbeitenden Personen, von den benötigten FTE abweichen kann:

Wenn Sie beispielsweise herausfinden, dass für Ihr Projekt 40 Stunden pro Woche erforderlich sind und Sie 10 Personen zur Verfügung haben, entspricht dies einer FTE von 4 (40 Stunden / 10 Personen = 4). Dies bedeutet, dass jede Person in Ihrem Team im Durchschnitt 4 Stunden pro Woche an dem Projekt arbeitet.

Die FTE ist ein unglaublich nützliches Instrument, um die Ressourcennutzung im Projektmanagement vorauszuplanen und zu überwachen.

Welche Vorteile hat FTE im Projektmanagement?

FTE ist ein also ein Indikator dafür, wie viele Personen einem Projekt zur Verfügung stehen. Dabei ist es unerheblich, ob die Personen tatsächlich Vollzeit an dem Projekt arbeiten oder nur Teilzeit. Der Wert gibt an, wie viel Zeit insgesamt in ein Projekt investiert wird.

Des Weiteren bringt es folgende Vorteile mit sich:

Ressourcenplanung: Mit der FTE-Methode wird die Auslastung von Ressourcen genau gemessen. So kann man den Bedarf eines Projektes bestimmen und Über- oder Unterlastung der Mitarbeiter vermeiden.
Einfaches Konzept: Der Wert und die Berechnung sind sehr einfach zu verstehen und zu erklären. Dies ist sehr wichtig, da es Ihnen ermöglicht, alle Beteiligten des Projektes (Kunden, Sponsor, Stakeholder etc.) auf einem gleichen Niveau zu informieren.
Projektkosten ermitteln: Dafür wird der Stundensatz einer Person mit der Anzahl der FTE multipliziert. So kann schnell errechnet werden, wie viel Geld insgesamt in ein Projekt investiert werden muss.
Mitarbeitereinsatz planen: Mitarbeiter sind häufig in mehrere Projekte eingeplant. Durch den Wert ist erkennbar, wie viel Aufwand in welchem Projekt steckt. In Systemen lassen sich außerdem schneller freie Ressourcen von Mitarbeitern finden.
Projektsteuerung: Durch den FTE können Projektmanager zudem überwachen, ob sich das Projekt im zeitlich geplanten Rahmen bewegt.

FTE ist ein beliebtes Mittel im Projektmanagement, weil es die Ressourcen und Aufwände transparent darstellt. Jeder kann sich so ein besseres Bild des Gesamtprojekts machen – kein Wunder, dass es so beliebt ist!

Lizenzende verpasst? Lizenzmanagement in IT-Projekten

Schreibe eine Antwort

Ohne lizenzierte Software läuft in den IT-Projekten gar nichts! Aber Achtung: Die Lizenzbedingungen sind komplex und leicht zu missachten. Daher ist ein effektives Lizenzmanagement unerlässlich, um Kosten zu sparen und das Projekt nicht zu gefährden.

In diesem Artikel beschreiben wir die wichtigsten Aspekte des Lizenzmanagements in IT-Projekten.

Warum Lizenzmanagement wichtig ist

Wenn ein Unternehmen ein IT-Projekt plant, gibt es viele verschiedene Faktoren, die dieses berücksichtigen muss. Einer dieser Faktoren ist das Lizenzmanagement. Oft wird dieser Aspekt vernachlässigt oder erst in einem späten Stadium des Projekts berücksichtigt. Dies kann jedoch zu erheblichen Kosten und Problemen führen.

Daher ist es wichtig, das Lizenzmanagement von Anfang an richtig zu planen und im Auge zu behalten. Das Unternehmen sollte genau festlegen, welche Softwarelizenzen diese benötigen und wie lange sie gültig sein sollten. Auch die Kosten sollten im Vorfeld genau berechnet werden. So lassen sich böse Überraschungen am Ende des Projekts vermeiden.

Wenn man ein Lizenzende in einem IT-Projekt verpasst, hat das meistens Folgen. Dabei ist es egal, ob die Lizenz für ein bestimmtes Softwareprodukt oder für eine ganze Softwareplattform abläuft. Folgende Punkte sollten Sie unbedingt beachten, damit keine bösen Überraschungen auftreten:

Prüfen Sie regelmäßig, ob Ihre Lizenzen noch aktuell sind. Dafür gibt es in der Regel entsprechende Funktionen in den Lizenzmanagement-Tools.
Achten Sie darauf, dass Sie bei der Vergabe von Lizenzen an externe Mitarbeiter oder Dienstleister auch die Kündigungsfristen einhalten.
Informieren Sie sich rechtzeitig über die Kosten für die Verlängerung Ihrer Lizenzen. Hier lohnt es sich oft, frühzeitig zu handeln und die Preise zu verhandeln.
Stellen Sie sicher, dass Sie immer genügend Reservelizenzen parat haben. Gerade bei größeren Projekten kann es sonst zu Engpässen kommen.

Arten von Lizenzen

Lizenzen sind wie eine Eintrittskarte für Software. Man bezahlt und darf die Software für eine bestimmte Zeit oder unbegrenzt nutzen – so wie man im Kino einen Film anschauen kann. Es gibt auch kostenlose Lizenzen, bei denen man die Software allerdings nicht ändern oder weiterverbreiten darf.

Die häufigsten sind:

Nutzungsrechts- oder Benutzungslizenzen
Dauerlizenzen
Abo-Lizenzen
Open Source-Lizenzen
Freeware-Lizenzen

Jede Lizenzart muss auf unterschiedliche Art und Weise verwaltet werden und bringt unterschiedliche Nutzungsdauer und Verwaltungsaufwand mit sich.

Wie man Lizenzen verwaltet

Wenn Sie die Lizenzbedingungen nicht einhalten, können Sie teure Strafgebühren zahlen müssen. Um sicherzustellen, dass Sie alle Lizenzbestimmungen einhalten, sollten Sie einige Tipps befolgen.

Ein effektives Lizenzmanagement in IT-Projekten erfordert diverse Vorkehrungen und Maßnahmen:

1. Die erste Maßnahme ist die Erstellung einer Liste aller benötigten Lizenzen sowie deren Preise und Laufzeiten. Diese Liste sollte regelmäßig aktualisiert werden, damit alle relevanten Informationen jederzeit verfügbar sind.

2. Lesen Sie alle Lizenzverträge genau, um sicherzustellen, dass Sie alle Bedingungen einhalten.

3. Stellen Sie sicher, dass alle notwendigen Zahlungen rechtzeitig getätigt werden, um Kündigung oder Verlust der Lizenz zu vermeiden.

4. Es sollten regelmäßige Überprüfungen stattfinden, um sicherzustellen, dass die Software immer noch den Anforderungen entspricht und keine neueren Versionen verfügbar sind.

Sie suchen eine einfache Möglichkeit, die Lizenzsituation Ihrer IT-Projekte zu überwachen und zu verwalten? Dann ist das passende Lizenzmanagement Tool genau das Richtige für Sie! Es hilft Ihnen nicht nur bei der Vermeidung von potenziellen Lizenzüberschreitungen, sondern erfasst auch alle relevanten Informationen rund um Ihre Lizenzen.

So haben Sie immer den Überblick und können verschiedene Szenarien testen, um herauszufinden, welche Kombination von Lizenzen am besten für Ihr Unternehmen geeignet ist.

Fazit: Lizenzmanagement ist essenziell für den Erfolg von IT-Projekten

Lizenzmanagement ist ein wesentlicher Bestandteil des Projektmanagements in der IT-Branche. Durch die Einhaltung von Lizenzbestimmungen können Projekte erfolgreich umgesetzt und abgeschlossen werden.

Damit ist gutes Lizenzmanagement entscheidend für den Erfolg von IT-Projekten. Durch die strikte Einhaltung von Lizenzbestimmungen können auch unvorhergesehene Kosten und Verzögerungen vermieden werden. Zudem sichern rechtzeitig erworbene Lizenzen die Qualität und den Umfang der gelieferten Software.

Vernachlässigte Empirie: Eine Gefahr im Projektmanagement

Schreibe eine Antwort

Wann ist ein Projekt erfolgreich? Die meisten würden jetzt sagen: „Wenn es zufriedenstellend abgeschlossen ist“. Dabei gibt es noch viel mehr Kriterien, die auf jeden Fall beachtet und vor allem betrachtet werden sollten. Eins davon stellt die Empirie im Projektmanagement dar. Was genau das bedeutet und warum es ein entscheidender Faktor für den Projekterfolg ist, erfahren Sie in diesem Artikel.

Was ist Empirie?

Der Begriff Empirie findet sich meist im wissenschaftlichen Kontext und in der Forschung. Dazu zuerst eine kurze Erklärung zu dem Begriff:

Die Empirie befasst sich mit den Erfahrungen, die Menschen machen. Dabei können diese Erfahrungen sowohl bewusst als auch unbewusst sein. In der Regel wird unter Empirie jedoch das Wissen verstanden, das Menschen durch Beobachtung und Experimente gewinnen. Dieses Wissen basiert also auf Fakten und nicht auf Theorien.

Kurz gesagt: Empirie stellt das Wissen aus den Erfahrungen dar. Schauen wir uns mal an, was das mit Projekten zu tun hat.

Was hat die Empirie mit Projektmanagement zu tun?

In Projekten finden die unterschiedlichsten Methoden und Vorgehen Anwendung. Projektleiter greifen auf diverse Mittel zurück, um den Projekterfolg sicherzustellen und das Voranschreiten der Aufgaben und der Entwicklung zu überprüfen.

Aber wie erfolgreich sind die erwählten Maßnahmen und wie gehen die Teams damit um? Hier kommt die Empirie ins Spiel. Sie hilft dabei, einen aktuellen Status quo des Projektes und des Vorgehens zu erheben. Der Blick wird weggelenkt von der Theorie: Wie sollte es laufen? Und wird hingelenkt zu dem tatsächlichen Arbeiten des Teams.

Im Grunde geht die empirische Erhebung in 3 Schritten vonstatten:

Durch transparente Prozesse sind Vernetzungen und Voranschreiten absolut ersichtlich. Nur wenn ein Projekt transparent gesteuert wird, sind Analysen und die richtigen Rückschlüsse möglich.
Es erfolgt eine Analyse des aktuellen Zustandes. Laufen Prozesse und arbeiten reibungslos ab oder gibt es Hindernisse? Erzielen getroffene Maßnahmen den gewünschten Effekt?
Anschließend lassen sich Anpassungen an den Prozessen vornehmen oder andere Maßnahmen zum Steuern ergreifen.

Der wichtigste Punkt ist und bleibt jedoch: Es geht um tatsächlich Erlebtes der Mitarbeiter und des Projektteams, nicht um rein theoretische Gedankenkonstrukte. Warum ist das so wichtig?

Vernachlässigte Empirie: Eine Gefahr!

Die Empirie nimmt eine so wichtige Stellung ein, da es nun mal Menschen sind, die in Projekten arbeiten. Es lässt sich nicht immer im Vorfeld vorhersagen, wie eine Maßnahme wirken wird. Jedes Team hat eine eigene Gruppendynamik, die Sie nicht unterschätzen sollten.

Bedenken Sie auch: Immer mehr Projekte werden in agiler Form durchgeführt. Diese funktionieren aber nicht ohne Empirie! Wie sollen Projektanpassungen vorgenommen werden, wenn der Ist-Zustand gar nicht erhoben wird und wie können Prozesse verbessert werden, wenn man gar nicht weiß, dass diese Optimierungsbedarf haben?

Die Mitarbeiter sind der Schlüssel. Die persönliche Erfahrung eines jeden Mitarbeiters und damit des Teams trägt den Projekterfolg auf den Schultern. Nur durch die notwendige Transparenz und die Erhebung sind Anpassungen und schnelle Adaptionen möglich, was wiederum viel über die Produktivität eines Teams aussagt.

Ohne Empirie im Projektmanagement lebt das Projekt also vollständig in der Theorie oder arbeitet auf Grundlage von Annahmen. Eine Projektsteuerung aufgrund der tatsächlichen Lage wird unmöglich. Und vor allem: Ein echtes, agiles Arbeiten wird verhindert.

Eine weitere Gefahr: Es kann zum Stillstand im Projekt kommen oder – und das konnte im klassischen Projektmanagement oft beobachtet werden – es kommt zu einem anderen Projektergebnis als erwartet.

Fazit

Empirie ist ein Schlüsselelement von agilen Projekten. Aber auch so können Projekte davon profitieren, Wissen aus den Erfahrungen der Mitarbeiter zu generieren. Denn diese Erfahrungen ermöglichen erst eine Weiterentwicklung. Vernachlässigt man den Punkt der Empirie und verbleibt rein im theoretischen Projektmanagement, reagieren auf neue und veränderte Anforderungen? Fehlanzeige!

Scrum ausweiten – was ist SAFe?

Schreibe eine Antwort

Wenn ein Projekt immer größer wird und das Team stetig wächst, kann Scrum an seine Grenzen stoßen. Wie kann es dann weitergehen? Es gibt verschiedene Skalierungsframeworks, mit dessen Hilfe Sie Scrum ausweiten können. Zu den beliebten Frameworks dieser Art gehört SAFe. Wie die Skalierung damit funktioniert, erfahren Sie in diesem Artikel.

Warum sollte Scrum skaliert werden?

Scrum definiert eine feste Teamgröße. Nun ist es aber immer häufiger erforderlich, dass mehrere Teams zusammenarbeiten, da ein Projekt sonst nicht bewältigt werden kann oder sich richtig lange ziehen würde.

Skalierungsframeworks bieten den Vorteil, dass Teams agil weiterarbeiten können, das Unternehmen aber neue Strukturen zur Verfügung gestellt bekommt, um das Ganze zu steuern.

Es gibt verschiedene Skalierungsframeworks, die Scrum skalieren können. Scrum of Scrums haben wir Ihnen bereits vorgestellt, ein weiteres beliebtes Framework ist SAFe.

SAFe – ein neues Mindset

Das Skalierungsframework SAFe kommt in mehreren Versionen einher, je nach Projektgröße und Ziel greift eine andere Version. Dabei betrachtet es drei Ebenen: das Team, das Portfolio und das Programm. Was bedeutet das? Das Framework wird nicht einfach nur auf die Arbeit des Teams angewendet, sondern eben auf alle drei Betrachtungsebenen.

Eine der Versionen wird als Full Solution bezeichnet. In dieser Version eignet es sich, das gesamte Unternehmen umzustrukturieren. Anders als bei anderen Frameworks liegt der Fokus nicht auf den Inkrementen, die ein Team produziert, sondern auch in der Weiterentwicklung des Unternehmens. Die Ideensammlung, Reflektion und die Wertschöpfung bekommen ausreichend Raum.

Das klingt nach einem neuen Mindset? Auch darum geht es. Schließlich bekommt Führung hier eine neue Bedeutung und Prozesse und die Zusammenarbeit wird transparent. So viel Umstrukturierung und Arbeit kann auf Unternehmen abschreckend wirken. Auch dafür hat SAFe eine Lösung! Das Framework kommt mit einer Roadmap um die Ecke, die genau beschreibt, was in welchem Prozessschritt zu tun ist, damit die Implementierung stufenweise funktioniert. Und vor allem, damit alle verstehen, was vor sich geht und ein Teil der Transformation sein können.

Doch was hat es mit Scrum zu tun? Um das zu erklären, schauen wir uns an, wie SAFe funktioniert.

Ein Projekt mit SAFe auf die Schienen bringen

Was haben Projekte mit Zügen zu tun? In SAFe werden mehrere Scrum Teams zu einem übergeordneten Team zusammengefasst: dem Agile Release Train (ART). Jedes Scrum Team in diesem Zug beziehungsweise in diesem ART hat weiterhin jeweils einen Scrum Master und einen Product Owner, zusätzlich kommen drei neue Rollen hinzu:

Der Release Train Engineer (RTE): Er coacht die Art-Teams, ist als dienende Führungskraft zur Stelle und übernimmt die Stakeholderkommunikation.
Product Manager: Er kümmert sich um das Anforderungsmanagement, erstellt Produktdefinition und treibt das Design Thinking voran.
System Architect/Engineer: Er definiert sowohl eine architektonische als auch technische Lösung, die für das Projekt passend ist und kommuniziert/vernetzt diese in den Teams.

In einem ART können zwischen 50 und 125 Personen zusammenarbeiten, wenn es mehr sind, können die Scrum Teams auf mehrere ARTs aufgeteilt werden, die wiederum gemeinsam einen Solution Train bilden. In SAFe gibt es eine feste Länge für Product Increments (PI) und ein PI-Planning, bei welchem alle anwesend sind.

Vor- und Nachteile von Safe

Das Agile Framework bringt einige Vor- und Nachteile mit sich. Die Top 3 sind:

Vorteile:

Roadmap erleichtert die Implementierung
Ist auf das gesamte Unternehmen anwendbar
Die Möglichkeit zur Weiterentwicklung dadurch, dass Teams auch Organisationsziele behandeln können

Nachteile:

Ein guter Plan ist erforderlich und neue Prozesse müssen geschaffen werden
Das Top-Down Vorgehen steht in Konflikt zu den agilen Prinzipien
Komplexität erfordert Schulungen der Beteiligten

Fazit

Wenn Scrum an seine Grenzen kommt, steht SAFe schon parat. Je nach Personenanzahl lassen sich unterschiedlich viele Scrum Teams in ARTs zusammenfassen. So ist der Agilität auch in großen Projekten weiterhin kaum eine Grenze gesetzt.

Agiles Projektmanagement – warum nicht alles SMART sein kann

Schreibe eine Antwort

Ziele gehören zu einem Projekt wie das Amen in die Kirche. Es heißt immer wieder, dass Ziele SMART formuliert sein müssen. Ist das wirklich so? Was versteckt sich hinter der SMART-Formel und warum kann es von Vorteil sein, eher auf agile Methoden zu setzen? Genau diese Fragen werden wir nun behandeln.

SMART – was bedeutet das?

Um Ziele im klassischen Projektmanagement zu formulieren, setzen Projektleiter häufig auf die Smartformel. SMART ist ein Akronym und steht für:

S – Spezifisch

M – Messbar

A – Akzeptiert, Attraktiv

R – Realistisch

T – Terminiert

Das bedeutet, dass ein Ziel alle oben genannten Kriterien erfüllen muss. Entworfen wurde diese Formel, um Ziele zu konkretisieren und zu verhindern, dass diese schwammig formuliert sind.

Das ist logisch und natürlich sinnvoll, aber eben nicht überall. Was ist, wenn das Ziel eines Projektes offen ist? Es kommt außerdem oft genug vor, dass neue Anforderungen die Projektleitung dazu zwingen, die Richtung zu ändern.

Und hier zeigen sich auch die Nachteile der SMART-Formel. Die mangelnde Flexibilität.

Zudem sind realistische und akzeptierte Ziele nicht immer auch ambitioniert. Wer nach den Sternen greifen möchte, kommt mit der Formel also nicht an sein Ziel. Die smarte Formulierung lässt zudem kaum Spielraum für Auslegungen, sollten sich die Umstände verändern.

Ein weiteres Problem: Die Projektleitung formuliert die Ziele zu Projektbeginn und das Projekt nimmt seinen Lauf durch diverse Phasen hindurch. Ein Eingreifen oder Verändern der Phasen ist im klassischen Projektmanagement nicht möglich. Bei Zielverfehlung geht man zurück in die Phase der Zielsetzung und beginnt die Phasen von Neuem.

Vorteile vom agilen Projektmanagement

Agile Methoden sind im Vergleich zum klassischen Projektmanagement eher jung. Sie befriedigen aber das Bedürfnis, das durch die Digitalisierung und die damit veränderten Anforderungen entsteht.

Was sind diese Bedürfnisse? Ein Prozess und Ziele, die eine stetige Weiterentwicklung zulassen und die Möglichkeit, in den Prozess einzugreifen, um Änderung schnell herbeizuführen.

Im klassischen Projektmanagement scheitern viele Projekte daran, dass sie ihr Ziele nach mehreren Jahren nicht erreichen konnten. Die Ursachen dafür sind vielfältig. So können die Bedingungen zum Zeitpunkt der Zielsetzung anders gewesen, neue Anforderungen könnten erst im Laufe des Projektes dazugekommen sein. Smarte Ziele sind darauf nicht vorbereitet, während agile Methoden durchaus darauf reagieren können.

Wie schafft das agile Projektmanagement den Spagat zwischen Zielen und neuen Anforderungen? Zum einen hat es mit einer anderen Art der Zielsetzung zu tun. So setzt sich das Team kein spezifisches Ziel, welches sie beispielsweise in zwei Jahren erreichen wollen. Es betrachtet stattdessen kleinere Zeitperioden. Meistens gibt es zudem eine Rückkopplungsschleife, in welcher das Team den Ist-Zustand prüft und bei neuen Anforderungen die Zielsetzung anpasst.

Agiles Projektmanagement hebt sich also vom klassischen Projektmanagement durch seine Dynamik ab. Dabei gibt es verschiedene agile Methoden, die dem Team unterschiedlich viel Spielraum lassen.

Methoden im agilen Projektmanagement

Im agilen Projektmanagement bezeichnet man agile Methoden auch als Frameworks. Dieser Begriff ist durchaus treffend, denn sie geben Rahmenbedingungen und Leitlinien vor, die einen Rahmen für das Projektmanagement bilden.

Zu den beliebtesten Frameworks gehören Scrum und Kanban, die sich durch folgende Merkmale auszeichnen:

Scrum:

gibt eine klare Struktur mit festgelegten Terminen, Teamgröße, Rollen und Instrumenten vor
Grundgedanke: ein Produkt ist niemals fertig, als Ergebnis produziert das Team Inkremente
das Team arbeitet in Sprints, die nicht länger als vier Wochen dauern
das Team setzt sich Sprintziele, neue Anforderungen können nach Sprintende hinzugefügt werden

Kanban:

eine Methode zur Visualisierung von Aufgaben (offen, in Arbeit, erledigt) auf einem Board
das Team kann jederzeit neue Anforderungen hinzufügen
Rollen, Termine und Dauer sind nicht festgelegt
Hauptelement: Work-in-progress Limit, welcher festlegt, wie viele Aufgaben gleichzeitig in Bearbeitung sein dürfen

Fazit

Sowohl das klassische Projektmanagement mit seinen smarten Zielen, als auch das dynamische agile Projektmanagement haben natürlich ihre Daseinsberechtigung. Beide haben jedoch unterschiedliche Ansprüche und Ziele. Die verschiedenen agilen Methoden bieten aber zahlreiche Alternativen zum klassischen, smarten Vorgehen.