Kommentare 0

Was ich aus organisatorischer VerĂ€nderung ĂŒber mich sich selbst lernen kann

Wir nehmen so viele EindrĂŒcke auf, dass wir diese Flut filtern mĂŒssen. Wir nehmen ZustĂ€nde oder Verhalten um uns herum selektiv wahr. Manche dieser Beobachtungen fĂŒhren dazu, dass wir auch den Antrieb verspĂŒren das beobachtete Verhalten der Menschen oder ZustĂ€nde der Organisation zu verĂ€ndern. In diesen FĂ€llen wurden „Trigger“ in uns ausgelöst. Der Trigger ist ein Ausdruck fĂŒr einen WidersprĂŒche zwischen Beobachtung und unseren eigenen Überzeugungen. Überzeugungen und GlaubenssĂ€tze sind mĂŒssen uns nicht immer selbst bewusst sein. An diesen WidersprĂŒchen zwischen Überzeugung und Beobachtung reiben wir uns aber so, dass wir das Beobachtete verĂ€ndern wollen, um diesen inneren Konflikt aufzulösen. Wir wollen die Organisation verĂ€ndern, um die zwei Sichten anzugleichen und den Konflikt damit fĂŒr uns abzubauen.
Im Meeting beschĂ€ftigen sich 3 Teilnehmer mit dem PC und der Organisator des Meetings hat die Agenda nicht vorbereitet. Wenn Sie nun den Grundsatz haben: „Mehrere Personen zusammen sollten aus Respekt zueinander die Zeit effektiv nutzen.“; fĂ€llt Ihnen das auf. Je nachdem wie wichtig Ihnen dieser Grundsatz ist, wollen Sie dieses Verhalten dann evtl. auch verĂ€ndern.

Interventionen betreffen nun andere Menschen. In den FĂ€llen, wo diese Interventionen im Widerspruch zu GlaubenssĂ€tzen dieser betroffenen Personen stehen, ergibt sich Widerstand. In diesen FĂ€llen ist die Arbeit an den Überzeugungen wichtig. Alleinige Maßnahmen zur VerĂ€nderung der Situation löst diesen Widerspruch nicht auf.
Reflektieren Sie fĂŒr sich doch mal Situationen, die Sie dazu bewegt haben, aktiv VerĂ€nderungen zu beginnen. Sie werden bewusste und unbewusste Überzeugungen finden. Wenn diese dann wieder einmal getriggert werden – kennen Sie das Prinzip und können bewusst darauf reagieren.

In Kategorie: Blog
Kommentare 0

Zukunftswerkstatt im Agile Leadership Summit auf Ibiza

In einer Gruppenarbeit haben wir zuerst fĂŒr uns bekannte Faktoren herausgearbeitet was fĂŒr uns gute FĂŒhrung ausmacht. Wenn wir gute FĂŒhrung und inspirierendes Leadership erlebt haben: Welche Dinge haben wir in diesen Situationen beobachtet? Die Erkenntnisse möchte ich hier teilen:

Kriterien die wir fĂŒr Gute FĂŒhrung gesammelt haben:

  • Absprachen einhalten
  • Orientierung geben
  • Werte vorleben
  • Vision kommunizieren
  • Förderung individueller StĂ€rken jedes einzelnen
  • stĂ€rkt das Team und beschĂŒtzt es vor Ă€ußeren EinflĂŒssen

Ebenso haben wir uns in der Gruppe gefragt, welche Eigenschaften und Handlungen uns aufgefallen sind, wenn wir schlechte FĂŒhrung erlebt haben.

  • Ego
  • Ziele ad-hoc und intransparent Ă€ndern
  • Command & Control, Micromanagement
  • Unsichtbar sein

Im anschließenden aktiven Teil haben wir als Zukunftswerkstatt unserem Unternehmen die Auszeichnung fĂŒr Top Leadership im Jahr 2021 ĂŒberreicht. Die Dankesrede des Teams geht im RĂŒckblick darauf ein, wie wir das geschafft haben. Wir haben uns also in die Zukunft unserer Organisation versetzt und vom erreichten Ziel gedanklich den Weg vom Heute neu gedacht.

Das war eine inspirierende Erfahrung und ein toller Austausch in unserem gemischten Team.

In Kategorie: Blog
Kommentare 0

Disconfirmation Evidence Bias

oder warum es uns so schwer fĂ€llt aus „SonderfĂ€llen“ die richtigen unternehmerischen SchlĂŒsse ziehen

