agilophil Podcast - agile Entwicklung für Dich Archiv

Agilität ist ja bekanntlich keine Methode, sondern ein Mindset. Was macht das Mindset aus?

Bestandteile sind - jetzt mal etwas ungeordnet:

Selbstorganisation,

Eigenverantwortung,

Pullprinzip,

Inspect and Adapt,

ständige Verbesserung,

Commitment,

Respekt,

Mut,

Fokus,

Offenheit

...

Wenn wir das alles auf unser Privatleben übertragen, dann müssten wir eigentlich alle vollkommen zufrieden und sorgenfrei leben…Das Glück wäre auf unserer Seite und Wohlstand kommt von ganz alleine … stimmt das?

Ständig wiederkehrenden Aufgaben, die im Haushalt zuverlässig erledigt werden sollen - dazu passt Kanban! - Ein Kanban-Board am Kühlschrank mit den Aufgaben der Woche in der Input Queue schafft Transparenz und schult die Eigenverantwortung.

Ein Urlaub ist ja sowas wie ein besonderes Projekt der gesamten Familie - dazu ist es vorteilhaft mal ein paar Blicke ins Scrum-Framework zu werfen. Das Ziel, die Roadmap, die Planung und das Review/Refinement sind Elemente, die Du auch in einem Familienurlaub gut einsetzen kannst - oder tust Du das in gewisser Weise vielleicht sogar schon?

Das agile Mindset ist nichts anderes als “angewandter gesunder Menschenverstand” und irgendwie machen die meisten von uns das doch sowieso.

Ich wünsche schöne Ferien

Dein agilophiler Frank

Fokus durch Automatisierung

Darüber unterhalte ich mich in dieser Folge des agilophil-Podcasts mit dem Automatisierungsexperten Santino Giese.

Wir gehen gemeinsam die lästigen Dinge durch, die Dir als Unternehmer*in den Fokus rauben. Getreu dem Motto "mach nur das, was Du liebst und am besten kannst", macht es Sinn dich von den Aufgaben zu befreien, die dich genau davon abhalten.

Dazu gehen wir an einem angenommenen Startup-Beispiel mal die unternehmerischen Themen durch, wie

Personalwesen

Marketing

Vertrieb

Buchhaltung, Kostenrechnung

Kundensupport

All diese Dinge lassen sich gravierend vereinfachen, wenn Du die Power der Automatisierung nutzt.

Denn du als Startup-Unternehmer*in ein neues Produkt entwickeln willst, musst du dich voll auf diese Aufgabe konzentrieren - Focus gehört ja auch zu den agilen Werten. Wer sich nur auf sein eigenes Produkt konzentriert, hat aber für die anderen Themen keine Zeit…womit wir beim Thema Engpass wären. Löse diesen Engpass auf durch Automatisierung.

Du erreichst Santino Giese über seine Webseite https://santino-giese.com

Du kannst mit ihm gleich einen Termin vereinbaren

Hier noch die Links zu den angesprochenen Tools (jeweils mit Alternativen, da dies keine Werbung darstellen soll):

Kontakte - LinkedIn: Expandi (Alternative dazu Waalaxy)

Social Media Planner: hootsuite (Alternative dazu - Publer )

Marketing - Email: klicktipp (Alternative Quentn)

Echtes Beispiel für Fitness-Produkt: "imakeyousexy.com"

Buchhaltung - Rechungseingang: Datev Unternehmen online, getmyinvoices.com

Lexoffice, Sevdesk

Kleiner Hinweis noch zum Schluß: Bei dieser Episode ist die Soundqualität durch ein technisches Problem bei der Aufnahme nicht optimal. Sorry for that...aber dafür ist der Inhalt umso spannender ;-)

Wenn dein Produkt größer wird, werden Aufgaben komplexer. Von einer einfachen, kleinen App für ein paar Kunden auf einem Betriebssystem wird irgendwann eine große Anwendung - vielleicht auch eine Plattform für viele User, vielleicht 100tausende oder Millionen in unterschiedlichen Welten (wie iOS und Android , Apple, Window, Unix...)

Die Anforderungen wachsen also und dein agiles Team mit seinen idealerweise 7 Leuten kommt an seine Grenzen…

