Dot voting – eine Methode zum Abstimmen, wenn richtig gemacht

Dot voting

Dot voting - eine Methode zum Abstimmen, wenn richtig gemacht

Vorgehensweise: Der Scrum Master schreibt die Auswahl der Optionen auf das Flipchart. Dann verteilt er rote Klebepunkte an die Team Mitglieder. Jetzt werden die Team Mitglieder aufgefordert an die Option auf dem Flipchart den Klebepunkt anzubringen, für die sie eine Stimme abgeben möchten. Es können auch mehrere Klebepunkte angebracht werden, wenn der Scrum Master dies zu Beginn der Abstimmung festgelegt hat.

Klingt einfach und ist es auch bei der Durchführung, birgt aber auch einige Gefahren:

  1. dadurch, dass offen abgestimmt wird, besteht die Gefahr der gegenseitigen Beeinflussung der Teilnehmer. Der eine oder andere Teilnehmer ist unentschlossen und klebt dann - bewußt oder unbewußt - den Punkt an die Stelle, an der eine andere Person bereits einen Punkt geklebt hat.
  2. Es kann auch vorkommen, dass der eine abwartet, was die anderen machen und sich dann nach der Mehrheit richtet.
  3. Denkbar ist auch, dass die Abstimmung manipuliert wird, dadurch dass einer der Teilnehmer Klebepunkte eines andern wieder wegnimmt. Das lässt sich eigentlich nur durch ständiges Beobachten vermeiden. Ansonsten ist nicht klar, wessen Punkt weggenommen wurde und auch nicht, wer es getan hat. Das Ergebnis ist aber dann manipuliert.

Der offenen Abstimmung kann man insofern entgegenwirken, indem man die Optionen auf dem Flipchart durchnummeriert und die Teilnehmer auffordert die Nummer der Option auf den Klebepunkt zu schreiben bevor der Klebepunkt geklebt wird. Dann wird geklebt, wenn alle entschieden haben und ihre Klebepunkte bereits mit der Nummer der Option versehen haben.

Agiles Softwareentwicklungsprojekt nach Festpreis – geht das?

Festpreis

Agiles Softwareentwicklungsprojekt nach Festpreis - geht das?

Das werde ich oft bei meinen Beratungsgesprächen gefragt.

Ich halte dann dagegen, wie es denn bei Wasserfall-Vorgehensmodell aussieht? Besteht dort nicht die Gefahr, dass man im Lastenheft etwas fordert und im Pflichtenheft zugesichert bekommt, das sich dann während der Projektlaufzeit als obsolet herausstellt? Dann muss aber dafür bezahlt werden, für eine Feature oder sogar mehr, das nicht genutzt wird. Aber der Scope dessen, was entwickelt werden soll, wurde frühzeitig festgelegt. Drastisch ausgedrückt ist das 'waste' den wir vermeiden möchten.

Es ist also der Scope, der sich durchaus bei einem Softwareentwicklungsprojekt verändern kann und es wäre schön, wenn es genau dazu eine vertragliche Regelung geben würde.

Diesen Ansatz habe ich selbst bei einem Scrum-Projekt gefahren. Ich habe immer auf zwei Sprints im Voraus budgetiert (Kosten für das Scrum-Team). Dagegen standen dann eine Reihe von User Stories, die als wichtig erachtet wurden und die wir dann auch liefern konnten. So näherten wir uns dem Release-Termin, den wir halten konnten und zu dem wir mit der Funktionalität in Betrieb gingen, die gebraucht wurde ... aber auch nicht mehr. Diese Vorgehensweise war sehr fein-granular, sowohl aus der Sicht der Budgetierung als auch aus der Sicht der Anforderungen. Wir - die PO und ich als Scrum Master - hatten sie aber erst gelernt, als wir mitten im Projekt steckten. Ich behaupte, wenn wir begonnen hätten zu Beginn alles zu planen und erst danach begonnen hätten, zu liefern, wären wir nicht rechtzeitig fertig geworden.

Kanban – ein Pull-System als agiles Framework mit WIP Limits

Kanban

Kanban ist ein agiles Framework, das auf dem Pull-Prinzip aufbaut.

Die Arbeit an den User Stories wird visualisiert durch das Kanban-Board. Das Kanban-Board ist in Spalten unterteilt, die verschiedene Status beschreiben, die von den User Stories durchlaufen werden.

Wichtig ist jetzt, dass in jeder Spalte nur eine gewisse Anzahl von User Stories stehen dürfen. Diese Grenze wird als WIP limit bezeichnet - das Work In Progress limit.

Das Pull-Prinzip funktioniert so, dass eine User Story nur dann in eine Spalte gezogen werden darf, wenn diese Grenze für diese Spalte unterschritten wird.

Agile Softwareentwicklung – Grundlagen, Werte und Prinzipien

Agile Softwareentwicklung - Grundlagen, Werte und Prinzipien

Agile Softwareentwicklung - Grundlagen, Werte und Prinzipien

Grundlagen

Als Begründung für die Entstehung der agilen Software-Entwicklung wird meistens das Wasserfallmodel oder V-Modell angeführt. In den 90er-Jahren war das Wasserfallmodel vorherrschend. Die erste formale Beschreibung des Wasserfallmodells wird Winston W. Royce zugeschrieben, obwohl dieser in seinem 1970 erschienenen Artikel den Namen „Wasserfall“ nicht verwendete. Das Wasserfallmodel wurde aus dem Bau- und Produktionsprozess auf die Software-Entwicklung adaptiert, weil es noch keinen formalen Softwareentwicklungsprozess gab [1].