Nach Aldous Huxley und dem Wissen was wir nur zu gern kleinen Kindern mitgeben: Tatsachen verschwinden nicht einfach nur weil wir sie ignorieren. Was wir bei kleinen Kindern wie selbstverstÀndlich erklÀren, holt uns dennoch bei wichtigen unternehmerischen Entscheidungen selbst ein.

Wir neigen nur allzu leicht dazu, eine eigene Meinung zu verstĂ€rken. Fakten, die unsere Theorie stĂŒtzen nehmen wir sehr stark war – die Fakten, die dagegensprechen jedoch weit weniger – das sind dann SonderfĂ€lle die wir nach kurzer Zeit (ca. 30 min) auch gern wieder vergessen.

Eine Meinung oder Überzeugung, die wir zusĂ€tzlich auch noch öffentlich vertreten haben, wollen wir gern behalten. Das ist menschlich, wir wollen konsistent in unseren Aussagen sein. Die Änderung einer Meinung lĂ€sst uns aber gegenĂŒber anderen inkonsistent erscheinen. Dieser Effekt verstĂ€rkt die ungleiche Wahrnehmung und Wertung von Informationen, welche eine Überzeugung stĂŒtzen.

Agile Produktentwicklungen die weniger gut funktionieren, Anlaufschwierigkeiten haben oder bei denen das Produkt letztlich nicht die gewĂŒnschten Erfolge liefert fallen bei klassischen Projektleitern auf fruchtbaren Boden. Ich habe es doch gewusst. Agilisten, die schlecht laufende Projekte nach klassischen Methoden sehen, wussten es schon immer: das kann ja nicht funktionieren.

Agile Produktentwicklungen die weniger gut funktionieren, Anlaufschwierigkeiten haben oder bei denen das Produkt letztlich nicht die gewĂŒnschten Erfolge liefert fallen bei klassischen Projektleitern auf fruchtbaren Boden. Ich habe es doch gewusst. Agilisten, die schlecht laufende Projekte nach klassischen Methoden sehen, wussten es schon immer: das kann ja nicht funktionieren.

Wenn Sie sich der Disconfirmation Evidence Bias bewusst sind, machen Sie sich in Ihrem Umfeld, Ihrem Unternehmen, Ihrem Team dieses Wissen zu nutze. Bewerten Sie radikal offen und unvoreingenommen die Fakten. Suchen Sie selbst nicht nach Beweisen dafĂŒr, dass „Sie“ die richtige Methode einsetzen, sondern suchen Sie ganz bewusst danach diese Theorie zu falsifizieren. Die wissenschaftliche Methode ist es, eine eigene Theorie auf zu stellen und diese dann mit Fakten oder objektiven Messwerten zu falsifizieren. Ermutigen Sie Ihr Team nach Fakten zu suchen, die Ihre unternehmerischen Entscheidungen in Frage stellen. In einem Klima der Offenheit und Transparenz fĂŒhren auf diesem Wege die Fakten die eben nicht in’s Bild passen, die „SonderfĂ€lle“, dann zu besseren unternehmerischen Entscheidungen.

In Kategorie: Blog
Kommentare 0

UI/UX Entwickler (m/w) fĂŒr Angular SPA – Stuttgart ab 01.2019 Vollzeit mit 40% Vor-Ort

Wir entwickeln in zwei Scrum Teams Web-Applikationen fĂŒr Automotive-Dienstleistungen eines OEM. Unsere Kunden nutzen die Dienste mobile als auch auf dem Desktop. Hast Du Erfahrung wie ein User-Interface aufgebaut sein muss? Kannst Du uns bei der Umsetzung neuer Features mit der richtigen User Experience helfen? Idealerweise beherrschst Du Angular, Typescript und kennst Dich in CSS aus. Unsere Apps (SPAs) sind schon produktiv, wir sind also im DevOp’s Mode. Wir nutzen eine Cloud-Container Infrastruktur und bauen Microservices im Backend.
Melde Dich gern bei mir – ich bin auch selbst in den Teams aktiv und kann so auch etwas zum realen Projekt aus der Praxis erzĂ€hlen. Die Zusammenarbeit haben wir abwechselnd eine Woche (Mo-Do) Vor-Ort und eine Woche remote organisiert.
Janko Böhm: +49.175.93.68.111 Tel/WhatsApp; janko.boehm@methodenfabrik.de