Was also tun?

Die Antwort liegt auf der Hand - du brauchst ein zusätzliches Team: Doch wie vorgehen?

In diesem Podcast zeige ich Dir 4 Varianten, wie du deine Teams skalieren kannst und welche Vor- und Nachteile das hat:

Im Grunde genommen hast du 4 Möglichkeiten:

Split and Groworganisches WachstumTeam SeedingWillkommensteam

Gehe dabei auf jeden Fall strategisch vor, lasse dein Team nicht einfach so wachsen. Und vertraue auf die Kompetenz eben deines Teams: Löse die Aufgabe der Skalierung des Teams nicht für dein Team, sondern mit deinem Team zusammen.

Alles andere birgt die Gefahr von Konflikten und Motivationsverlust.

Viel Spaß

Dein agilophiler Frank

Wann hast du zum letzten Mal ein neues Produkt entwickelt? Womit hast du dabei angefangen?

Damit die Features zu überlegen, die das neue Produkt haben sollte vielleicht?

klingt erstmal nicht schlecht…

doch ist das eigentlich geschickt und sinnvoll?

Die Frage ist letztlich - wie kommen wir an unser Backlog, das wir brauchen, um das Produkt zu entwickeln? In dieser Folge erfährst du wie du in 6 Schritten über eine Roadmap zu einem perfekten Backlog kommst, mit dem du Kunden und Investoren überzeugen kannst.

Ich bin sicher, dass du mit einer outcomebasierten Roadmap besser fährst als mit einer klassischen feature-basierten. Auch wenn die Messbarkeit am Ende schwieriger ist und die Erkenntnisse vielleicht länger dauern, so wirst du näher am Kunden sein und den Zweck deines Unternehmens besser erfüllen können. Denn darum geht es ja.

Dein agilophiler Frank

Ist Scrum auch Lean? Ist Lean eigentlich agil? Was ist Lean eigentlich?

"Lean Thinking" war eine Welle, die in den 1990er Jahren durch die Management-Abteilungen der Unternehmen schwappte: Grundgedanke ist dabei die Vermeidung von Verschwendung gemäß der Maxime von James P. Womack und Daniel-T. Jones, den Autoren des Buches “Lean Thinking”

“Jede Tätigkeit, die ohne Wertschöpfung Ressourcen verbraucht, ist Verschwendung.” 

Der Begriff “Lean” wurde im Westen geprägt und bezieht sich im Wesentlichen auf die Grundlagen des “Toyota Production Systems”, das in den 1980er Jahren Furore machte. 

“Lean is a mindset - a mental model how the world works” ist ebenfalls ein Zitat und zwar von Mary Poppendieck aus den frühen “nuller” Jahren…

Nun gibt es viele verschiedene Autoren und Torsten Scheller hat in seinem dicken Buch “Auf dem Weg zur Agilen Organisation” viele davon unter die Lupe genommen - daher auch die folgende Zusammenfassung daraus:

Lean basiert auf 4 allgemeinen Prinzipien, die alle das Ziel haben Verschwendung zu vermeiden:

Mache nur Dinge, die Wert schaffenErmächtige die Leute “vor Ort”Reagiere unmittelbar auf KundenRealisiere einen schnellen Durchlauf basierend auf den Anforderungen (also das “Pull-Prinzip”).

In Scrum werden alle Lean Prinzipien erfüllt und so kann ich die die Frage „ist Scrum auch Lean?“ uneingeschränkt mit ja beantworten. Es sind alles Kinder aus dem selben Elternhaus. Oder anders ausgedrückt: Es macht wenig Sinn eine agile Methode gegen eine andere auszuspielen. Da es sich schlicht nicht um Methoden handelt. Es ist immer das selbe Mindset , das dahinter steht. Und genau um das agile Mindset geht’s, wenn Du in deinem Team oder in deinem Unternehmen voran kommen willst.

Viel Spaß beim Zuhören

Dein agilophiler Frank

Was ist eigentlich ein Scrum Master? Worin unterscheidet sich die Rolle Scrum Master von einem Projektmanager?

Und was macht einen Scrum Master zu einem erfolgreichen Scrum Master?

