Florian Mücke im Netz

An agile journey and beyond

Larmans Gesetze zum Organisationsverhalten

(Übersetzung des Artikels von Craig Larman)

Nach jahrzehntelanger Beobachtung und Organisationsberatung, sind hier Larmans Gesetze zum Organisationsverhalten. Es sind allerdings eher Beobachtungen als Gesetze, die man befolgen sollte 😉

1. Organisationen sind implizit darauf optimiert, den Status Quo der mittleren und ersten Führungsebene sowie “ Spezialisten“-Positionen & Machtstrukturen nicht zu verändern.

2. Als logische Folge von (1) wird jede Veränderungsinitiative darauf reduziert, die neue Terminologie so umzudefinieren oder zu überladen, dass sie im Grunde dasselbe bedeutet wie der Status quo.

3. Als logische Folge von (1) wird jede Veränderungsinitiative als „puristisch“, „theoretisch“, „revolutionär“, „religiös“ oder „braucht eine pragmatische Anpassung an örtliche Gegebenheiten“ abgetan – was davon ablenkt, die Schwächen und den Status quo der Manager/Spezialisten anzugehen.

4. Als logische Folge von (1) werden, falls einige Manager oder Einzelspezialisten nach der Anpassung des Changes doch versetzt werden, diese zu „Coaches/Trainern“ für die Veränderung, was häufig (2) und (3) verstärkt.

5. (in großen etablierten Organisationen) folgt die Kultur der Struktur. Und in kleinen, jungen Organisationen folgt die Struktur der Kultur.

Ausführung:

Eine ausführlichere Beschreibung lautet: In großen, bereits etablierten Gruppen folgt die Kultur/das Verhalten/die Denkweise den Veränderungen im Organisationssystem und -design und wird von diesen beeinflusst. Das bedeutet, dass man in großen, etablierten Organisationen mit der Änderung des Organisationssystems (Gruppen, Teams, Rollen und Verantwortlichkeiten, Hierarchien, Karrierepfade, Richtlinien, Bewertungs- und Vergütungssysteme usw.) beginnen muss, wenn man die Kultur wirklich ändern will, weil sie sich sonst nicht wirklich ändert. Anders ausgedrückt: Das Organisationssystem hat einen starken Einfluss auf die Denkweise und das Verhalten.

Dies hat auch der Verfechter des systemischen Denkens John Seddon beobachtet: „Der Versuch, die Kultur einer Organisation zu ändern, ist Torheit, er misslingt immer. Das Verhalten der Menschen (die Kultur) ist ein Produkt des Systems; wenn man das System ändert, ändert sich das Verhalten der Menschen.

Diese Beobachtung gilt für große etablierte Organisationen; in kleinen Start-ups ist es dagegen umgekehrt: Die Struktur folgt dort ihrer Kultur. Das heißt, das (wahrscheinlich einfache und informelle) Organisationsdesign spiegelt die Denkweise und Kultur der kleinen Anzahl von Mitgliedern im Startup wider. Wenn die Organisation wächst, kehrt sich das in der Regel irgendwann in Kultur folgt Struktur um.

Und „Kultur folgt Struktur“ (in großen Gruppen) ist der Grund, warum reine „Mindset“-Ansätze wie organisatorisches Lernen in großen Gruppen nicht wirklich haftend oder wirkungsvoll sind, und warum Frameworks wie Scrum (die zu Beginn einen starken Fokus auf strukturelle Veränderungen haben) dazu neigen, die Kultur schneller zu beeinflussen – wenn die Konsequenzen der strukturellen Veränderungen von Scrum tatsächlich umgesetzt werden.

Lernen ist nur was für Kinder!

Von Erwachsenen wird in unserer Gesellschaft erwartet, dass sie Dinge auf anhieb verstehen und in der Lage sind, komplizierte, ja sogar komplexe Sachverhalte nach einer kurzen Erklärung zu verstehen.

Man wird auf Trainings geschickt, im Glauben, man könne Können einimpfen.

Dabei vergessen wir leider oft, dass auch Erwachsen nur Menschen sind und echtes Lernen mit Erfahrung verbunden ist. Diese Erfahrung kommt aber nicht durch stilles Reindenken und nacktes Wissen, sondern erst durch Kontakt mit anderen Individuen und praktisches Erproben in der Umwelt. Es wird erwartet, dass alles auf Anhieb verstanden wird und einmaliger Informationsinput ausreicht.

Weiterlesen

DIY: Lernturm fürs Kind bauen

150103-Lernturm-01

Damit der oder die kleine endlich auch mal in der Küche helfen kann und deswegen nicht mehr quengelnd durch die Küche rennt, gibt es einen speziellen Hochstuhl auf dem das Kind sicher stehen kann. Einen solchen kann man sich ganz leicht selbst bauen – vorausgesetzt man ist nicht völlig ungeschickt.

Nach etwas Betteln seitens meiner Frau, habe ich mich dann doch bereit erklärt einen solchen Stuhl zu bauen – und Spaß hat es auch noch gemacht 🙂

