Schlagwort: Scrum

noch mehr Meeting

noch mehr Meeting

Der vorangegangene Beitrag schloss mit einem Hinweis auf Beratungs- und Entscheidungspunkte. In diesen beiden Begriffen ist ein wichtiger Ansatz enthalten, den ich gerne verwende. In Besprechungen und Zusammenkünften, die keine strikte Form wie z.B. das daily scrum1 haben, lässt sich die Agenda leichter definieren und einhalten, wenn jeder Punkt explizit typisiert wird. Mögliche Typen sind:

  • I – wie Information
  • B – wie Beratung
  • E – wie Entscheidung

Information – wird in der Regel von einem Teilnehmer mitgeteilt, die anderen hören zu. Nachfragen zum Verständnis sind erlaubt, Diskussionen sollten vermieden werden. Wenn sich Diskussionsbedarf abzeichnet sollte dies vertagt werden und in einen neuen Beratungspunkt münden. Im Protokoll kann die Information nochmals wiederholt und ggf. durch die Antworten auf die verständnisfragen ergänzt werden.

Beratung – hier darf diskutiert werden. Meinungen werden ausgetauscht, Meinungen verändern sich. Im Protokoll sollten die geäußerten Meinungen und Ansichten dokumentiert werden.

Entscheidung – der Diskussionsstand wird nochmals zusammengefasst und eine Entscheidung getroffen. Im Protokoll wird die Entscheidung und nichts anderes dokumentiert.

Was bringt diese Typisierung der Tagesordnungspunkte. Sie erhöht die Verbindlichkeit. Ohne die explizite Unterscheidung der Punkte gehen Information, Diskussion und Beratung leicht ineinander über. Im Protokoll stehen dann viele unterschiedliche Aspekte ohne dass klar ist, welche Punkte nur diskutiert und welche wirklich entschieden wurden. Manchmal beruft sich jeder auf einen anderen Halbsatz im Protokoll, irgendwie haben dann alle recht und alle machen weiter wie sie denken.

Lassen sich mit einer Typisierung alle Besprechungen effizient gestalten? Nein, nicht immer – das liegt daran, dass wir Menschen sind und auch im ernsten Business Alltag nach Austausch suchen. Bei der Vorbereitung von Terminen sollte man das immer im Hinterkopf behalten und auch in der Planung der Besprechung berücksichtigen (Zeitstruktur, Pausen, Smalltalk).

Es spricht übrigens nichts dagegen die Typisierung auch mit einem Augenzwinkern zu erweitern. Ich selbst hatte auch in wichtigen Besprechungen als ersten Tagesordnungspunkt schon Nachbesprechungen von Fußballspielen stehen.

Zu guter letzt ein Bild wie ein Protokoll einer derartigen Besprechung aussehen könnte und ein Word-Dokument als Protokollvorlage.

  1. Auch wenn man Scrum macht, heißt das noch nicht, dass man keine normalen Besprechungen mehr benötigt. Spätestens dann wenn der Scrum-Master sich um die Beseitigung von impediments kümmert wird er auch Besprechungen mit team-fremden Teilnehmern benötigen. []
Eine Pionier-Scrum-Konferenz

Eine Pionier-Scrum-Konferenz

Pionier passt in doppelter Hinsicht. Pionierbasis veranstaltet eine Scrum-Konferenz in einem neuen Format: Dezentral und rund um die Uhr.

8 Referenten werden zu wichtigen Themen rund um Scrum interviewt. Die Themenauswahl klingt spannend und ist an der Praxis orientiert:

– Skalierung von SCRUM für große Projekte
– Agiles Produktmanagement mit Scrum
– Agile Softwareentwicklung mit verteilten Teams
– Klassisches versus agiles Projektmanagement
– Agiles Projektmanagement mit ZCOPE
– Spannungsfeld Architektur und Agilität
– Agile Engineering Techniken in SCRUM
– Agilität und Kultur

Die Interviews stehen auf einer speziellen Plattform online zur Verfügung. Mittels dieser Plattform stellen die Teilnehmer Fragen an die Referenten, diese werden beantwortet und diskutiert. Interviews, Fragen und Antworten stehen danach weiter zur Verfügung. Ich halte das für eine sehr gute Idee. Mir fallen die wichtigsten Fragen meistens auf dem Heimweg von einer Konferenz ein, das kann bei dieser Scrum-Konferenz nicht mehr passieren.

Die agile Essenz

Die agile Essenz