In Kategorie: Jobs
Kommentare 0

Scrum Master & Team Coach in 45257 Essen – Teilzeit möglich

Ein Software Entwicklungsteam in Essen sucht einen neuen Scrum Master, da dieser zum Jahreswechsel das Team verlĂ€sst. Wenn Du jetzt schon Zeit hast, kannst Du direkt starten und die Zeit bis zum Jahreswechsel als Übergabephase nutzen.
Das Team ist nicht ganz unerfahren, möchte auf den Facilitator aber nicht verzichten. Technisch ist das Team gut aufgestellt, braucht aber einen verstĂ€ndnisvollen Coach, der bei Klippen im persönlichen Umgang einfĂŒhlsam unterstĂŒtzt.
Auch wenn Du in der Rolle des Scrum Masters noch nicht so lang arbeitest, aber agile Prinzipien kennst, Scrum Praktiken Dir nicht fremd sind und soziale Skills im Umgang mit Menschen Deine StÀrke ist, könnte das Deine Herausforderung sein.
Melde Dich gern bei mir, Janko Böhm +49.175.93.68.111 oder janko.boehm@methodenfabrik.de

In Kategorie: Jobs
Kommentare 0

Technology Lead als Leitwolf fĂŒr ein Dev-Team in Berlin

Du kennst die neusten Entwicklungen im Bereich Web Development und weißt wie man robuste, skalierbare Software Architektur baut?
Triffst Du auch gern technische Entscheidungen, argumentierst und verteidigst diese? Das ganze aber nicht nur theoretisch, sondern entwickelst auch gern noch selbst guten Code?
Da haben wir eine Herausforderung, bei der Du neben dem reinen Code schreiben auch Deine technischen und kommunikativen StÀrken einbringen kannst.
Wir arbeiten in einem verteilten Umfeld mit mehreren Teams und bauen Web Services sowie Web Anwendungen. Deine Kenntnisse insbesondere in JavaScript (HTML, CSS Frameworks), WebAPIs (REST), TypeScript wollen wir nutzen um gute, stabile und skalierbare Produkte zu bauen. Wir erweitern Microservices-Architekturen in einer AWS Cloud fĂŒr Applikationen und Services die schon produktiv sind. Uns fehlt aber noch ein Leitwolf der nah am Team ist und technisch dem Produkt Struktur und Richtung gibt.
Janko Böhm: +49.175.93.68.111 janko.boehm@methodenfabrik.de

In Kategorie: Jobs
Kommentare 0

Wir suchen: Product Owner Support – Story Editor in 71636 Ludwigsburg


Wir suchen nach UnterstĂŒtzung fĂŒr unseren PO. Wir haben zwei Team die jeweils eine iOS App entwickeln. Dazu brauchen wir viele kleine gut geschriebene User Stories fĂŒr unsere Entwickler-Teams. Leider hat unser PO nicht genĂŒgend Zeit um diese immer selbst aus zu formulieren und in’s Jira zu bringen. Kannst Du uns auf freiberuflicher Basis unterstĂŒtzen? Vollzeit – oder auch nicht, hast Du Lust auf kreative Leute in zwei jungen Teams mit viel Raum fĂŒr Deine Persönlichkeit? Wir sprechen Deutsch.

In Kategorie: Jobs
Kommentare 0

Folge #7 Skalierung in der agilen Produktentwicklung

Skalierung in agilen Produktentwicklungen und VerÀnderungen in Unternehmen die damit einhergehen.
Was ist Skalierung? Ist das Vorhandensein mehrere Produktentwicklungs-Teams in einem Unternehmen schon (automatisch) Skalierung? Ausschlaggebend fĂŒr eine Skalierung ist die Arbeit von mehreren Teams an einem integrierten Produkt. Sonst wĂ€ren es einfach mehrere agile Teams die alle fĂŒr sich an ihrem eigenen Produkt zeitgleich nebeneinander entwickeln.
In einer integrierten Produktentwicklung in mehreren Teams entstehen AbhÀngigkeiten und Herausforderungen der Synchronisation. In dem Podcast greifen wir diese AbhÀngigkeiten auf, diskutieren SkalierungsansÀtze wie z.B. Scrum@Scale.
Neben den inhaltlichen Themen gibt es aber auch die Idee die AbhÀngigkeiten erst garnicht entstehen zu lassen.
Wenn diese AbhĂ€ngigkeiten nicht (weiter) vermieden werden können muss das Team diese in den Griff bekommen. Hierbei könnten Konflikte zwischen dem VerstĂ€ndnis der Selbstorganisation des Teams und dem Steuerungsinteresse von außen (andre Teams/ Linienorganisation) entstehen. Auch das Reporting und die Fortschrittskontrolle bei grĂ¶ĂŸeren Team-Konstrukten stellt eine Herausforderung der Organisation dar.