Die sieben Arbeitsschritte habe ich hier zusammengeschrieben… Weiterlesen

Was spricht gegen Exceptions in C++?

Obwohl es Exceptions im C++ Standard schon etliche Jahre gibt, werden diese in größeren Projekten oft nicht eingesetzt. Im folgenden Artikel möchte ich das Für und Wider erörtern und mit gängigen Vorurteilen aufräumen.

try {
    funktion();
   ...
} catch (const std::invalid_argument& e) {
    std::cerr << "Falsches Argument:"  << e.what() << std::endl;
} catch (const std::range_error& e) {
    std::cerr << "Ungültiger Bereich:" << e.what() << std::endl;
} catch (...) {
    std::cerr << "Sonstiger Fehler" << std::endl;
}

Gängige Vorurteile

  1. Die Behandlung von Ausnahmen ist codeintensiver (mehr Schreibarbeit)
    Falsch. Ein sinnvolles try/catch braucht ist sogar weniger Code als ein sinnvolles if/else if/elsefür alle möglichen Fehlercodes. Fehlercodes werden aber oft nicht vollständig überprüft oder gar ganz weggelassen, was der Qualität des Codes nicht gerade zuträglich ist. Exceptions dagegen zwingen zu einer durchdachten Fehlerbehandlung.
  2. Exceptions machen den Code langsam
    Falsch. Wenn Exceptions richtig eingesetzt werden, sollten sie für Ausnahmen im Programmablauf verwendet werden. Die Ausführungsgeschwindigkeit des "Gut"-Pfades (in dem keine Ausnahmen geworfen werden) leidet nicht darunter. Wenn also die Exception die Ausnahme und nicht die Regel ist, hat man nichts zu befürchten. Weiterlesen

Dateiversion auslesen

#pragma comment( lib, "version" )
struct FileVersion
{
	DWORD dwLeftMost;
	DWORD dwSecondLeft;
	DWORD dwSecondRight;
	DWORD dwRightMost;
	bool IsLower( const FileVersion& ver )
	{
		return dwLeftMost < ver.dwLeftMost ? true :
			dwSecondLeft < ver.dwSecondLeft ? true :
			dwSecondRight < ver.dwSecondRight ? true :
			dwRightMost < ver.dwRightMost ? true : false;
	}
};

static void GetFileVersion( const CString& fileNameWithPath, FileVersion& fileVersion )
{
	DWORD dwDummy;
	DWORD dwFVISize = GetFileVersionInfoSize( fileNameWithPath , &dwDummy );
	LPBYTE lpVersionInfo = new BYTE[dwFVISize];
	::GetFileVersionInfo( fileNameWithPath , 0 , dwFVISize , lpVersionInfo );
	UINT uLen;
	VS_FIXEDFILEINFO* lpFfi;
	::VerQueryValue( lpVersionInfo , _T("\\") , (LPVOID *)&lpFfi , &uLen );
	DWORD dwFileVersionMS = lpFfi->dwFileVersionMS;
	DWORD dwFileVersionLS = lpFfi->dwFileVersionLS;
	delete[] lpVersionInfo;
	fileVersion.dwLeftMost = HIWORD(dwFileVersionMS);
	fileVersion.dwSecondLeft = LOWORD(dwFileVersionMS);
	fileVersion.dwSecondRight = HIWORD(dwFileVersionLS);
	fileVersion.dwRightMost = LOWORD(dwFileVersionLS);
}

Stativtest: Bilora gegen Cullmann gegen Vanguard

Da ich mein jetziges Stativ damals einfach für den Camcorder gekauft hatte und es jetzt meinen wachsenden Ansprüchen für die Fotographie nicht mehr genügt, habe ich mir (nach Lektüre diverser Tests) zwei potentielle Nachfolger mit Kugelköpfen zum Vergleich bestellt:

„P ≠ NP“ gelöst

Es sieht so aus, als wäre eines der wichtigsten noch offenen Rätsel der Informatik gelöst worden. Vinay Deolalikar von den HP Reseach Labs scheint jetzt endlich bewiesen zu haben, dass die Komplexitätsklasse P ungleich der Komplexitätsklase NP ist. Die Lösung dieses Millennium-Problems ist mit 1 Million Dollar dotiert und behandelt im wesentlichen die Fragestellung „Wenn es für ein Problem einen einfachen Weg gibt, eine Lösung zu verifizieren, gibt es dann auch eine einfache Lösung?“. Mit P ≠ NP ist jetzt endlich der Beweis für die bislang allgemeine Annahme, dass dies nicht so ist, erbracht.

Ein Beispiel für ein solches Problem ist das Problem des Handlungsreisenden (Traveling Salesman Problem), bei dem es darum geht, eine bestimmte Anzahl von Städten so zu besuchen, dass ein möglichst kurzer Weg zurückgelegt wird, jedoch keine Stadt mehrmals besucht wird.

Leider wurde der Beweis relativ kurze Zeit später widerlegt.

Weiterführende Links:

« Ältere Beiträge