Genau das ist der Kern, wenn du Anforderungen mit KI erheben willst: nicht schneller tippen, sondern besser denken. Die KI schreibt die Story nicht für mich – sie führt mich durch ein Gespräch, an dessen Ende ich selbst klarer bin als vorher.

Das klingt banal. Ist aber das genaue Gegenteil von dem, was die meisten mit KI machen.

Der Fragebogen-Reflex

Der erste Reflex – bei Menschen wie bei KI – ist: alles auf einmal. Ein großes Template, zwanzig Felder, „bitte vollständig ausfüllen“. Oder du kippst der KI in einem Absatz deine halbe Idee hin und sie spuckt eine fertig aussehende Story aus.

Das Problem: So entsteht eine Scheinvollständigkeit. Du füllst Felder, weil sie da sind, nicht weil du die Antwort wirklich durchdacht hast. Und die KI ergänzt den Rest mit plausiblen Annahmen. Am Ende steht ein Dokument, das fertig aussieht – und auf Vermutungen gebaut ist.

Anforderungsarbeit ist aber kein Formular. Sie ist Denkarbeit. Und Denken erzwingt man nicht mit mehr Feldern, sondern mit den richtigen Fragen zur richtigen Zeit.

Anforderungen mit KI erheben heißt: eine Frage nach der anderen

Deshalb läuft es bei mir als echtes Gespräch. Eine Frage. Ich antworte. Die KI hört zu, hakt nach, stellt die nächste. Kein Fragebogen, ein Dialog.

Die Reihenfolge ist bewusst gewählt: Erst was genau, dann warum (der eigentliche Wert), dann für wen, dann – die unbequeme – was explizit nicht, und zum Schluss der Kern der Akzeptanzkriterien.

Der Unterschied zum Fragebogen ist der gleiche wie zwischen einem guten Interviewer und einem Formular: Der Interviewer merkt, wenn eine Antwort schwammig ist, und bohrt nach. Das Formular nimmt jede Antwort, auch die faule. Genau dieses Nachbohren – „für wen genau?“, „was passiert, wenn nicht?“ – ist die Arbeit, die eine Story trägt oder scheitern lässt. (Über den Interview-Ansatz selbst habe ich hier schon ausführlicher geschrieben.)

Während wir reden, prüft die KI schon

Und jetzt kommt der Teil, der mir das Gespräch erst richtig wertvoll macht: Während ich rede, arbeitet die KI im Hintergrund.

Sie gleicht meine Idee live gegen die bestehenden Tickets ab – gibt es das schon, unter anderem Titel, in einem anderen Epic? Sie schaut in die Wissensbasis aus Teil 2: Widerspricht die Idee einer Architekturentscheidung? Steht sie im Konflikt mit etwas, das wir bewusst verworfen haben? Gibt es Abhängigkeiten zu anderen Stories?

Das ist der Moment aus Teil 1, nur von innen betrachtet: „Das gibt es schon. Zweimal.“ Ich muss dafür nicht 200 Tickets im Kopf haben – die KI hat sie parat, während ich mich aufs Denken konzentriere. Vor einem Live-Abgleich fragt sie mich übrigens kurz, ob sie loslegen soll. Auch hier bleibe ich der, der entscheidet.

Am Ende steht ein Draft – nicht das Ticket

Wichtig: Was aus dem Interview herausfällt, ist ein Draft. Ein strukturierter Entwurf mit Titel, dem eigentlichen „als wer will ich was und warum“, ersten Akzeptanzkriterien, einer klaren Abgrenzung und den gefundenen Abhängigkeiten. Dazu ein schneller INVEST-Check – und wenn die Sache zu groß ist, ein Vorschlag, sie zu splitten.

Es ist ausdrücklich nicht das fertige Ticket. Es ist mein Rohmaterial – sauber vorbereitet, aber noch nicht entschieden. Und es ist eine simple Markdown-Datei, die ich lesen und ändern kann, ganz gleich, ob die KI gerade mitspielt oder nicht.

Der Draft geht als Nächstes durch die Mangel. Und zwar nicht durch eine Perspektive, sondern durch ein ganzes Gremium.

Was das im Alltag verändert

Die größte Wirkung hat nicht die Zeitersparnis – die gibt es, ist aber nicht der Punkt. Die größte Wirkung ist, dass ich gezwungen werde, meine eigene Idee zu Ende zu denken, bevor sie irgendwer anders sieht. Die unbequemen Fragen kommen jetzt von der KI, an meinem Schreibtisch, und nicht später im Refinement vom halben Team.

Die Exportfunktion von neulich? Die sieht heute anders aus als die Idee, mit der ich reingegangen bin. Besser. Weil mir jemand die eine unbequeme Frage gestellt hat, bevor ich losgelaufen bin.

Das ist Teil 3 der Serie „Requirements Engineering mit KI-Agenten“. Im nächsten Teil geht der Draft durch die Mangel: sechs Perspektiven schauen gleichzeitig drauf – Security, UX, Architektur, Compliance, Story-Qualität – und ein Advocatus Diaboli, der mich vor mir selbst schützt.

Alle Teile der Serie: Zur Themenseite „Requirements Engineering Pipeline“

Der Beitrag Anforderungen mit KI erheben: ein Interview statt eines Fragebogens erschien zuerst auf Das ist die Welt von Thomas.

Der Fehler war nicht die KI. Der Fehler war, dass ich keine Wissensbasis für KI aufgebaut hatte, bevor ich sie arbeiten ließ. Kein Rahmen, kein „so arbeiten wir hier“. Sie musste raten. Und raten kann sie beeindruckend gut – nur eben nicht zuverlässig richtig.

Das war der Moment, in dem ich mein Vorgehen umgedreht habe: erst das Fundament, dann die Agenten.

Was passiert, wenn die KI raten muss

Eine KI ohne Kontext ist wie ein neuer Kollege am ersten Tag, den du sofort eine Anforderung schreiben lässt. Er ist klug, motiviert, formuliert schöne Sätze – aber er kennt eure Historie nicht, eure Entscheidungen nicht, eure Grenzen nicht.

Also füllt er die Lücken mit Annahmen. Die klingen plausibel, weil er gut klingt. Und genau das ist die Falle: Das Ergebnis sieht fertig aus, obwohl es auf Vermutungen steht.

Bei Anforderungen ist das teuer. Eine Story, die eine bestehende Architekturentscheidung ignoriert. Ein Feature, das gegen eine Datenschutzvorgabe läuft, die es längst gibt. Ein Vorschlag, den ihr vor einem Jahr aus gutem Grund verworfen habt. Nicht, weil die KI dumm ist – sondern weil ihr niemand gesagt hat, was gilt.