Durch die CASE-Tools - computer-aided Software Engineering-Tools - wurde versucht, den Softwareentwicklungsprozess möglichst zu automatisieren, was nicht gelang. Allerdings gibt es diese Tools heute noch für spezielle Aufgabenstellungen.

Auch diese Tools änderten am eigentlichen Problem wenig. Das Problem war, dass viele Softwareentwicklungsprojekte scheiterten.

Kent Beck war einer der ersten, der mit seinem Buch 'Extreme Programming' 1999 ein agiles Vorgehen bei der Softwareentwicklung beschrieb. Kent Beck war mit anderen dann auch dabei, als sich 2001 in Utah 17 Software-Entwickler trafen um über den Stand der Software-Entwicklung zu sprechen. Ein Ergebnis dieses Treffens ist die Postulierung des 'Agilen Manifestes' - 'The agile manifesto'. Das agile Manifest findet man in [2].

Es haben sich verschiedene Frameworks etabliert auf der Basis der agilen Werte und Prinzipien. Die meisten existierten bereits zum Zeitpunkt, als das agile Manifest formuliert wurde. Die zwei Wichtigsten sind Scrum und XP (eXtreme Programming), weil ein Großteil aller agilen(!) Softwareentwicklungsprojekte mit einem der beiden oder einer Kombination aus beiden durchgeführt werden.

Scrum wurde Mitte der Neunziger Jahre von Ken Schwaber und Jeff Sutherland vorgestellt. Im Jahr 2000 stellte Kent Beck eXtreme Programming in seinem Buch 'Extreme Programming – das Manifest' vor.

Werte

Die agilen Werte, die sich aus den Grundlagen ableiteten sind:

  • Mut
  • Respekt
  • Fokussierung
  • Einfachheit
  • Kommunikation
  • Offenheit
  • Selbstverpflichtung (commitment)
  • Rückmeldung (feedback)

Die konkrete Ausgestaltung der Werte in Handlungen findet man bei den beschriebenen Frameworks umgesetzt:

Prinzipien (sicher nicht vollständig)

  • Verantwortung
  • Selbstorganisation
  • Reflexion
  • Kontinuierliche Verbesserung
  • Bevollmächtigt sein
  • Verschwendung vermeiden

[1]: Wasserfallmodel

[2]: Agile Softwareentwicklung

Spotify engineering culture – eine Implementierung der agilen Vorgehensweise

Spotify engineering culture

Die 'Spotify engineering culture' entstand bei der Firma Spotify, einem Musik-Streamingdienst ansässig in Stockholm, Schweden.

Ursprünglich arbeitet Spotify mit Scrum, erkannte aber, nachdem mehrere Scrum Teams entstanden waren, dass sich einige Standards, die bei Scrum verfolgt wurden, sich gegenseitig im Weg standen. Diese Scrum Standards wurden daraufhin als optional betrachtet. Man sagte, dass Regeln gut sind zu starten, aber gebrochen werden sollten, wenn nötig. Für Spotify waren die agilen Werte wichtiger als die Umsetzung durch Scrum und Prinzipien wichtiger als Praktiken.

Von diesem Zeitpunkt an wurden auch Begriffe angepasst, z.B. wurde der Scrum Master in Agile Coach und das Scrum Team in Squad umbenannt.

Henrik Kniberg war und ist der Consultant bei Spotify, der maßgeblich an dieser Entwicklung beteiligt war.

Siehe auch 'Spotify engineering culture' Teil 1 und Teil 2

Chapter – Kompetenzen bei der Spotify® engineering culture

Chapter

Chapter ist ein Begriff der 'Spotify engineering culture'.

Als Chapter wird eine Kompetenz-Area bezeichnet, z.B. 'quality assistance', 'agile coaching' oder 'Web development'.

Squads fokussieren auf 'product delivery' und 'quality'.

Ein Chapter umfasst Mitglieder aus den einzelnen Squads. Der 'chapter lead' ist der Linien-Manager des Mitglieds. Ein Mitglied kann von einem Squad in ein anderes Squad wechseln. Wenn dies passiert, dann bleibt der Linien-Manager derselbe.

Squad – Team bei der Spotify® engineering culture

Squad

Gemäß der 'Spotify engineering culture' wird der Begriff Scrum Team wurden durch Squad ersetzt.

Spotify startete ursprünglich mit Scrum. Durch das Wachstum der Teams erkannte man aber, dass die agilen Werte wichtiger waren als deren Umsetzung durch Scrum. Man wollte eine eigene Kultur haben, die auf agilen Prinzipien aufbaute. Daraus entstand die 'Spotify engineering culture'.

Ein Squad besteht aus nicht mehr als acht Personen. Ein Squad ist eine autonome funktionsübergreifende und selbst-organisierte Einheit.

Jedes Squad ist verantwortlich von Anfang bis Ende für das, was sie tun – vom Design über Deployment usw. Ein Squad hat sowohl langfristige Ziele, im Hinblick auf das Unternehmen als Ganzes, als auch interne Ziele, die sich auf das Projekt beziehen, an dem gerade gearbeitet wird.

Autonom zu sein bedeutet in diesem Fall, dass ein Squad frei ist zu entscheiden

  1. was gebaut werden soll
  2. wie es gebaut werden soll und
  3. wie man währenddessen zusammenarbeitet.

Die Autonomie muss in Einklang gebracht werden müssen mit den langfristigen Zielen, den internen Zielen, der Produktstrategie und anderen kurzfristigen Zielen. Es findet jedes Quartal eine Überprüfung statt.

Siehe auch 'Spotify engineering culture (part 1)' und 'Spotify engineering culture (part 2)'