Glossar Agilität

kurz - knapp - klar

Dietmar Prudix

• Verlag: Books on Demand
• Jahr: 2017
• ISBN drucken: 9783744854993
• eBook-ISBN: 9783744865692
• Auflage: 1
• Thema: Business
• Thema: Management

Im Projektmanagement ist das Thema Agilität aktuell ein Hype. Jeder arbeitet gefühlt agil. Der Umfang des Themas ist jedoch sehr umfangreich: von einzelnen Methoden bis hin zum System-verständnis und einem neuen Managementverständnis. Bei dieser Vielfältigkeit ist es sinnvoll und hoffentlich hilfreich, mit einem Glossar zu arbeiten, das versucht, alle Einzelaspekte zu beschreiben. Nur so wird der Umfang des Themas Agilität.

S

SAFe-Framework

Das Scaled Agile Framework ist ein komplexes Modell um agile Entwicklung über viele Teams abzustimmen und zu integrieren. Es betrachtet die vier Ebenen Team, Programm, Value Stream und Portfolio.

Sarbanes-Oxley Act

Gesetz, mit dem die Corporate Governance von Unternehmen verbessert werden soll, die an US-Börsen notiert sind; zum Teil abgekürzt als SOX.

Scaling Model

Für die Organisation größerer Einheiten und mehrerer Teams gibt es spezielle Frameworks wie das Scaled Agile Framework oder Large Scaled Scrum. Diese Frameworks definieren weitere Rollen, die in großen agilen Entwicklungsorganisationen benötigt werden.

Schlüsselbereich

(engl.: key domain) nach den Eigenschaften Service, Kommunikation, Personal und Positionierung geordnete Menge von Erfolgsfaktoren.

Schlüsselfaktor

(engl.: key factor) Kombination Erfolgsfaktor/ Wettbewerbsfaktor, die für den Beitrag der IT zum Unternehmenserfolg von besonderer Bedeutung ist.

Schlüsselfertiges System

(engl.: turnkey system) System, das Anwendern mit allen Komponenten aus einer Hand (z. B. von einem ASP) produktiv nutzbar zur Verfügung gestellt wird.

Schrittmachertechnologie

Im Entwicklungsstadium befindliche Technologie, von der ein erhebliches Veränderungspotenzial erwartet wird.

Schulung

(engl.: training) Mittel und Maßnahmen, deren Zweck es ist, die Qualifikation der Mitarbeiter so zu gestalten, dass sie die ihnen zugeordneten Aufgaben erfüllen können.

Schutzbedarf

(engl.: security requirements) angestrebtes oder erforderliches Sicherheitsniveau einer Informationsinfrastruktur.

Schwäche

(engl.: weakness) negative Abweichung der Eigenschaft eines Systems von einem definierten Standard (z. B. Sollzustand). Synonym: Schwachstelle.

Schwachstelle

(engl.: vunerability, weakness) Umstand, der das Eintreten gefährdender Ereignisse begünstigen oder deren negative Folgen verstärken kann.

Scrum

Scrum ist ein Begriff aus dem Rugby-Sport und bezeichnet dort das so genannte «Angeordnete Gedränge». Als Technik wurde es ursprünglich im Softwarebereich ent-wickelt, ist aber davon unabhängig. Scrum wird in der Zwischenzeit in vielen anderen Domänen eingesetzt und ist eine Umsetzung von Lean Development für das Projektmanagement. In der Softwareentwicklung ist es eine Methode zur Komplexitätsreduktion. Der Ansatz von Scrum ist empirisch, inkrementell und iterativ. Er beruht auf der Erfahrung, dass die meisten modernen Entwicklungsprojekte zu komplex sind, um einen voll-umfänglichen Plan erstellen zu können. Die Unklarheit sowohl von Anforderungen als auch Lösungsansätzen lässt sich bei komplexen Aufgabenbeseitigen, indem iterativ und inkrementell Zwischenergebnisse geschaffen werden.

Scrum Master