Eine Wissensbasis für KI schlägt jeden cleveren Prompt

Die meisten versuchen, dieses Problem mit besseren Prompts zu lösen. Immer längere Anweisungen, immer mehr „beachte bitte auch…“. Das skaliert nicht. Du kannst nicht vor jeder Frage die halbe Firmenhistorie ins Chatfenster tippen.

Der bessere Hebel ist eine Wissensbasis für KI: strukturiertes, kuratiertes Wissen, auf das jeder Agent bei jeder Aufgabe automatisch zugreift. Nicht im Prompt, sondern als fester Kontext im Hintergrund. Die KI rät dann nicht mehr – sie liest nach.

Der Unterschied ist derselbe wie zwischen einem Berater, der dein Unternehmen zum ersten Mal sieht, und einem, der seit Jahren dabei ist. Gleiche Intelligenz, völlig andere Qualität der Antwort. Nicht weil der eine schlauer ist, sondern weil er den Kontext hat.

Zwei Schichten: was für alle gilt, was nur fürs Produkt

Bei mir liegt diese Wissensbasis in zwei Schichten – und diese Trennung ist der eigentliche Trick.

Schicht 1 – Organisation. Alles, was immer gilt, egal woran ich arbeite: Compliance und Datenschutz, Security-Baselines, Architektur-Guidelines, die grobe Strategie, das Stakeholder-Verzeichnis. Diese Schicht ist bei jeder Analyse aktiv.

Schicht 2 – Produkt. Alles, was nur ein bestimmtes Produkt betrifft: Personas, Architekturentscheidungen (inklusive der wichtigen Frage „Was haben wir bewusst nicht gebaut – und warum“), bestehende Stories, Roadmap, nicht-funktionale Anforderungen.

Warum die Trennung? Weil Compliance für alles gilt – die will ich nicht bei jedem Produkt neu erfinden. Und weil Produktwissen isoliert bleiben muss – eine Entscheidung aus Produkt A darf die Analyse für Produkt B nicht verfälschen. Schicht 1 gilt überall, Schicht 2 wird passend zum aktuellen Produkt dazugeladen. So hat jeder Agent denselben, sauberen Informationsstand.

Das Fundament gehört zuerst mir, dann der KI

Jetzt kommt der Teil, der mir besonders wichtig ist: Diese Wissensbasis ist keine „KI-Konfiguration“. Es sind einfache Markdown-Dateien in Obsidian – Klartext, den ich lese, pflege und verstehe.

Das heißt: Das Fundament nützt zuerst mir. Es ist mein Zweitgehirn, meine dokumentierten Entscheidungen, mein „so arbeiten wir hier“. Dass die KI dieselben Dateien liest, ist ein Nebeneffekt – ein sehr nützlicher, aber eben nur ein Nebeneffekt.

Damit bleibt der Ansatz genau das, was ich in Teil 1 beschrieben habe: KI-basiert, aber nicht KI-abhängig. Fällt die KI aus, habe ich immer noch ein sauber gepflegtes, lesbares Wissenssystem. Ich verliere Tempo, nicht das Fundament. Genau das meine ich mit Guidelines-First – ein Prinzip, über das ich schon im Dompteur-Modell geschrieben habe.

Was ich dabei gelernt habe

Die wichtigste Lektion: Die Qualität der KI-Arbeit hängt weniger am Modell und am cleveren Prompt, als man denkt – und viel mehr an dem, was die KI lesen darf. Wer vorne beim Kontext spart, zahlt hinten bei den Ergebnissen.

spielmit.eu läuft heute anders. Erst das Fundament, dann die Agenten. Der Jenga-Turm steht nicht mehr auf Vermutungen, sondern auf einer Wissensbasis, die ich selbst geschrieben habe.

Das ist Teil 2 der Serie „Requirements Engineering mit KI-Agenten“. Im nächsten Teil wird es konkret: das Interview – wie aus einer rohen Idee ein Story-Draft wird, ganz ohne Fragebogen, und wie die KI dabei nebenbei merkt, dass es eine Idee vielleicht schon gibt.

Alle Teile der Serie: Zur Themenseite „Requirements Engineering Pipeline“

Der Beitrag Guidelines-First: Warum eine KI ohne Wissensbasis am Jenga-Turm baut erschien zuerst auf Das ist die Welt von Thomas.

Ich saß da und wusste kurz nicht, ob ich mich ärgern oder freuen soll. Geärgert, weil ich gerade dabei war, Arbeit zu doppeln, die längst getan war. Gefreut, weil mir das jemand jetzt sagt. Und genau an diesem Punkt hängt das Thema, über das gerade alle streiten: KI-generierte User Stories.

Die will nämlich kaum jemand lesen. Und ehrlich gesagt: ich auch nicht.

Dass es mir jetzt auffällt – an meinem Schreibtisch und nicht erst im Refinement, wo so eine Diskussion die Zeit des ganzen Teams frisst und die Velocity drückt – ist kein Zufall. Genau das ist mein Job: solche Dinge früh erkennen und im Zweifel vorab mit mir selbst und meinen Agenten klären.

Erst der ehrliche Teil: der Schmerz

Die Story von neulich war der harmlose Fall. Da hat es jemand – die KI – rechtzeitig gemerkt. Meistens merkt es keiner. Und dann passiert genau das, was Anforderungsarbeit seit Jahren zäh macht:

Du legst eine Story an, die es längst gibt – nur unter anderem Titel, im falschen Epic, von jemand anderem geschrieben. Du findest sie nicht, weil du gar nicht weißt, dass du suchen müsstest. Zwei Teams bauen dieselbe Sache.

Oder jemand bringt eine Idee auf, die vor zwei Jahren schon einmal auf dem Tisch lag und bewusst verworfen wurde. Die Story liegt irgendwo in Jira – mit Glück archiviert, im schlimmsten Fall längst gelöscht. Mit genug Recherche fände man sie wieder. Aber genau das ist der Punkt: Als PO will ich das Backlog nach vorne bringen, nicht vor jeder Idee zum Detektiv werden und ständig hinterfragen, ob es das nicht schon gab. Diese Sucharbeit brauche ich – und genau die kann mir eine KI abnehmen.

Oder die Story ist sauber formuliert, klingt rund – und im Sprint fällt auf, dass sie am Datenschutz vorbeigeht, ein Sicherheitsloch aufreißt oder einer Architekturentscheidung widerspricht. Jetzt ist es teuer.

