Holokratie als Organisationsform

Erstellt am 16 Mai 2017
von Schreibe einen Kommentar
This entry is part 3 of 3 in the series Agile Organisationsentwicklung

Holokratie ist nach dem altgriechischen holos für ‚vollständig‘, ‚ganz‘ sowie kratia – wie bei der Organisationsform Soziokratie – für ‚regieren‘, ‚Macht‘, ‚Stärke‘ abgeleitet [1]. Aus bekannten Problemen und Herausforderungen der klassischen Organisationslehre – siehe Blogreihe 1 – entwickelte Brian J. Robertson die Holokratie [2], basierend auf den Inhalten der Soziokratie. Zur besseren Vermarktung der Holokratie gründete Robertson sein eigenes Unternehmen, welches Organisationen durch eine Art Verfassung [3] bei der Implementierung dieser Organisationsform unterstützt.

Die Holokratie basiert auf den drei Hauptelementen: organisatorische Struktur, Governance und operatives Geschäft. Zusammen mit den drei genannten Hauptelementen und der Verfassung gibt Robertson ein Setup vor und verkauft hierfür Lizenzen, um eine Organisation nach den Werten und Prinzipien der Holokratie aufzustellen [2].

Um das Prinzip der Holokratie zu verstehen, müssen wir zunächst ein Verständnis für Unternehmensstrukturen schaffen.

Anforderungen langfristig dokumentieren, im agilen Umfeld

Erstellt am 10 Mai 2017
von 1 Komment

 

In unserem CARS-Training diskutieren wir viele Themen, unter anderem: wie dokumentiert man Anforderungen langfristig, im agilen Umfeld?

Diese Frage ist für uns deshalb so wichtig, weil der Wert der Dokumentation mit der Zeit zunimmt.

Handlungsoptionen für den Umgang mit komplexer Dynamik

Erstellt am 3 Mai 2017
von Schreibe einen Kommentar

Unsere Welt ist komplex und schnelle Veränderungen bedrohen uns. Allerorten spricht man von Industrie-Revolution und Agilität. So fand ich in Prof. Peter Kruse wieder einmal einen hervorragenden Autor, der sehr anschaulich diese Schlagworte und Aussagen in einen praxistauglichen Kontext stellt und so die Transformation in seinen eigenen Alltag zu einem Synapsen-Feuerwerk werden lässt.
Quelle: http://mtux.lima-city.de/GC2VDCZ/mandelbrot.jpg

Anforderungen strukturieren – 2. Techniken

Erstellt am 26 April 2017
von Schreibe einen Kommentar
This entry is part 2 of 2 in the series Anforderungen strukturieren

Im letzten Blog „Anforderungen  strukturieren – 1. Kriterien“ haben wir vorgestellt, welche Kriterien für die Strukturierung von Anforderungen relevant sind. Heute stellen wir Ihnen im 2. Teil dieser Blog-Serie ein paar Ideen und Konzepte vor, die die Anforderungsstrukturierung ermöglichen. Wir wollen die Frage beantworten: „Welche technischen Möglichkeiten gibt es, um Anforderungen zu strukturieren?“

Das Ende des Requirements Engineerings wie wir es kennen

Erstellt am 1 April 2017
von 3 Kommentare

Nun ist es passiert ! Nach jahrhundertelangem Bemühen der Menschheit, den Weg von der Idee in die Realisierung zu verkürzen, ist der Durchbruch geschafft. Was haben sich Informatiker Gedanken über die semantische Lücke gemacht, was hat man Sprachen erfunden, um es für verschiedenste Fachdomänen praktischer zu machen, sich Hilfssysteme zu bauen. Es war immer die Hoffnung, dass wenn das Problem formuliert ist, die Lösung damit auf dem Tisch liegt.

Da hat man z.B. COBOL in die Welt gesetzt, um Wirtschaftlern  eine direkte Möglichkeit zu geben, einer Maschine sagen zu können, was man möchte. Da wurde SQL erfunden, so dass jedermann auf der Straße mal eben eine Datenbank abfragen könnte. Es ließen sich tausende weitere Beispiele und Versprechungen aufzählen, die nach einem ähnlichen Muster gestrickt sind.

Anforderungen strukturieren – 1. Kriterien

Erstellt am 30 März 2017
von Schreibe einen Kommentar
This entry is part 1 of 2 in the series Anforderungen strukturieren

Die Teilnehmer unseres Trainingsangebotes bringen häufig ein konkretes Problem aus ihrem beruflichen Umfeld mit. Viele wollen wissen, wie man gute Anforderungen schreibt, andere wollen einfach die Grundlagen umfassend kennenlernen, die bei dem Umgang mit Anforderungen notwendig sind, sei es im klassischen oder agilen Umfeld.

Eine der häufigsten Fragen lautet: „Ich habe da eine Menge Anforderungen von verschiedenen Seiten in meinem Projekt. Wie strukturiere ich am besten diese heterogenen Anforderungen?

Es ist Samstagabend…

Erstellt am 14 März 2017
von 1 Komment
This entry is part 3 of 3 in the series Anforderung und Implementierung

…nach dem Abendessen, meine Mutter und mein Bruder sind bei uns zu Besuch. Meine Tochter ist auch Zuhause und wir haben uns entschieden, Karten zu spielen. „Schwimmen“ , so heißt unser Lieblingsspiel und unsere Gäste kennen es noch nicht, so müssen wir das Spiel nun erläutern. Der Kampf „ums Erklären dürfen“ geht los. Unser Töchterchen studiert Technische Redaktion und ich bin Berater. Das Töchterchen gewinnt und darf das Spiel erklären, während ich das Geschehen beobachte.

Inwieweit kann man das Erlernen eines Kartenspiels mit der Qualifizierung von Menschen in der Formulierung von Anforderungen in einem Entwicklungsunternehmen vergleichen und was wir hierbei voneinander lernen können, folgt jetzt:

Anforderungsdokumentation ist nicht generell sinnvoll!

Erstellt am 28 Februar 2017
von Schreibe einen Kommentar

Vor etwa zwei Jahren habe ich mit einem Kunden die Fragestellung erörtert, inwieweit sich User Stories in einer Entwicklung im regulierten Umfeld einsetzen lassen. Es herrschte die Meinung, User Stories seien gänzlich ungeeignet um im regulierten Umfeld eingesetzt zu werden, da sie nicht detailliert genug seien, um als geforderte Anforderungsdokumentation zu dienen.

Wie cool ist Requirements Engineering denn?

Erstellt am 15 Februar 2017
von Schreibe einen Kommentar

…wahrscheinlich nicht sooooo cool, zumindest bei meiner Tochter, denn die verbindet „Anforderungen“ eher mit Aussagen wie „Räum den Tisch ab!“ und „Räum dein Zimmer auf!“.

Doch welchen Stellenwert hat Requirements Engineering und der Umgang mit Anforderungen heutzutage im Umfeld der Software-, Produkt- und Dienstleistungsentwicklung?

Seit vielen Jahren geben wir Kurse für Requirements Engineering und Management. Vor einigen Jahren kamen dort interessierte Systemingenieure zu uns, die merkten, dass die Spezifikation „ihres“ Systems immer komplexer wird. Sie wollten wissen,