Ein Problem klassischer Projektorganisation ist ja, dass es eine Rolle des Projektleiters gibt, die für alles verantwortlich ist. Gemeint ist für den Projekterfolg. Das ist genau der Punkt. Wenn es einen Menschen gibt, der für den Projekterfolg verantwortlich gemacht werden kann, dann möchte der Eine auch diesen Erfolg absichern. Das kann zu Entscheidungen und Methoden führen, die dem Projekt selbst am Ende gar nicht gut tun.

Und der Begriff Erfolg ist dehnbar…Mit ein paar Change Requests, mit genehmigten Budgeterhöhungen oder Zeitverschiebungen können wir vieles abfedern und so den Erfolgsbegriff verwässern.

Das erfolgreiche Projekt ist irgendwann mal live gegangen und konnte dann abgerechnet und beendet werden. Aber ist das dann noch erfolgreich? Nutzt jemand das Produkt?

Merkst Du, wo hier der Denkfehler steckt?

Es geht gar nicht um Projekte….es geht um Produkte!

Es geht darum ein Produkt ins Leben zu bringen - und so weiterzuentwickeln, dass es ein erfolgreiches Produkt wird und den Kunden oder Anwendern Probleme löst, Herausforderungen stellt oder schlicht Spaß macht!

Und dafür brauchen wir eine Rolle, die verantwortlich ist für den Erfolg des Teams als Ganzes - sowas wie ein Trainer, Coach und Beschützer, der dafür sorgt, dass das Team immer besser werden kann. Das ist die Rolle des Scrum Masters!

Ein Scrum Master ist keine Führungskraft, die auf Grund von Macht und Hierarchie führt. Er oder Sie führt auf Basis ihres Einflusses - ein wesentlicher Aspekt dabei ist vorbildliches Verhalten, Führen aus dem Hintergrund. 

Daher kommt auch die Haltung, die ich bei vielen erfolgreichen ScrumMastern sehe: Eine Haltung, die sagt „Ich mache die Anderen groß.“ 

Daher ist es auch gut und wichtig die Anderen machen zu lassen. Insbesondere die Entwicklung zu einem selbst gemanagten Team ist genau so ein Punkt. 

Experimente wagen, kontinuierliche Verbesserung über einen längeren Zeitraum erzielen. Du als Scrum Master:in solltest deinen Einfluss geltend machen, dein Team und dich selbst in diese Richtung zu entwickeln. Das Team muss lernen dem Prozess zu vertrauen. Und Du bist Meister:in des Prozesses Scrum - ein Scrum-Master

Dann bist Du auch erfolgreich ;-)

Dein agilophiler Frank

Ist ein Scrum Master eigentlich eine Führungskraft?

Gibt es überhaupt Führungskräfte in einem agilen Team? Sollen die nicht immer selbst-gemanaged sein?

Im Scrum Guide steht tatsächlich ganz konkret dieser Satz: "Scrum Master sind echte Führungskräfte, die dem Scrum-Team und der größeren Organisation dienen."

Also doch - des gibt Führungskräfte in Scrum Teams - es sind also die sogenannten Servant Leaders - die dienenden Führungskräfte, die nicht nach Command and Control Dinge vorgeben, sondern den Boden bereiten, so dass das Team und die Organisation den höchsten Mehrwert beisteuern kann.

Aber ist das nicht zu einfach?

Bekannt und beliebt ist das Konzept der Situativen Führung: Das Modell beruht auf der Erkenntnis, dass ein Führungsstil zum Skill-Level einer Gruppe passen muss, sonst wird es nicht funktionieren.

Wenn Du erkennst, auf welchem Level sich Dein Team bewegt, dann kannst Du deinen Führungsstil entsprechend darauf einstellen:

Das Team auf dem Level 1 ist unsicher und es fehlt noch am Wissen über agile Methoden und Praktiken. Es fehlt auch noch an Vertrauen in diese neue Art zu Arbeiten. Diese Unsicherheit kannst Du beheben, indem Du klar den Rahmen vorgibst, der Führungsstil ist "Telling" - also Anweisen: Wichtig ist, dass Du die Ziele nicht zu hoch setzt. Auch der Umfang des Projekts sollte nicht zu groß sein.