Und selbst wenn alles gut läuft: Kaum hast du das Ticket ans Team übergeben, entwickelt es sich in Jira weiter – neu geschnitten, ergänzt, umpriorisiert. Deine Planung steht derweil auf altem Stand. Du merkst es nicht. Bis es kracht.

Das ist der Schmerz. Nichts davon ist spektakulär. Aber es summiert sich – zu doppelter Arbeit, vergessenen Entscheidungen und Stories, die im luftleeren Raum entstehen.

„Keine KI-generierten User Stories“ – und sie haben recht

Wenn ich davon erzähle, kommt oft der Reflex: „Dann lass doch die KI die Stories schreiben.“ Und genauso oft kommt von guten Entwicklern der Gegenreflex: „Bitte nicht. KI-generierte User Stories merke ich sofort – und dann lese ich sie nicht gern.“

Der Frust dahinter ist berechtigt. Nichts ist ermüdender als glatter Text, der so tut, als hätte jemand nachgedacht, aber niemand hat. Gleichzeitig erwarten dieselben Leute, dass ein Product Owner 2026 KI nutzt. Kein Werkzeug in der Hand zu haben, das alle anderen längst haben, wirkt eben auch nicht souverän.

Das klingt nach Widerspruch. Ist es aber nicht. Beide Seiten reden nur über zwei verschiedene Dinge. Das Problem ist nicht, dass KI im Spiel ist. Das Problem ist, was sie tut.

Warum Prüfen das Schreiben schlägt

Eine Story zu schreiben heißt: eine Absicht zu formulieren. Warum bauen wir das? Für wen? Was lassen wir bewusst weg? Das hängt an Kontext, an Historie, an Verantwortung – an Dingen, die in meinem Kopf und in den Köpfen meiner Kollegen stecken, nicht im Trainingsdatensatz eines Modells. Wenn ich das an eine KI abgebe, kommt genau der Text heraus, den keiner lesen will: plausibel und hohl.

Eine Story zu prüfen ist das genaue Gegenteil.

Prüfen heißt: alles gegen alles abgleichen. Gibt es das schon? Widerspricht es einer Entscheidung von damals? Was sagt der Datenschutz, was der Sicherheitsblick, was der Nutzer? Das ist stumpfe, vollständige, ausdauernde Arbeit – und genau da bin ich als Mensch schwach. Ich vergesse Tickets. Ich habe nicht alle Architekturentscheidungen im Kopf. Ich kann nicht gleichzeitig die Security-, die Datenschutz- und die Nutzerbrille tragen.

Eine Maschine kann das. Unermüdlich, bei jedem einzelnen Ticket.

Deshalb schreibt bei mir die KI nicht – sie prüft. Ich behalte den Teil, den nur ich kann: entscheiden, was wir bauen und warum. Sie übernimmt den Teil, den ich alleine nie so gründlich hinbekäme. Das ist keine Bequemlichkeit. Das ist Arbeitsteilung nach Stärken.

Die These, auf der alles aufbaut

Der Mensch besitzt die Absicht. Die Agenten besitzen die Prüfung.

Was am Ende im Ticket steht, wurde nicht geschrieben. Es wurde geprüft – und von mir entschieden. Deshalb sind meine Stories besser durchdacht, seit KI im Spiel ist, nicht schlechter.

Zwei Bausteine davon habe ich hier schon beschrieben: den Interview-Ansatz statt Fragebogen und das Dompteur-Modell mit Guidelines-First. In dieser Serie setze ich sie zu einem kompletten Vorgehen zusammen.

KI ist eine Ergänzung – kein Allheilmittel

Damit das nicht falsch ankommt: Die KI ist bei mir nicht der Chef. Wir Product Owner sind die Profis, die entscheiden – die KI unterstützt. Und Unterstützung heißt für mich ausdrücklich, dass ich auch dann arbeiten kann, wenn sie mal nicht da ist.

Deshalb liegt meine gesamte Wissensbasis – alle Guidelines, alle Stories, alle Entscheidungen – als einfache Markdown-Dateien in Obsidian. Klartext, den jeder Mensch lesen und selbst bearbeiten kann, ohne Spezialwerkzeug, versioniert in Git. Die KI liest genau dieselben Dateien wie ich, kein verstecktes Format dazwischen.

Der Workflow ist KI-basiert, aber nicht KI-abhängig. Ist das Modell mal nicht erreichbar, bin ich offline oder fällt der Dienst aus, verliere ich Tempo – nicht meine Daten und nicht die Kontrolle. Dann mache ich eben von Hand weiter. Genau das ist der Unterschied zwischen einem Werkzeug, das dich stärker macht, und einem, von dem du abhängig wirst.

Was ich dabei gelernt habe

Der wichtigste Perspektivwechsel war, die KI nicht als schnelleren Texter zu sehen, sondern als etwas, das ich alleine nie leisten könnte: Hunderte Tickets vor jeder neuen Idee durchsehen, jede alte Entscheidung parat haben, gleichzeitig aus fünf Blickwinkeln auf dieselbe Anforderung schauen.

Das nimmt mir die Fleißarbeit ab – und lässt mir den Kopf frei für das, was wirklich meine Aufgabe ist.

KI-generierte User Stories im eigentlichen Sinn entstehen bei mir also nicht. Was am Ende rausgeht, ist geprüft – und von mir verantwortet.

Und die Story von neulich? Die habe ich nicht angelegt. Die gab es ja schon.

Das ist der erste Teil einer Serie über mein Vorgehen im Requirements Engineering mit KI-Agenten. Im nächsten Teil geht es ums Fundament: warum eine KI ohne Wissensbasis am Jenga-Turm baut – und was sich ändert, sobald sie kuratierten Kontext bekommt.

Alle Teile der Serie: Zur Themenseite „Requirements Engineering Pipeline“

Der Beitrag Warum ich keine KI-generierten User Stories schreibe – und KI trotzdem überall einsetze erschien zuerst auf Das ist die Welt von Thomas.

Ein Kollege hat mich letzte Woche zu einem Termin mitgenommen. Eine Gruppe Menschen, die über eine Kooperation mit dem Arbeitsmarkt zu uns gekommen sind. Menschen, die viele Bewerbungen schreiben. Die wenige oder gar keine Antworten bekommen. Die sich schwertun — manche, weil Deutsch nicht ihre erste Sprache ist, manche, weil die Bewerbung einfach nicht rund ist, manche, weil sie schlicht nicht wissen, wie das heute alles funktioniert.

Und dann fiel das Thema KI.