Projekte, die agile Vorgehensweisen einsetzen, sind erfolgreicher. Anderseits gibt es einen noch ausgeprägteren Zusammenhang zwischen Teamqualität und Projekterfolg. Meine These lautet: Es kommt darauf an, dass sich während des Projektes ein echtes Team bildet. Wenn agile Methoden eingesetzt werden, gelingt dies ein wenig leichter. Diese These möchte ich im Folgenden erläutern.

Wie sieht der gemeinsame Kern agiler Vorgehensweisen aus?

  • Es wird akzeptiert, dass zu Beginn nur ein Teil der Anforderungen definiert ist.
  • Es besteht permanenter und enger Kontakt zu denen,
    die das Arbeitsergebnis geliefert bekommen.
  • Es wird in wiederkehrenden Intervallen gearbeitet.
  • Am Ende jeden Intervalls wird ein verwendbares Zwischenergebnis fertig gestellt.
  • Jedes Arbeitsintervall wird ausgewertet.
    Es werden Konsequenzen für das nächste formuliert und auch gezogen.
  • Die produktive Arbeit wird von einem Team geleistet, das selbstorganisiert arbeiten darf.

Aus der Formulierung der Merkmale wird schon deutlich, dass diese Arbeitsweise nicht nur für Software-Entwicklung sondern für viele verschiedene Projektarten möglich sein wird. Wie die Merkmale in der Praxis konkret umgesetzt werden (z.B. mittels Scrum) ist letztendlich egal. Genauer betrachtet lässt sich diese Arbeitsweise auch mit “klassischem Projektmanagement” zuzüglich ordentlichem Changemanagement, kooperativer Führung und transparenter Kommunikation verwirklichen. Agilität ist ohnehin eher als Geisteshaltung denn als Prozessbeschreibung zu verstehen.1

Nehmen wir an, dass in einem Projekt wie oben beschrieben gearbeitet wird. Das Team arbeitet und liefert nach einer gewissen Zeit ein (hoffentlich) verwertbares Zwischenergebnis ab. Sollte im ersten Intervall nichts Brauchbares fertig werden, muss eben nach den Gründen gesucht werden um dann im zweiten Anlauf erfolgreicher zu sein. Egal ob im ersten oder zweiten Anlauf, das Team hat sehr früh ein Erfolgserlebnis. Konkrete (Erfolgs)-Erlebnisse und Erfahrungen beschleunigen die teaminternen Klärungsprozesse wie Rollenklärung oder die üblichen Machtkämpfe erheblich. Ein simples Beispiel: Ein Kollege bezeichnet sich selbst als Spezialist für ein bestimmtes Thema. Stimmt das? Können sich Team und Projekt wirklich darauf verlassen? Nach der Lieferung des ersten Zwischenergebnisses hat sich das bestätigt (oder eben nicht). Die Bestätigung der Fähigkeiten, der Verlässlichkeit, das Erproben der Zusammenarbeit, das Wachsen des aufkeimenden Vertrauen – all dies erfolgt schneller wenn mit greifbaren Zwischenschritten gearbeitet wird.2 Im negativen Fall wird ebenfalls schneller klar, dass der Kollege vielleicht nur eine große Klappe hatte und er mit einer anderen Aufgabenstellung mehr für das Projekt tun kann. Wichtige Grundvoraussetzungen für eine erfolgreiche Teamentwicklung wie die Klärung der Fragen “Wer gehört dazu?” bzw. “Wie sieht die gemeinsame Aufgabe aus?” werden bei einer solchen Vorgehensweise quasi im Vorbeigehen erledigt.

Wer agil arbeitet, stellt gewissermaßen ganz nebenbei gute Rahmenbedingungen für eine konstruktive Teamentwicklung bereit.

Eine konstruktive Teamentwicklung innerhalb des Projektes ist m.E. DER Erfolgsfaktor für Projekte. Scrum stellt hierfür bessere Rahmenbedingungen als das Wasserfallmodell bereit. Dennoch gibt es keinen Königsweg. Auch in Wasserfall-Projekten lässt sich ein Teil des agilen Gedankenguts (siehe obige Merkmale) leben. Ein gutes Team schafft fast alles, eine zerstrittene Projektgruppe kann jedes Projekt scheitern lassen.

  1. Insofern kann ich Stimmen, die Scrum als alten Wein in neuen Schläuchen bezeichnen durchaus verstehen. []
  2. Ein Meilenstein in einem Projektplan ist nicht zwingend ein greifbarer Zwischenschritt. Die Softwareentwicklung hat es hier relativ leicht. Hier entspricht dies einem lauffähigen Release. In anderen Projekten muss die Definition der Meilensteine genau bedacht werden. []