Ein Team auf Level 2 hat noch wenig Wissen, aber ein gewisses Selbstvertrauen: Der passende Führungsstil wäre "Selling". Auch hier gibt die Führungskraft die Richtung vor, aber die Kommunikation geschieht als Gespräch in dem die Führungskraft ihre Überzeugungskraft einsetzt und so dafür sorgt, das Team die Aufgabe aus voller Überzeugung übernimmt - sie also quasi abkauft.

Ein Team auf Level 3 hat das nötige Wissen, aber noch nicht das volle "Empowerment" sich die Welt für sich zu gestalten. Der passende Führungsstil wäre "Partizipating". Es werden Entscheidungen gemeinsam getroffen.

Auf das oberste Erfahrungslevel 4 passt der Führungsstil "Delegating", bei der die Aufgabe komplett an das Team übergeben wird. Hilfe kommt nur bei Nachfrage, ansonsten läuft alles von alleine.

Wie ist Dein Level - zum Beispiel als Scrum-Master:in?

Viel Erfolg bei Entwickeln deines Teams

Dein agilophiler Frank

Ein Klassiker des agilen Coachings sind die 5 Dysfunktionen eines Teams von Patrick Lencioni: 

Fehlendes VertrauenScheu vor KonfliktenFehlendes EngagementScheu vor VerantwortungFehlende Ergebnisorientierung

Es gibt aber noch einen anderen Klassiker im Coaching-Bereich und das ist die Bedürfnispyramide von Maslow:

Physiologische BedürfnisseSicherheitsbedürfnisseSoziale BedürfnisseIndividualbedürfnisseSelbstverwirklichung

Wenn es der Sinn des Lebens ist, ein Teil eines effizienten Teams zu sein, dann wird man in der Lage sein, die persönlichen Bedürfnisse zurück zu stellen und die Teamergebnisse vor die eigenen Ziele zu stellen. Das klingt allerdings ein wenig pathetisch - aber das ist schon ziemlich hoch. Genau darum ist es auch nicht selbstverständlich zu einem High Performance Team zu gehören. 

Und es ist erst recht schwierig so ein Team zusammenzustellen und zu entwickeln. Eine Garantie gibt es da nicht und einen sicheren Weg auch nicht. 

Dein agilophiler Frank

Was ist ein Impediment? Übersetzt ist ein Impediment ein Hindernis, dass sich einem in den Weg stellte und so den Fortschritt erschwert. Bei der Arbeit - vor allem bei Kanban und Scrum, steht die Effizienz hoch im Kurs. Wir wollen die Sache schließlich richtig machen. Mit wenig Einsatz schnelle Ergebnisse liefern. Und daher gibt es in Scrum ja auch vielfältige Feedbackschleifen für das Team um an der Effizienz zu arbeiten. Ein gut eingespieltes Team erledigt seine Arbeiten zuverlässig in einer konstant hohen Geschwindigkeit…soweit so gut.

Wenn da nicht die reale Welt wäre, die einem den ein oder anderen Stock in die Speichen steckt. Denn Hindernisse lauern überall. Und sie sind immer da. Allerdings wird das oft genug verdrängt. Oder unter den Teppich gekehrt. Da unangenehm…

Nun steht das Wort Impediment im Scrum Guide - sogar an mehreren Stellen - und meistens in Verbindung mit der Rolle Scrum-Master.

Ein Scrum Master hilft dem Team auf verschiedene Weisen:

Scrum Praktiken und Werte vermitteln,

Selbstmanagement lernen,

sich auf das Schaffen von Nutzen im Sprint zu fokussieren und

Er oder sie hilft dem Team bei der Beseitigung von Hindernissen , die den Fortschritt des Scrum-Teams verlangsamen.

Impediments können klar, banal oder auch schwerwiegend sein. Und es sind nicht alles Dinge, die nicht vom Team selbst gelöst werden können.

Ein Scrum Master soll das Team bei der Beseitigung der Impediments helfen. Das bedeutet nicht, dass in einer Spalte „Verantwortlich“ der Liste der Impediments nun überall der Scrum Master stehen muss. Viele Dinge können vom Team selbst gelöst werden - eben mit Unterstützung des Scrum Masters.