Die Reaktion hat mich ehrlich gesagt überrascht. Nicht, weil ich keine Ahnung hatte, dass da Skepsis herrscht. Aber wie weit weg das alles von meiner eigenen Realität ist — das hat mich dann doch getroffen.

Wir reden aneinander vorbei

In meiner Welt ist KI Alltag. Ich nutze sie täglich: Anforderungserhebung, Code-Reviews, Texte, Planung. Meine Frau Sarah hat auch angefangen damit — ein bisschen zögerlich noch, aber sie nutzt es. Bei uns ist KI längst kein Thema mehr, das man groß erklären muss.

Und dann sitzt du da, mit Menschen, die noch nie ChatGPT aufgemacht haben. Die KI kennen als Schlagzeile, als Bedrohung, als das Ding, das irgendwann kommt und alles verändert.

Das Ding ist aber: es ist schon da.

Was mich wirklich nachdenklich gemacht hat — wir ITler denken über Dinge nach wie: Welches Modell ist besser? Wie prompted man richtig? Welche Aufgaben delegiere ich an KI, welche nicht? Das sind unsere Probleme. Und das ist natürlich meilenweit entfernt von jemandem, der sich fragt: „Werde ich beim nächsten Bewerbungsgespräch überhaupt noch von einem Menschen gelesen?“

Der Akkuschrauber

Ich habe versucht, das runterzubrechen. Mein Standardvergleich für solche Momente: der Akkuschrauber.

Kein Handwerker dreht heute tausend Schrauben von Hand. Jeder greift zum Akkuschrauber. Nicht weil er muss, sondern weil es einfach sinnvoll ist. Und trotzdem hat nicht der Akkuschrauber das Haus gebaut — der Handwerker hat es gebaut. Das Werkzeug hat ihm nur geholfen.

KI ist nichts anderes. Ein Werkzeug. Kein Teufelswerkzeug, kein Jobkiller, kein Alleskönner. Ein Werkzeug, das man einsetzen kann — oder auch nicht. Aber wer es nicht einsetzt, macht es sich unnötig schwer.

Das gilt übrigens nicht nur für ITler.

Die Sache mit dem Bewerbungsscreening

Ein Punkt, der in der Runde aufkam, hat mich nicht losgelassen. Wenn KI schon heute Bewerbungen voraussortiert — und das tut sie in vielen Unternehmen bereits — dann sind Menschen, deren Bewerbung nicht passt, raus. Ohne dass ein Mensch draufgeschaut hat. Ohne zweite Chance.

Das ist hart. Ich will das nicht schönreden.

Aber die Konsequenz daraus ist nicht, KI abzulehnen. Die Konsequenz ist, das Spiel zu verstehen und mitzuspielen. Keine generische Bewerbung an hundert Unternehmen schicken. Sich mit der Stelle beschäftigen. Die eigene Bewerbung prüfen lassen — von KI, von Freunden, von wem auch immer. Und dann nochmal prüfen.

Lass dir deine Bewerbung von ChatGPT durchlesen. Dann von Gemini. Schau, was beide sagen. Und dann entscheide selbst, was davon zu dir passt — denn wenn eine KI plötzlich hochgestochenes Kanzleideutsch aus dir macht, du aber eigentlich bodenständiger Handwerker bist, dann klingt das nicht nach dir. Und das hilft niemandem.

Wie fängt man an?

Das war die praktischste Frage des Abends, und sie verdient eine praktische Antwort:

Schritt 1: Öffne chat.openai.com oder gemini.google.com. Schreib rein, was dich beschäftigt. Stell eine Frage. Schau, was passiert. Kein Tutorial, kein Kurs — einfach machen.

Schritt 2: Nimm ein konkretes Problem, das dir gerade im Kopf rumgeht — deine Bewerbung, ein Anschreiben, eine schwierige E-Mail. Und unterhalte dich mit der KI darüber wie mit einem Freund. Nicht als Suchmaschine, sondern als Gesprächspartner.

Schritt 3: Gib der KI eine Rolle. Sag ihr: „Du bist HR-Mitarbeiter bei Firma X. Hier ist meine Bewerbung. Was würdest du daran bemängeln?“ Du wirst überrascht sein, wie anders die Antwort wird — und wie viel konkreter.

Die Angst vor KI verliert man nicht durch Nachdenken. Man verliert sie durch Benutzen.

Ein Tipp noch — für alle, die gerade bei null anfangen

Der KI-Podcast der ARD hat vor Kurzem eine Folge rausgebracht zum Thema: Wie fange ich 2026 mit KI an? Ist es zu spät? Was mache ich zuerst? Wirklich empfehlenswert — kein Tech-Insider-Geraune, sondern ehrlich für Einsteiger gemacht.

Was ich mitgenommen habe

Ich sehe mich nicht als KI-Missionar. Das ist nicht mein Ding.

Aber dieser Termin hat mir gezeigt, dass wir in der IT sehr schnell vergessen, wie weit wir von der Realität anderer Menschen entfernt sind. Wir diskutieren über Kontextfenster und Modellvergleiche, während andere noch nicht mal wissen, dass man KI kostenlos nutzen kann.

Das ist keine Kritik an irgendjemandem — das ist einfach so. Aber ab und zu aus der eigenen Bubble rausgucken und sich fragen: Was beschäftigt eigentlich die Menschen, die nicht täglich mit diesem Thema arbeiten? Das tut gut. Mir jedenfalls.

Und das Schönste daran: Was heute noch nicht funktioniert, funktioniert in einem halben Jahr. Ich hab das selbst erlebt — spielmit.eu hätte ich vor einem Jahr mit KI nicht so bauen können wie Anfang dieses Jahres. Die Entwicklung geht schneller als jeder Kurs hinterherkommt.

Also: Gebt KI eine Chance. Probiert Dinge nochmal aus, die vor einem Jahr nicht geklappt haben. Und verliert die Angst — nicht durch Reden darüber, sondern durch Machen.

Der Beitrag Angst vor KI überwinden — und der Moment, in dem mir klar wurde, wie weit wir in der Bubble sind erschien zuerst auf Das ist die Welt von Thomas.

beruflicher Reset auf Raten

Schon in einigen Beiträgen hier habe ich über meinen beruflichen Reset gesprochen. Auf der Suche nach der persönlichen Zufriedenheit habe ich mich und meine Tätigkeit stark hinterfragt. Nach und nach wurden Dinge verändert mit dem Ziel wieder auf den richtigen Weg zu kommen. So richtig funktionieren wollte es jedoch nicht, meine persönliche Unzufriedenheit wuchs ständig weiter. Es war Zeit für einen „harten Reset“.