Er ist vor allem Moderator, Coach und Dienstleister für das Projektteam. Er sorgt dafür, dass Hindernisse und Störfaktoren im Umfeld des Teams beseitigt werden. Er beschafft die notwendigen Ressourcen und ist Ansprechpartner für Außenstehende. Er hilft dem Team bei methodischen Problemen und stellt sicher, dass die Scrum-Regeln eingehalten werden. Der Scrum Master arbeitet eng mit dem Product Owner zusammen.

Der Scrum Master ist eine Rolle in Scrum, die sich allein um den Prozess kümmern soll. Der Scrum Master organisiert die Zeremonien und führt sie teilweise durch, hilft dem Team in der täglichen Arbeit durch das Beseitigen von Impediments (Hindernissen) und unterstützt es bei der kontinuierlichen Reflektion und Verbesserung der eigenen Arbeitsweisen.

Die für den Scrum-Prozess verantwortliche Person. Der ScrumMaster sorgt für die korrekte Implementation und den maximalen Nutzen des Prozesses.

Anmerkungen:

Der ScrumMaster sollte kein Vorgesetzter der Team Members sein.

Der ScrumMaster sollte keine Doppelfunktion als Team Member oder Product Owner haben. Interessenkonflikte wären die unvermeidliche Folge.

Der ScrumMaster ist kein Projektleiter im herkömmlichen Sinn, sondern ein Vermittler und Unterstützer (Facilitator), dessen Hauptaufgabe darin besteht, Hindernisse (Impediments) für das Team aus dem Weg zu räumen.

Scrum of Scrums

Wenn in einem Scrum-Projekt die ideale Team-Größe von sieben Personen wesentlich überschritten wird, wird ein skalierter Scrum-Prozess benötigt. Das ist relativ einfach möglich, indem mehrere Teams gebildet werden, die sich in der Folge untereinander mit möglichst wenig Overhead koordinieren und abgleichen müssen. Jedes Team funktioniert zunächst eigenständig. Aus jedem Team wird ein Mitglied in den Scrum of Scrums entsendet. Die Team-Botschafter — es müssen nicht immer dieselben sein — berichten dort aus ihrem Teilprojekt und gleichen sich auf diese Weise bzgl. Übergeordneter Themen ab. Sie nehmen die Informationen mit zurück in ihre jeweiligen Teams, um sie dort nach Bedarf zu verbreiten.

Anmerkung: Der Scrum of Scrums kann auch mehrstufig angelegt sein, wenn es sehr viele Teams gibt. Dies wurde bereits häufig in der Praxis mit bis zu mehreren hundert Team-Mitgliedern umgesetzt und zeigt, wie gut Scrum als Prozess mit sehr wenig Overhead skaliert.

Scrum Sprint

Ein Sprint ist ein kurzes Entwicklungsintervall, das sich wiederholen kann, an dessen Ende jeweils eine fertige Funktionalität vorliegt. Sprints umfassen also machbare Kundenanforderungen, die in eine entsprechend überschaubare Spezifikation der technischen Anforderungen münden und auf Quick-wins zielen.

Scrum Team

Das Scrum Framework kennt drei Rollen mit jeweils verschiedenen Verantwortungen:

Product Owner, Entwicklungsteam und Scrum Master.

Die Gesamtheit dieser Rollen wird als Scrum Team bezeichnet. Ein Scrum Team tritt mit vielen weiteren Rollen in der Organisation in Kontakt. Diese Rollen werden als Stakeholder (Beteiligte) bezeichnet.

Selbstorganisation

Selbstorganisation steht als Begriff als Gegensatz zu Fremdorganisation oder Fremdbestimmung. Das Verhalten eines Systems wird zu einem großen Teil nicht durch äußere, sondern durch innere Ereignisse angestoßen und zwar in einer Weise, die im System zu einer zunehmenden Ordnung führt. Diese innere Dynamik ist meist nicht hierarchisch gesteuert, sondern geschieht über das System verteilt. In der Physik ist Laserlicht als Beispiel einer selbstorganisierten Ordnung bekannt. Der Kreisverkehr ist ein alltägliches Beispiel eines verteilten, selbstorganisierten Prozesses. Dieser läuft oft hoch geordnet ab, obwohl kein übergeordneter Akteur (z. B. eine Ampel oder ein Verkehrspolizist) das Gesamtgeschehen dirigiert. Die Ordnung in selbstorganisierten Systemen bewegt sich teils «am Rande des Chaos» – ihre Ordnungsmuster sind nicht vorsehbar, aber dennoch nicht zufällig. Auf Organisationen bezogen, stellt sich die Frage, was jeweils das passende Verhältnis von hierarchischer Einflussnahme versus selbstorganisiertem Handeln ist. Gelingt Selbstorganisation, kann sie mit Effizienzgewinnen und Synergieeffekten verbunden sein. (→ Prigogine; Kauffman; Haken)