Daher denke groß, wenn Du Scrum Master:in bist. Lasse dich nicht auf eine Projektassistenz reduzieren, sondern nutze die Hindernisse, die dein Team hat, dafür, die gesamte Organisation in Richtung Agilität zu verändern. Das ist nicht wenig und das wird lange dauern - aber das macht Spaß.

Dein agilophiler Frank

Am 28. und 29. April 2022 fand die (Fr)agile Earth Action - Open Space conference, online statt. Neben dem netten Headliner - dem Wortspiel „(Fr)Agile Earth - hatte die Veranstaltung den Untertitel „Z’sammen scrummen für 1,5 Grad“.

Vom Titel her ansprechend, dachte ich - und ich habe mich angemeldet...

Open Space ist eine Idee von Harrison Owen aus dem Jahr 1985 - also auch nicht mehr ganz jung. Ausgehend von der Erkenntnis, dass die Kaffeepausen bei Kongressen und Veranstaltungen immer der nützlichste Teil sind, hat er eine Methode entwickelt, Veranstaltungen für komplexe Fragestellungen zu organisieren:

Den Open Space.

Selbstorganisation ist dabei Trumpf: Alle Themen werden erst zu Beginn der Veranstaltung gesammelt - so entsteht der Themen-Marktplatz und alle bekommen einen Überblick über das, was passiert.

Es werden Sessions abgehalten und dazu gibt es folgende Regeln:

Wer auch immer kommt, es sind die richtigen Leute.Was auch immer geschieht, es ist das Einzige, was geschehen konnte.Es beginnt, wenn die Zeit reif ist.Vorbei ist vorbei - nicht vorbei ist nicht vorbei.

und das"Gesetz der zwei Füsse": Wenn Du feststellst, dass du bei einer Gruppe weder etwas lernen kannst, noch etwas beizutragen hast, dann kannst Du gehen und dir eine andere Gruppe anschauen.

Das ist das Gute daran. Es ist nicht vorher geplant - es geht nur um ein generelles Thema. Die Vielfalt der Sessions bringt einen großen Gewinn - neue Themen kommen hoch, mit denen Du dich beschäftigen kannst. Neue Impulse — teilweise aus einer ganz anderen Richtung - erweitern den Horizont.

So. und jetzt mal zu der (Fr)agile Earth Action - Session:

Wie zu erwarten entstand ein breites Spektrum an Themen, die im engeren und weiteren Sinne mit der Einhaltung des 1,5 Grad Zieles zu tun haben. Wie zum Beispiel: 

Fachkräftemangel in Handwerk und Produktion, 

Mieten statt kaufen - wie kann man sowas fördern, 

Experiment-Ideen zu besserer Klimaberichterstattung - dieses Thema wurde vorbereitet von Maren Baermann von der Initiative „Klima vor 8“, 

Wie kann man Politiker:innen/Verwalter:innen und Menschen besser erreichen?

ein Brainstorming über minimale Änderungen, die nicht weh tun. 

Carsharing - wie und warum es funktioniert und wie wir es weiter promoten können. sowie

Schnelle "Scope 3" Erfolge erzielen in der Industrie

Wenn Du mehr dazu wissen möchtest, hier der Link zum Event: https://www.linkedin.com/events/fr-agileearthaction-z-sammenscr6872284808505040896/about/

Vielen Dank an Corinna Lechler, Doris Weißgerber, Jan Fischbach und Pierre Smits für die Organisation.

Dein agilophiler Frank

Was ist eigentlich ein hochperformantes Team und welche Voraussetzungen kannst Du schaffen, damit Dein Team auch dazu gehört?

Da ich in Berlin wohne, habe ich hier auch gleich 2 passende Beispiele: Hertha BSC und Union Berlin.

Unterschiedlicher können die Ausgangssituationen nicht sein: Union - Aufsteiger in der letzten Saison mit einem eher 2.Liga -Etat und Hertha - seit vielen Jahren von einem großzügigen Geldgeber unterstützer Traditionsverein mit hohem Anspruch als "Big City CluB"...doch was passiert?