Wechsel der Perspektive

Mein persönlicher Anspruch die Welt im beruflichen Context per Voice zu verbessern ist aus meiner Sicht fehlgeschlagen. Die Gründe hierfür sind vielschichtig und müssen an dieser Stelle nicht näher ausgeführt werden. Für mich selbst steht jedoch fest, dass ich meinen eigenen Ansprüchen im Themenbereich Conversational.ai und der Umsetzung von Voicebots im aktuellen Konzernumfeld nicht gerecht werden kann.

Aus diesem Grund habe ich mich zu einem harten Schnitt entschieden und den Innovationsbereich, und somit auch mein ehemaliges Team, verlassen. Ich habe mir im Haus der DB eine neue Heimat gesucht bei welcher ich so gar nichts mit diesem Themenbereich zu tun habe und einen persönlichen Neustart wagen kann.

Ganz klar war für mich, dass ich bei dem Wechsel auch die Rolle es TecoLead für HMI abgeben werde. Ich bin sehr froh darüber dass Sascha Wolter diese Rolle nun übernommen hat. Mit seiner Leidenschaft zum Thema Mensch-Maschine Schnittstelle ist er genau der richtige für den Job. Ich bin großer Zuversicht, dass Sascha es schafft, das wichtige Thema HMI innerhalb der DB weiter nach vorne zu treiben.

In meinem neuen Team führe ich wieder den Job des Architekten aus. In meiner neuen Einheit, dem „House of Mobile“ innerhalb der DB-Systel trage ich nun dazu bei, die Welt auf technischer Sicht etwas schöner zu machen. Ich freue mich auf diese Herausforderung.

Das neue berufliche Umfeld beschäftigt sich im Kern mit der Umsetzung von Mobilen Anwendungen. Im ersten Schritt bin ich hier im Backend im Einsatz, werde mich aber nach und nach auch in Richtung Frontend bewegen. Ich bin gespannt wo die Reise hingeht, privat habe ich mich auf jeden Fall schonmal ein wenig mit den unterschiedlichen Frontend-Frameworks wie Flutter oder auch Angular und Co. auseinandergesetzt.

Voicebot und conversational.ai für mich am Ende?

Wer mich ein wenig kennt der weiß, dass ich mein privates Interesse im privaten Umfeld gerne vorantreibe. So auch im Bereich Conversational.ai. Laut meinem Git-Repo habe ich am 4. April 2020 den initialen Commit durchgeführt. Seitdem arbeite ich im Privaten kontinuierlich an meiner Idee einer Wartbaren, Skalierbaren und Providerunabhängigen Conversational.ai Plattform. In bisher 1.452 commits ist hierbei etwas entstanden auf was ich persönlich sehr stolz bin. Unter anderem bot die hier entstandene Lösung die Basis für die ersten Feldversuche im Forschungsprojekt SKILLED der TH-Köln …

Klar ist für mich, dass ich meine „neu gewonnene Leidenschaft“ weiterführen werde. Ich bin noch lange nicht am Ziel, dennoch kann man bereits im realen Leben Gespräche mit dieser Lösung führen. Die fachliche Modellierung der Prozesse erfolgt auf Basis von BPMN2.0 und wird direkt über die Camunda Process Engine ausgeführt.

Im Kern orchestriert die Plattform die besten Komponenten vom Markt, um für einen spezifischen Anwendungsfall das beste Ergebnis zu liefern. Beim Design der Lösung habe ich peinlich genau darauf geachtet Abhängigkeiten zu einem einzelnen Provider zu verhindern.

Ab sofort: Beruflich Vollgas im House of Mobile, Voicebots „als Hobby“

Ich hoffe, dass der nun doch recht hart durchgeführte Schnitt mich dazu bringt die gewünschte Zufriedenheit wieder zu finden.

Das Thema Voicebot / Voice-First spielt ab sofort in meinem beruflichen Context keine Rolle mehr. Wie jedoch schon angekündigt ist dieser interessante Bereich aus privater Sicht noch lange nicht vom Tisch …

Beruflich konzentriere ich mich nun voll auf meine neue Tätigkeit im „House of Mobile“ der DB Systel. Ich freue mich darauf viele neue Menschen kennen zu lernen und diverse Architekturansätze zu diskutieren. Es wird mit Sicherheit eine großartige Zeit und ich werde, erneut, viel lernen.

Der Beitrag beruflicher Vollreset – Voicebot / Conversational AI nur noch im „Privaten“ erschien zuerst auf Das ist die Welt von Thomas.

Was stört mich an meiner Tätigkeit als Product Owner

In meiner Rolle des Product Owner, welcher an der Erfüllung seines Business Cases gemessen wird fühle ich mich nicht wohl. Ich muss mich aktiv darum kümmern Geschäft für mein Team ans Land zu ziehen und Aufträge zu generieren.

Eine Zusammenarbeit mit anderen Teams zahlt nicht positiv auf meinen Case ein. Dies sorgt im Endeffekt dazu dass ich mit einem eingeschränkten Werkzeugkasten arbeiten muss und meinem Kunden nicht die wirklich perfekte Lösung anbieten kann.

Ich selbst möchte aber nicht mit einem Tunnelblick durchs Leben laufen sondern das beste für meinen Kunden erreichen.

Wer bin ich und was will ich?

Es gibt viele Punkte innerhalb der Rollenbeschreibung des Product Owners welche gut zu mir passen. Ich treffe gerne selbst Entscheidungen und vertrete diese. Dabei möchte ich helfen das große und ganze im Blick zu behalten und schaue über den Tellerrand hinaus.

Allerdings bin ich auch jemand der gerne mit Menschen zusammen arbeitet und versucht Synergien zu heben. Redundante Tätigkeiten machen mich schlicht wahnsinnig. Noch mehr wurmt es mich wenn Teams in einem Unternehmen offensichtlich und bewusst in unterschiedliche Richtungen ziehen und gegeneinander arbeiten (Stichwort: Kannibalismus im Unternehmen).

Dazu kommt, dass meine tägliche Arbeit eine Bereicherung für mich sein soll auf die ich mich freue. Wenn ich ständig Arbeiten mache die ich inhaltlich und moralisch in Frage stelle fühle ich mich nicht wohl und empfinde diese als Ballast.

Dazu kommt, dass ich mich einfach freue wenn ich meine Leidenschaft als Techniker ausleben kann. Ich fasse gerne Technik an, spiele damit und probiere neue Frameworks aus. Dies mache ich weil ich mein Hobby zum Beruf gemacht habe. Ich liebe es die grenzen des technisch machbaren zu verschieben. Als PO bin ich an dieser Stelle zu weit weg und kümmere mich stattdessen um Zahlen (was ich kann mich aber kolossal langweilt).