Selbstreferenz

Selbstreferenz bedeutet, dass etwas auf sich selbst Bezug nimmt. Das Verhalten eines Systems erklärt sich nicht nur durch Außenbedingungen, sondern in Bezug auf aktuelle oder vergangene Zustände des Systems. Ein Diskussionsbeitrag in einem Gespräch ist nicht nur eine Reaktion auf die Außenwelt, sondern er bezieht sich meist auch auf eine zuvor geäußerte Aussage, an die der Beitragende gedanklich anknüpft. Ob, wann und in welcher Weise angeknüpft wird, ist meist schwer vorhersehbar. Selbstreferenz ist eines der grundlegendsten Prinzipien von menschlichem Verhalten und von Zusammenarbeit. (→ Maturana und Varela; von Foerster)

Selbstzeugnis

(engl.: personal testimonial) Literarisches Zeugnis eigenen Tuns, Denkens, Erlebens oder Ähnliches, eine Teilmenge der Ego-Dokumente.

Self Organisation

Selbstorganisation ist einer der augenfälligsten Aspekte, wenn man Scrum-Teams beobachtet. Das Team als Ganzes ist einer der drei Manager in Scrum (neben dem ScrumMaster und dem Product Owner). Es organisiert und verwaltet sich selbst (Self-Management), trifft eigenständig und ohne Anweisungen eines Vorgesetzten Entscheidungen. Es ist einzig dem Scrum-Prozess und seinen Regeln verpflichtet. D. h. beispielsweise, dass es, kulinarisch ausgedrückt, Sashimi bzw. Carpaccio abliefern muss – darunter verstehen wir in jedem Sprint ein Increment of Potentially Shippable Functionality, auf dessen Umfang und Inhalt sich das Team im Sprint Planning Meeting selbst verpflichtet hat, und zwar im Einklang mit den Priotitäten im Product Backlog.

Anmerkung: Selbstorganisation passiert nicht automatisch, weil die meisten Menschen auf das Command-and-Control-Verhaltensmuster konditioniert sind. Erst wenn die Team Members die Erfahrung machen, dass sie z.B. im Daily Scrum einander und nicht dem ScrumMaster oder dem Product Owner berichten, dass sie auch von keinem Außenstehenden unterbrochen werden, beginnt allmählich das Verständnis für die Eigenverantwortung und somit der Prozess der Selbstorganisation. Und dann – werden Teams wirklich effektiv!

Sequenziell

(engl.: sequential) Aufeinander folgend; der Reihe nach.

Service Desk

Struktureinheit, der operative Aufgaben des Störungsmanagements zugeordnet sind. Synonyme: Helpdesk, User-Help-Desk, Benutzerservice-Zentrum.

Serviceebene

(engl.: service level) Qualitätsniveau einer Dienstleistung (Dienstgüte).

Serviceebenenmanagement

(engl.: service level management) Führungsaufgaben, die mit der Festlegung von Serviceebenen und der Vereinbarung von Serviceebenen zwischen Dienstleistungsnehmer und Dienstleistungsgeber im Zusammenhang stehen.

S...

Inhaltsverzeichnis

• Inhaltsverzeichnis
• Vorwort
• Kapitel A
• Kapitel B
• Kapitel C
• Kapitel D
• Kapitel E
• Kapitel F
• Kapitel G
• Kapitel H
• Kapitel I
• Kapitel J
• Kapitel K
• Kapitel L
• Kapitel M
• Kapitel N
• Kapitel O
• Kapitel P
• Kapitel Q
• Kapitel R
• Kapitel S
• Kapitel T
• Kapitel U
• Kapitel V
• Kapitel W
• Kapitel Z
• Impressum