Union performt und performt, zieht fast ins DFB-Pokalfinale ein und spielt wahrscheinlich nächstes Jahr in Europa. Und Hertha? Seit einigen Jahren mehr schlecht als recht. Letztes Jahr dem Abstieg noch eben von der Schippe gesprungen und dieses Jahr sieht es nicht besser aus...

Woran liegt das? Am Geld auf jeden Fall nicht!

Auf jeden Fall ist es klar - es gibt kein einfaches Rezept ein Team performant zu machen. Als Scrum-Master:in kannst Du aber Voraussetzungen schaffen, die es leichter machen:

partizipative Führung

minimaler und passender Prozess

gute Zusammenarbeit

sich gegenseitig respektieren

einander vertrauen

mit Fokus und Dringlichkeit nutzen

Konflikte manager und nicht vermeiden

...es sind sicher noch ein paar weitere Dinge hilfreich, aber das wichtigste ist: Es macht Spaß!

Es macht Spaß in einem hochperformanten Team zu arbeiten und genau zu wissen, dass wir es schaffen! Diese hohe Moral, dieses Gefühl dazuzugehören, das macht Spaß.

Und das ist nicht mit Geld zu bezahlen...

Dein agilophiler Frank

Was wäre, wenn Agilität und Scrum nicht nur im Bereich der Software - oder Produktentwicklung eingesetzt wird, sondern für unser Land - wie wäre es, wenn wir ein agilophiles Deutschland hätten? Also - es ist Ostern und ich spinne hier einfach mal ein bisschen rum…

Fangen wir mal an: Wir brauchen ein Produktziel:

Für Deutschland könnte man das ja aus Sicht einer fiktiven Regierung vielleicht so formulieren

Wir bieten unsere Lösung für die in Deutschland lebenden Menschen……die nachhaltig glücklich in Frieden, Freiheit, Wohlstand leben wollenUnser Produkt ist ein agilophiler Regierungsservice……der zielgerichtet die gemeinsamen Grundbedürfnisse der Menschen nachhaltig befriedigt und verbessert.Anders als die Opposition (ich lasse das hier einfach mal so pauschal stehen)……arbeitet unsere agilophile Regierung in schnellen Zyklen entsprechend dem inspect and adapt Prinzip und sorgt für eine ganzheitliche und pragmatische Umsetzung der wichtigsten Themen, die für eine kontinuierliche Verbesserung des Lebens aller Menschen in unserem Lande und der Welt relevant sind. 

Als nächstes brauchen wir Leute, die daran arbeiten. Wir werden ob der Größe des Projekts in einem skalierten Umfeld arbeiten:

Nehmen wir mal als Chief Product Owner den Bundeskanzler 

Und als Product Owner die jeweiligen Minister:innen der 15 einzelnen Ministerien.

Und wir brauchen ein gemeinsames Backlog, wenn wir integriert zusammenarbeiten wollen. Nicht 15 einzelne Backlogs - die dann jeweils individuell in irgendeine Richtung laufen. 

Wie schnell sich Rahmenbedingungen ändern können, sehen wir in unserer aktuellen Zeit. Der Einfluß von Corona ist noch nicht zu Ende, da kommt ein Krieg in Europa, der für völlig neue Einschätzungen sorgt.

Plötzlich verlangen die Ziele Frieden und Freiheit besondere Aufmerksamkeit und das muss sich in unserem Backlog widerspiegeln. Neue „Features“, die vorher im Backlog sehr weit unten standen, rücken zwangsläufig nach oben. 

Was mir allerdings noch fehlt ist die Rolle des Experten für die Methode - also die Rolle Scrum Master

Ich habe so ein bisschen das Gefühl, das sowas auch für die Bundesregierung eine gute Idee ist. Ich bin mir nämlich nicht sicher, ob die Meetings der Politiker immer effizient ablaufen, ob die Timeboxen eingehalten werden und ob immer in Richtung des Meetingziels gearbeitet wird. 

OK, das ist nur ein Gedankenspiel...

Ich wünsche Dir frohe Ostern und eine friedliche Zeit, auch in einer verrückt spielenden Welt.

Dein agilophiler Frank