berufliche Neuorientierung – weg mit den Schulterklappen

Bereits im November habe ich für mich die Entscheidung getroffen, dass sich etwas bei mir verändern muss. Für mich war klar dass ich einen Schritt zurück treten und die Rolle des POs abgeben möchte. Gemeinsam haben wir einen neuen Product Owner für das Team SEMMI gesucht. Nach einer Übergabe hat dieser die Rolle und die damit verbundenen Aufgaben inzwischen übernommen.

Ich selbst führe derzeit im Kern die Rolle des Technologieverantwortlichen HMI / TecCo Lead HMI in der DB aus. In dieser Rolle begleite ich aktuell die strategische Erarbeitung der Voice-Strategie für den DB Konzern. Dazu versuchen wir eine Entscheidung über die Zukunft der Conversational AI Plattformen im Hause des DB Konzern herbeizuführen.

Zum jetzigen Zeitpunkt kann ich noch nicht zu 100% sagen ob diese Rolle und die aktuelle Tätigkeit das Richtige für mich ist. Zum einen bin ich nun in der Lage die strategische Ausrichtung des Konzerns mit in die richtige Richtung zu lenken. Auf der anderen Seite bin ich auch noch technisch unterwegs und kann einzelne Lösungen benchmarken und Lösungsansätze validieren. Ich bin gespannt wie weit wir hier kommen und ob wir hierüber eine Möglichkeit haben den Kannibalismus im Bereich der Conversational AI aufzulösen …

Der Beitrag berufliche Neuorientierung – Zeit für den Reset erschien zuerst auf Das ist die Welt von Thomas.

Künstliche Intelligenz im Alltag – unsere Vision

SEMMI selbst ist im Skydeck der DB Systel entstanden. Hier kam ein ehemaliger Kollege auf eine grandiose Idee. Wir wäre es wenn wir ein System zur Verfügung hätte welches Kunden in Ihrer Muttersprache beraten könnten. Neben dem Führen einer Konversation in unterschiedlichen Sprachen stand die emotionale Komponente mit im Focus. Es sollte nicht nur ein Chatbot entstehen, nein vielmehr ist der Anspruch eine natürlicher Kommunikation unter Einbeziehung der Emotionen abzubilden.

Heute sind wir so weit dass SEMMI in der Lage ist menschenähnliche Konversationen zu führen. Neben der Beantwortung einfacher Fragen wie die Suche nach dem Weg zu einem Ziel innerhalb eines Gebäudes können komplexere Dinge wie Reiseauskünfte gegeben werden. SEMMI behält sich während der Unterhaltung den Context und stellt, sofern notwendig, Rückfragen. Unsere KI stellt natürlich nur Rückfragen zu Themen, die auf Basis das bisherigen Gesprächsverlaufes nicht bereits bekannt sind.

auf dem Weg zum Alltagshelden

Noch ist es ein bisschen hin bis SEMMI uns im Alltag begegnen wird. Wir arbeiten allerdings unermüdlich daran dieses Zeil zu verwirklichen. Der Beitrag in der Europawoche 2021 zeigt ein Beispiel wo und wie wir SEMMI unter Umständen bald erleben dürfen.

Der Beitrag Künstliche Intelligenz im Alltag – SEMMI erschien zuerst auf Das ist die Welt von Thomas.

Warum die Arbeitszeit protokollieren?

In der Anfangszeit hatte ich einen Vertrag in welchem etwas Stand wie das all meine Arbeitsstunden, auch die Überstunden, mit dem Gehalt abgegolten sind. Schön, dachte ich, somit ist es völlig irrelevant wie viele Stunden ich so arbeite und muss mir nicht den Aufwand machen diese zu protokollieren.

Ganz so ist es dann leider doch nicht. Zum einen ist da die Arbeitsrechtliche Seite der Medaille:

Unter dem Begriff der „Vertrauensarbeitszeit“ versteht man ein Arbeitszeitmodell, bei dem der einzelne Mitarbeiter selbst für die Einhaltung und aufgabengerechte Verteilung seiner Arbeitszeit verantwortlich ist; lediglich das Volumen der in einem bestimmten Zeitraum zu erbringenden Arbeitszeit wird vom Arbeitgeber festgelegt. Auf eine elektronische Zeiterfassung wird verzichtet und die Mitarbeiter können gewissermaßen „vorarbeiten“, um die vorgearbeitete Zeit – also ihre Überstunden – zu einem späteren Zeitpunkt „abzufeiern“.

Quelle: https://www.monster.de/mitarbeiter-finden/recruiting-tipps/personalmanagement/arbeitsrecht/vertrauensarbeitszeit-rechte-und-pflichten-065967/

Auf der anderen Seite haben wir, leider, in den meisten Firmen auch heute noch ein Misstrauensproblem (glücklicherweise stelle ich dies bei meinem aktuellen Arbeitgeber gerade nicht fest). Unabhängig davon welches Arbeitszeitmodell hier vorliegt hat der Arbeitgeber eher die Angst, dass die Mitarbeiter weniger arbeiten und das Bedürfnis dieses kontrollieren zu müssen. Fällt man, was die Arbeitszeit angeht, ein wenig aus dem „Rahmen“ kann es zu komischen Blicken oder auch Fragen führen.

Allein schon aus diesem Grund kann es nicht schaden, die geleisteten Arbeitsstunden in einer kleinen Tabelle „nebenbei“ mit zu erfassen.

Warum mit Excel Arbeitszeit protokollieren?

In jedem Unternehmen in welchem ich bisher tätig war, war das MS Office gesetzt. Excel ist eines der Tools welches was die Verwaltung von Tabellen angeht wohl zweifelslos am bekanntesten ist.

Dazu kommt, dass Excel wirklich einfach ist. Ich glaube jeder ist in der Lage eine kleine Tabelle anzulegen, ein paar Zahlen zu protokollieren und daraus eine Summe zu bilden. Nun ist die Arbeitszeiterfassung nun keine Raketentechnik, somit ist es recht naheliegend Excel auch hierfür zu nutzen.

Warum der Download, wenn es so einfach ist?

Natürlich kann sich jeder selbst hinsetzen und sich eine eigene Vorlage für die Arbeitszeiterfassung bauen. Doch auch dies kostet wieder unnötig Zeit. Weiterhin habe ich selbst für mich gerne ein zentrales Archiv, an welchem ich solche Vorlagen immer griffbereit habe. Meine eigene Internetseite bietet hierfür einen geeigneten Platz.