Abschließend stellen wir auch Formulierungen zu agilen Prinzipien vor. Könnten Prinzipien wie

  • Wir fĂŒhren den Stand der Produktentwicklung nach jeder Iteration öffentlich vor
  • Wir teilen Wissen innerhalb der Organisation aktiv
  • Wenn möglich ziehen wir das persönliche GesprĂ€ch vor

dazu fĂŒhren das agile Mindset zu bilden und helfen diese Prinzipien bei der Skalierung?

Kommentare 0

Agile Transformation Navigator – Mit Augenmaß die richtige Dosis zwischen Speed und Reifegrad

AgilitĂ€t erscheint manchmal als die Antwort auf alle Probleme in der Produktentwicklung. Wenn dann noch agile Produktentwicklungsprozesse so verstanden und gelebt werden dass keine Planung und keine klare Ausrichtung auf ein gemeinsames Ziel mehr stattfinden muss – denn wir sind ja agil, kann das auch schnell schief gehen.

In dem Post des Transformation Navigators möchte ich 2 Dimensionen (Speed und Reifegrad) aufspannen. Innerhalb der zwei Dimensionen bestimmen wir zum einen die Position des Teams und zum anderen die Position des Auftrags bzw. des zu erzeugenden Produkts. Eine rĂ€umliche NĂ€he zeigt dann an, dass das Team mit den passenden Werkzeugen, Praktiken und Prinzipien das Produkt erstellt. Wenn beide Punkte weiter auseinanderfallen wird ein Weg sichtbar den entweder das Produkt zum Team, oder das Team auf das Produkt hin zurĂŒcklegen sollte.

Suchen wir uns die richtigen Produkte und AuftrĂ€ge fĂŒr das bestehende Team?

Haben wir das richtige Team mit den richtigen Werkzeugen fĂŒr die Aufgabe?

Das Paper der „Agile Transformation Navigator“ spannt dazu die Landkarte auf und setzt das Boot „Team“ wie auch das Boot „Produkt-Ziel“ auf das Wasser. Wie lang ist die Stecke zum paddeln?

Download – Agile Transformation Navigator

In Kategorie: Blog
Kommentare 0

Folge #6 Wann ist mein agiles Projekt fertig und was kostet es?

Zeit- und Kostenplanung in einem agilen Projekt – Wir werden doch aber dennoch nach Zeit und Kosten des Projekts gefragt.
Die Fragen sind ja nicht weg nur weil wir eine Produktentwicklung agil angehen. In der klassischen Budgetierung mĂŒssen die Fragen nach Geld und Zeit bedient werden. Das kann und will ein agiler Ansatz der Umsetzung auch nicht ignorieren.
Ein klassischer Planungsansatz stellt die EffektivitĂ€t der Umsetzung des Gesamt-Ergebnisses in den Vordergrund und fragt: „Wie kann das Vorhaben möglichst Kosteneffizient mit dem geringsten Ressourceneinsatz vollstĂ€ndig erreicht werden?“ Der agile Ansatz stellt die EffektivitĂ€t – also das Was in den Vordergrund, geht nicht davon aus das alle Elemente des Vorhabens umgesetzt werden mĂŒssen und fragt stattdessen: „Welche Elemente mĂŒssen wir in einem ersten Schritt auf jeden Fall zuerst umsetzen (MVP)?“ Dieser kleinere, aber wichtigere Teil wird unter Aufgabe der Kosten-Effizienz zuerst umgesetzt und schafft dafĂŒr aber schon frĂŒh Mehrwert. Kosten und Zeitplanung können mit Erfahrungswerten fĂŒr LiefergegenstĂ€nde hochgerechnet werden. Diese Hochrechnung hat statistisch weniger Varianz (und damit weniger Fehler) weil die Planungskontext kleiner ist.
Wir diskutieren in diesem Podcast die einzelnen Planungsaspekte, stellen VerstĂ€ndnisfragen und stellen die Frage nach dem „Wie kann ich das meinem Kunden erklĂ€ren?“