Im Geschäftsleben brauchen wir Verträge - und wir nutzen Verträge überall, auch wenn wir das gar nicht bemerken. Mündliche Abmachungen sind ebenso rechtlich gültige Verträge, wie der berühmte Handschlag. Nur ist es halt dann vor Gericht immer schwer nachzuweisen, was eigentlich besprochen worden ist…das macht die Sache dann weniger sicher und daher unpraktisch. Daher ist es üblich die Bedingungen in einem Vertrag schriftlich festzuhalten.

Wenn Du mit Deinem Team für ein Unternehmen eine Individualsoftware baust, wird Dein Kunde mit Dir festlegen wollen, was er bekommt und was das kostet.

Die grundsätzliche Frage, die sich immer stellt: Haben wir einen Werkvertrag oder einen Dienstvertrag?

Obwohl im allgemeinen der Werkvertrag auch für Software immer noch gängig ist, hat er doch extreme Nachteile für agile Projekte, denn agil ist in einem Werkvertrag schlicht nicht vorgesehen. 

Wenn Dein Kunde allerdings mit agilen Methoden nicht vertraut ist, wird er davon ausgehen, dass er mit der Software ein fertiges Produkt kauft (so wie es ja meistens bei anderen Produkten auch der Fall ist - man kauft ja auch kein unfertiges Auto).

Beim Dienstvertrag, der die Tätigkeit der Softwareentwicklung beschreibt, liegt das Risiko mehr auf der Seite deines Kunden - beim Werkvertrag mehr auf deiner Seite. Es macht also Sinn über Verträge nachzudenken, bei denen die Sache etwas ausgeglichener ist:

Sowas wäre zum Beispiel:

Profit Sharing

Pay per Use

Proviant und Prämie

oder eine Bezahlung nach Produktivität. Letztlich gibt es noch Modelle, wie den agilen Festpreis, Change for Free und Money for nothing.

Aber, egal, welche Vertragsgestaltung du anstrebst, ohne ein Willen zur Zusammenarbeit auf beiden Seiten wird kein Vertragsmodell funktionieren. Verträge sind nicht dafür da unfaires Verhalten festzuschreiben. Knebelverträge nutzen niemandem - erst recht nicht im agilen Umfeld. „Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlungen“ - so steht es schließlich im agilen Manifest.

Dein agilophiler Frank

Schöne Welt hin oder her - wenn du Unternehmer:in bist, gibt es immer wieder notwendige Tätigkeiten, die gemacht werden müssen, egal ob sie nun Spaß machen oder nicht - egal ob sie agil sind oder nicht - und egal ob sie deine Kunden voran bringen, oder nicht.

Dabei helfen dir Tools - also Werkzeuge, die dir das Leben leichter machen können. Darum geht es in der heutigen Folge:

Warum sollst du dich mich mit Dingen beschäftigen, die…

...dich nicht interessieren....den Kunden nicht weiter bringen, weil es letztlich keine Lösung seines Problems darstellt....lästige Fleißarbeiten zum Beispiel im Rahmen der Qualitätssicherung und Wartbarkeit darstellen, die gemacht werden müssen, aber von kaum jemanden geliebt werden....von jedem anderen durchgeführt werden können, da sie dein Fachwissen nicht brauchen - auch wenn du es selbst könntest....von anderen viel besser durchgeführt werden können, weil sie das Fachwissen haben, das du selbst nicht hast.

Egal, was - es geht darum, dass du Tools für Deine Arbeit nutzt und zwar so, dass sie dir Arbeit abnehmen. 

Damit erreichst du

Automatisierung (die Maschine kümmert sich um Dinge, Du oder Dein Team müsst es nicht selbst tun)

Transparenz (also zentrale Datenhaltung und Übersicht - nie mehr 2 Doppelte Excellisten von denen eine veraltet ist)

Rechtssicherheit (Excel ist nicht rechtskonform!)

Messe den Wert deiner Tools in Stunden, die du statt vor dem Rechner besser im Garten oder auf dem Balkon verbringen kannst - oder gleich im Urlaub. Denn deine eigene Zeit ist mit Geld fast nicht zu bezahlen…ein Tool aber schon.

Dein agilophiler Frank