Meine Excel-Vorlage ist mit Sicherheit nicht das beste was man finden kann, hilft mir allerdings seit vielen Jahren sehr zuverlässig. Ich möchte ohne großen Schnick-Schnack einfach täglich meine Arbeitszeiten erfassen, eine Übersicht über die bisher geleisteten Stunden und Überstunden haben und im Falle des Falles Antworten auf Fragen haben.

Es freut mich, wenn ich mit meiner Vorlage dem ein oder anderen helfen kann. Falls nicht, auch gut, dann bleibt diese Seite eben mein persönliches Archiv

Was kann die Vorlage?

Da die Excel Vorlage mit Formeln und Funktionen gespickt ist, habe ich hier eine kleine Übersicht der einzelnen Funktionen gebastelt:

Im ersten Schritt geben wir einen Tag im aktuellen Monat an für welchen wir die Arbeitszeiten erfassen möchten. Anhand dieses Datums wird die Tabelle automatisch aufgebaut, die Wochentage gefüllt und die Arbeitstage berechnet.

Durch die Erfassung des Arbeitszeitbeginns, des Ende der Arbeitszeit und die durchgeführte Pause wird die Soll- und Ist- Arbeitszeit berechnet. Über die Projektspalten kann die Arbeitszeit auf einzelne Projekte verteilt werden (sofern man auf mehreren Projekten tätig ist).

Innerhalb der Tätigkeitsspalte kann per Freitext erfasst werden, was man denn getan hat. Hier können Begriffe wie „Urlaub“, „Feiertag“, „Krank“ oder „Gleittag“ eingetragen so werden. Hierdurch werden die Tage entsprechend in der Kalkulation berücksichtigt.

Neben der Übersicht der geleisteten Arbeitsstunden berechnet die Excel direkt die bisher angefallenen Überstunden und zieht genommene Gleittage automatisch ab.

Ich selbst lege je Monat eine einzelne Excel-Datei an. Nachdem ich den aktuellen Monat erfasst habe übertrage ich, zur sauberen Berechnung und Dokumentation, die Überstunden aus dem Vormonat in die Zelle B41 um die Lückenlose Dokumentation, ohne einzelne Files verknüpfen zu müssen, zu gewährleisten.

Excel Vorlage Herunterladen

Meine Excel-Vorlage zur Arbeitszeitprotokollierung steht jedem kostenlos zum Download bereit. Die Nutzung ist auf eigene Gefahr, ich übernehme keine Garantie oder Gewährleistung für die Vorlage.

Solltet Ihr bei der Benutzung Fragen haben oder auf Punkte stoßen, welche Ihr gerne ändern würdet (oder sogar geändert habt) dann wäre ich froh, wenn Ihr mich darüber auf dem Laufenden halten könntet. Vielleicht ist die ein oder andere Idee auch für mich von Nutzen und wir können die Vorlage somit nach und nach weiter optimieren

Der Beitrag Mit Excel Arbeitszeit protokollieren – eine Vorlage erschien zuerst auf Das ist die Welt von Thomas.

Was macht ein Product Owner (PO)?

Definitionen zum PO gibt es viele, wer selbst im Agilen Umfeld unterwegs ist wird die meisten kennen. Ich persönlich finde das Video von Maik Scheele, welchen ich in meiner damaligen Tätigkeit bei der ING DiBa kennen lernen durfte, sehr passend um diese Frage zu beantworten. Schaut einfach mal selbst rein:

Die wichtigsten Kernpunkte sind hier im Video schön, sowohl per Sprache als auch mit Illustrationen beschrieben.

Wem das Video zu lange dauert, hier die Kernaufgaben:

Der PO ist Eigentümer des sog. Product Backlogs, d.h. der Liste mit den Anforderungen an das zu entwickelnde Produkt. In dieser Eigenschaft hat er folgende Verantwortlichkeiten:

– Relevanz der Anforderungen im Product Backlog für den Wert der zu erstellenden Software
– Eindeutige und verständliche Beschreibung der Anforderungen im Product Backlog
– Priorisierung der Anforderungen
– Maximierung der Wertschöpfung der Arbeit des Entwicklungsteams
– Gewährleisten, dass das Product Backlog dem Entwicklungsteam als geeignete Arbeitsgrundlage zur Verfügung steht.

https://www.projektmagazin.de/glossarterm/product-owner

Wirtschaftliche Verantwortung für Produkt und Team

Die hier aufgeführte und von Maik herangezogenen Definition sprechen wir von der Definition nach Scrum. Nach meiner Erfahrung arbeitet kaum ein Unternehmen nach der reinen Definition sondern passt den Agilen Werkzeugkoffer an die eigenen Bedürfnisse an. So auch bei meinem Arbeitgeber, der DB Systel. Hier kommen zu den eigentlichen Aufgaben noch einige Führungsaufgaben so dass die Aufgabe doch um einiges Umfangreicher wird.

So trage ich auch für die wirtschaftliche Verantwortung für das Produkt und das Team. Ich muss mich also nicht „nur“ mit der Frage beschäftigen „Was“ wir im Team umsetzen sondern immer die Wirtschaftlichkeit im Blick behalten. Neben dem üblichen Managen des Backlogs muss ich den Business Case und den Salesfunnel jederzeit im Blick behalten. Tools wie Excel und Salesforce gehören inzwischen zu meinen täglichen Arbeitsinstrumenten.

Wie fühlt es sich für mich an?

Rein von der Ausbildung her fühle ich mich auf dem IT-Bereich und in der IT-Architektur erstmal sehr wohl. Der Slogan „ITler aus Leidenschaft“ passt einfach zu mir. Der jetzige Switch weg von der Entwicklung und eher hin zum Business ist nicht einfach aber er lohnt sich. Natürlich fühle ich mich an einigen Stellen hier und da stark gefordert, dennoch lerne ich täglich viel neues.

Früher hatte ich immer den Eindruck ich könnte nichts ändern und wäre am ende der Nahrungskette nur das ausführende Organ. Vorschläge und Anregungen wurden nicht ernst genommen und man lief oft, obwohl man dies quasi vorhersagen konnte, gegen die Wand. Die neue Rolle des Product Owner erweitert um die Führungsaufgaben ist in der Tat sehr Anspruchsvoll aber fordert mich.

Geduld ist eine Tugend vom Product Owner