Selbstorganisation und Menschenbild

Selbstorganisation und Menschenbild

Dass die Selbstorganisation nicht vom Himmel fällt sondern erarbeitet werden muss, hatte ich schon geschrieben. Arbeit alleine reicht aber nicht, auch die Einstellung muss stimmen. Der Weg zu selbstorganisierten Teams – egal ob man Scrum oder eine andere teamorientierte Arbeitsweise einführt – gelingt nur mit der passenden Einstellung bzw. einen bestimmten Menschenbild.

In einer Diskussion über Führungsstile sagte eine Führungskraft vor kurzem folgenden Satz zu mir: “Das geht alles auch mit Druck”. In gewisser Weise hat er recht, eine Arbeitsgruppe oder Abteilung lässt sich natürlich mit präzisen Handlungsanweisungen, Druck und Drohungen führen. Ob das in Projekten oder bei Entwicklungsarbeiten in denen es auf Kreativität und neue Lösungen ankommt sinnvoll ist, möchte ich jetzt nicht diskutieren. Wichtiger scheint mir die grundlegende Haltung, das Menschenbild, das zu einem solchen Führungsverständnis führt, zu sein. Provozierend formuliert steckt da folgendes Menschenbild dahinter:

  • Mitarbeiter wollen nicht arbeiten und müssen permanent angetrieben werden.
  • Mitarbeiter sind dümmer als die Führungskraft. Deshalb muss die Führungskraft mit konkreten Anweisungen den Arbeitsfortschritt absichern.

Nicht minder provozierend formuliert lautet die Antithese:

  • Mitarbeiter wissen besser als die Führungskraft wie die Probleme zu lösen sind.
  • Mitarbeiter sind grundsätzlich interessiert sich für die Firma und ihre Ziele zu engagieren und wollen lieber sinnvoll arbeiten als faulenzen.

Die Wirklichkeit ist ein wenig komplizierter aber irgendwo zwischen diesen Polen bewegt sich die Einstellung gegenüber den Mitarbeitern. So verlockend Produktivitätssteigerungen durch Selbstorganisation auch klingen mögen, mit einem Menschenbild wie dem zuerst formulierten wird es nie ein echtes selbstorganisiertes Team geben. Nur wer daran glaubt, dass das Team im besten Wissen und Gewissen eine Lösung erarbeitet und dann bereit ist diese Lösung mit zu tragen wird die Früchte der Selbstorganisation ernten können. Dieses Mittragen der Lösung – auch wenn sie im ersten Moment nicht der eigenen Präferenz entspricht – ist die Antwort auf die implizite Vertrauensfrage, die das Team regelmäßig stellt. Wer “Selbstorganisation” nutzen will (z.B. bei einer Einführung von Scrum) muss bereit sein “mitzutragen” auch dann, wenn die Entscheidung des Teams den Eigeninteressen der Führungskraft zuwider läuft. Es gibt nichts Schlimmeres als mit Worten “ja” und mit Taten “nein” zu sagen.

Der Advocatus diaboli fragt nun wie mit politischen Entscheidungen umgegangen werden soll, die ggf. den Entscheidungen des Teams entgegen laufen (könnten). Hier gibt es nur eine Antwort: So früh und so ehrlich wie möglich alle Rahmenbedingungen an das Team kommunizieren. Wenn beispielsweise innerhalb eines Projektes eine Software angeschafft werden muss und auf höherer Ebene hierzu bereits eine Vorentscheidung gefallen ist, muss das Team davon wissen, bevor sie sich selbst mit der Auswahl befassen. Hört sich trivial an ist es aber nicht, ich habe es schon zu oft erlebt, dass wohl überlegte Lösungen mit dem Hinweis auf bereits vorgefasste Entscheidungen wieder gekippt wurden. Kein Team arbeitet gerne für den Mülleimer und eine solche Entscheidung wird von den Mitarbeitern nahezu zwangsläufig als Missachtung Ihrer Arbeit(szeit) betrachtet.

Ohne offene und ehrliche Kommunikation und einer gehörigen Portion Vertrauen in die Mitarbeiter kann Selbstorganisation nicht wachsen.

© pentaeder 2019 / 2020