Eine weitere besondere Herausforderung bei der Ausübung des POs ist es, dass ich jetzt eben nur noch über das „Was“ spreche und nicht mehr über das „Wie“. In einer Anforderung (Userstory) nur noch die Anforderung selbst (mit funktionalen und nicht funktionalen Anforderungen / Akzeptanzkriterien) zu formulieren ohne auf die Umsetzung selbst Einfluß zu nehmen fällt mir natürlich nicht leicht.

Glücklicherweise bin ich inzwischen in der Situation dass ich durchaus etwas wie Geduldig sein kann. Ich halte es aus wenn es mir mal nicht schnell genug geht und ein Feature anstatt dem geplanten einem Sprint eher 3 Sprints dauert.

Jeder der selbst aus der Softwareentwicklung kommt und die Rolle des Product Owners übernimmt kennt die Situation. Es ist keine einfache aber diese ist lösbar

Der Beitrag Product Owner – Was ist eigentlich mein Job? erschien zuerst auf Das ist die Welt von Thomas.

Warum selbstorganisierte Teams?

Schauen wir doch als erstes Mal in das „Agile Manifest“ welches die Leitlinien der Agilen Arbeitsweise setzt und beschreibt. Hier finden wir folgende Aussage:

Die besten Architekturen, Anforderungen und Entwürfe entstehen
durch selbstorganisierte Teams.

Quelle: Agiles Manifest

Ein selbstorganisiertes Team ist ein Team, welches sich durch die Zusammensetzung der Personen in die Lage versetzt, wesentliche Rahmenbedingungen selbst zu bestimmen und zu leben. Das Team organisiert seine Arbeitsabläufe selbst und bekommt die Verantwortung für die prozessuale Steuerung übertragen.

Das Team trägt die Verantwortung für das im Team verortete Produkt.

Ein selbstorganisiertes Team ist im Grunde also eine Einheit welche sich, wie es der Name schon sagt, selbst organisiert. Hierunter fallen unter anderem Dinge wie die Priorisierung der Aufgaben, die Definition der Arbeitsweise aber Punkte wie die Zusammenarbeit mit anderen Teams.

Zusammenarbeit zwischen Teams gewährleistet?

Synergien innerhalb des Konzernes müssen genutzt werden – so zumindest mein Leitbild. Der gemeinschaftliche Erfolg überwiegt immer den eigenen. Die Zusammenarbeit zwischen Teams ist essenziell für den Erfolg eines Unternehmens. Nur wenn wir als Teams wirklich offen miteinander arbeiten, zueinander offen und ehrlich sind und versuchen entstandene Lösungen und vorhandenes Wissen gegenseitig zu nutzen entsteht das beste Produkt.

Was ist aber, wenn jedes Team nur seine eigenen Ziele verfolgt? Wenn gar aus der falschen Interpretation eines „selbstorganisierten Teams“ eine echte Konkurrenzsituation entsteht anstatt, dass die Zusammenarbeit gefördert wird?

Ist es nicht sogar logisch, dass selbstorganisierte Teams, je nach Definition dieser Selbstorganisation, eher Konkurrenten als Partner sind?

In vielen Gesprächen mit Personen aus unterschiedlichen Unternehmen stellte ich fest, dass die fehlende Zusammenarbeit allgegenwärtig ist. Meist arbeiten die Agilen Teams (egal ob Scrum oder Kanban) nebeneinander her, alle mit ihrem eigenen Ziel. Selten sind die Ziele zwischen einzelnen Teams abgestimmt, im schlimmsten Fall widersprechen sich selbige.

Vorsicht vor Kannibalismus im Unternehmen

Es ist keine Seltenheit, dass in unterschiedlichen Teams die gleichen fachlichen Lösungen entstehen. Nach der Produktivsetzung werden diese dann als Konkurrenzprodukte im Unternehmen angesehen werden. Der „Kampf“ welche Lösung sich durchsetzt wird mit ausgefahrenen Ellenbogen auf unterer Ebene ausgetragen – das Miteinander ist zerstört.

Ich nenne das den „Kannibalismus im Unternehmen“. Der Focus des Handelns liegt nicht mehr darin das Beste für das Unternehmen zu tun. Das Handeln wird durch die eigenen Ziele jedes einzelnen Teams bestimmt – das große Ganze gerät aus dem Focus.

Wir, zumindest sollten es, sind in der Lage von vergangenen Fehlern zu Lernen. Hierbei müssen wir nicht alle Fehler selbst machen, auch eine Beobachtung oder eine Erzählung genügt. Ich erinnere mich z.B. an eine Geschichte von meinem Vater bei welcher er mir erzählte wie er gelernt hat, dass man im Topf kochendes Wasser nicht anfassen sollte. Das reine zuhören genügte um daraus zu lernen und zu wissen, dass dies auf der „not ToDo-Liste“ steht.

Teams, welche nicht miteinander, sondern nebeneinander oder sogar gegeneinander arbeiten können nicht voneinander lernen. Erfahrungen werden nicht geteilt und Fehler wiederholen sich. Wir müssen voneinander lernen um besser zu werden. Nur die wirkliche und ehrliche Zusammenarbeit sorgt dafür, dass wir nicht ständig die gleichen Fehler machen.

Selbstorganisierte Teams – wo ist die Grenze?

Natürlich befürworte ich die Arbeit in einem selbstorganisierten Team. Die Vorteile der freien Arbeitsweise überwiegen klar den möglichen Nachteilen. Fraglich ist für mich nur, wie viel Selbstorganisation den Teams überlassen werden sollte.

Aus meiner Sicht ist spätestens beim Business-Case, also der wirtschaftlichen Verantwortung, Schluss. Agile Teams, welche aus 5 bis 10 Personen bestehen sind, aus meiner Sicht, als Einheit zu klein als dass diese die wirtschaftliche Steuerung selbstständig übernehmen sollten.

Obliegt diese Steuerung den Teams selbst so ist die Zusammenarbeit mit anderen Teams nicht mehr im Focus. Der Kannibalismus beginnt.

Aus meiner Sicht muss genau an dieser Stelle ein organisatorischer Überbau geschaffen werden, welcher diese Situation verhindert. Die Zusammenarbeit der Teams und die Nutzung der vorliegenden Synergien muss ein Kriterium für die Erreichung der wirtschaftlichen Ziele sein. Zusammenarbeit muss die Pflicht und keine Option sein.

Teams, welche die gleichen Themen bearbeiten aber auf unterschiedliche Ziele einwirken (sei es nun ein strategisches oder wirtschaftliches Ziel) sollte es nur in absoluten Ausnahmefällen gegeben.

Der Beitrag Selbstorganisierte Teams – Kannibalismus im Unternehmen? erschien zuerst auf Das ist die Welt von Thomas.