Vertragsverhandlungen<\/span><\/span>. Wir sollten die Software entwickeln, die unser Kunde braucht, nicht die, die wir am Anfang mit ihm vereinbart haben.<\/p>\nAuch die Entwicklung von Standardprodukten, bei denen wir weniger auf konkrete Kundenanforderungen, sondern viel mehr auf Anforderungen eines bestimmten Markts eingehen m\u00fcssen, lebt von einer hohen Ver\u00e4nderungsbereitschaft. Was Anfang des Jahres eine gute Idee war, muss es jetzt gar nicht mehr sein, weil sich um uns herum so viel ver\u00e4ndert hat. Da m\u00fcssen wir uns anpassen. Und das betrifft nicht nur die Entwicklungsabteilung im Unternehmen! Auch andere Unternehmensbereiche m\u00fcssen reagieren, mitziehen zusammenarbeiten. Es gilt Ver\u00e4nderungen zu erkennen und gemeinsam die neue Richtung festzulegen.<\/p>\n
<\/p>\n
\u00c4nderungen \u00fcberstehen<\/h1>\n
Im agilen Manifest sprechen wir auch davon, dass Individuen und Interaktionen<\/span> wichtiger sind als Prozesse und Werkzeuge<\/span><\/span>. Ein fixierter Prozess hilft mir nicht dabei, eine \u00c4nderung zu erkennen oder mit ihr umzugehen. Im Gegenteil, mit Hilfe eines Prozesses kann ich mich zur\u00fcckziehen und die Ver\u00e4nderung ignorieren und das auch noch gut begr\u00fcnden. Hieraus entstehen dann Aussagen, die sicherlich jeder von euch schon mal geh\u00f6rt hat:<\/p>\n\n- „Das haben wir schon immer so gemacht!“<\/li>\n
- „Da steht aber, dass ich das so machen soll, also mach ich das so!“<\/li>\n
- „In meinem Arbeitsvertrag steht nicht, dass ich diese Aufgabe machen soll!“<\/li>\n<\/ul>\n
Wenn wir auf Ver\u00e4nderungen nicht eingehen wollen, f\u00e4llt es uns leicht Argumente daf\u00fcr zu finden, warum wir dieser Ver\u00e4nderung nicht folgen m\u00f6chten. Nicht alle sind so offensichtlich wie die oben genannten Beispiele.<\/p>\n
Eine Ver\u00e4nderung an sich macht uns keine Angst. Ver\u00e4nderungen f\u00fchren aber dazu, dass wir uns unsicher f\u00fchlen. Was kommt da auf mich zu? Schaffe ich das? Ist das Risiko nicht viel zu gro\u00df f\u00fcr mich? Welche Gefahr besteht f\u00fcr mich, wenn ich der Ver\u00e4nderung folge? Dieser Unsicherheit begegnen wir im agilen Umfeld durch den Fokus auf die Individuen. Wir arbeiten in Teams zusammen, nicht jeder einzelne muss eine Ver\u00e4nderung durchmachen, wir machen das gemeinsam! Wir st\u00fctzen uns, nehmen uns gegenseitig die \u00c4ngste, gehen aufeinander ein.<\/p>\n
Wenn wir nun doch wieder in Richtung Prozess denken, dann versuchen wir in der Agilit\u00e4t die Ver\u00e4nderungen durch Methodiken zu institutionalisieren. Im Scrum etwa arbeiten wir in kurzen Zyklen von wenigen Wochen. Nach jedem Sprint schauen wir zur\u00fcck und Fragen uns, was wir ver\u00e4ndern sollten, damit es noch besser funktioniert. Wir erkennen die notwendigen Ver\u00e4nderungen selbst und gestalten sie miteinander – im Team, nicht alleine. Innerhalb eines Sprints f\u00fchren regelm\u00e4\u00dfige Iterationsgespr\u00e4che mit dem Product-Owner oder dem Stakeholder zu schnellem Feedback, welches zu \u00c4nderungen an den Anforderungen f\u00fchrt. Auch hier wird die \u00c4nderung gemeinsam getragen. Niemand bleibt mit seiner Unsicherheit allein.<\/p>\n
Damit das aber auch tats\u00e4chlich funktioniert, m\u00fcssen wir \u00c4nderungen willkommen hei\u00dfen. Jeder einzelne um Team muss eine Ver\u00e4nderung als Chance<\/strong> sehen und nicht als Bedrohung. Bedrohungen f\u00fchren dazu, dass wir in eine Abwehrhaltung gehen und der Situation nicht mehr konstruktiv gegen\u00fcbertreten. Sehen wir hingegen Chancen, sprudeln wir nur so vor Ideen. Und jede dieser Ideen kann das neue Erfolgsrezept sein.<\/p>\n <\/p>\n
St\u00e4ndiges lernen<\/h1>\n
Ein weiterer Aspekt in der Agilit\u00e4t, die dabei hilft, Ver\u00e4nderungen positiv gegen\u00fcberzutreten ist, dass wir alles in kurzen Zyklen machen. Sei es die Entwicklung eines riesigen Features, bei dem wir erst einmal kleine, klar abgegrenzte Teile umsetzen, oder ein neues Vorgehen bei der Automatisierung unserer Tests. Wir machen einen Schritt, schauen uns um und sehen, wo wir stehen. Sind wir in der richtigen Richtung unterwegs? M\u00fcssen wir die Richtung anpassen, oder m\u00fcssen wir gar wieder einen Schritt zur\u00fcck machen?<\/p>\n
Wir d\u00fcrfen Fehler machen! Wir sollen sogar Fehler machen. Aus Fehlern lernen wir. Wichtig ist dabei, das wir die Auswirkung unserer Fehler klein halten. Wir probieren etwas Neues aus, wir starten ein Experiment und nach kurzer Zeit (in aller Regel nach einem Sprint) schauen wir, was an dem Experiment gut war und was wir noch verbessern k\u00f6nnen.<\/p>\n
Das Mantra „fail fast, fail often<\/strong>“ spielt hier eine wichtige Rolle. Wir probieren viel Neues, gehen mutig nach vorne, auch mal Wege, die vielleicht nicht so sicher oder bequem sind, Wege, auf denen Gefahren lauern. Aber wir sind dabei niemals alleine, wir sind immer ein Team, wir begegnen Gefahren gemeinsam. Wir schauen uns die Situation regelm\u00e4\u00dfig an, lernen, passen an, ver\u00e4ndern. Dauernd.<\/p>\nDas setzt nat\u00fcrlich eine Kultur voraus, in der Fehler schnell erkannt werden und auch auch direkt offen angesprochen werden (k\u00f6nnen). Das k\u00f6nnen individuelle Fehler sein, aus denen ich selbst lerne. Es kann ein Fehler in einer Teamentscheidung sein, aus der das Team lernt. Es kann ein Fehler in einer Unternehmensentscheidung sein, aus dem wir alle lernen. Wichtig ist, dass wir lernen wollen<\/span>!<\/strong><\/p>\nZum Schluss dieses Artikels steht auch das letzte Zitat aus dem agilen Manifest, und ich denke nach dem Lesen dieses Artikels spricht er f\u00fcr sich: Reagieren auf Ver\u00e4nderung <\/span>wichtiger als das Befolgen eines Plans<\/span><\/span>.<\/p>\nDas Ziel ist es nicht, Software zu entwickeln. Das Ziel ist es, gute Produkte <\/b>auszuliefern<\/b><\/u>, sich st\u00e4ndig weiterzuentwicklen<\/span> und auf Ver\u00e4nderungen eingehen k\u00f6nnen<\/span> und wollen<\/span>.
\n<\/b><\/p>\n <\/p>\n
Wir hoffen, euch auch hiermit wieder einen Denkansto\u00df gegeben zu haben. Versucht mal f\u00fcr euch selbst zu reflektieren, was das bedeutet und welchen Beitrag ihr leisten k\u00f6nnt, um in eurem Unternehmen Ver\u00e4nderungen besser umsetzen zu k\u00f6nnen.<\/p>\n
Eure Spa\u00df-Coder<\/p>\n","protected":false},"excerpt":{"rendered":"
Hallo Spa\u00df-Coder, im zweiten Teil der Artikelreihe wollen wir uns damit besch\u00e4ftigen, welchen Arten von Ver\u00e4nderungen ein Unternehmen begegnen muss und wie uns Agilit\u00e4t dabei hilft. Im ersten Teil der Artikelreihe haben wir uns in erster Linie damit besch\u00e4ftigt, warum es f\u00fcr ein Unternehmen notwendig ist, sich st\u00e4ndig zu ver\u00e4ndern und anzupassen, und wie wir […]<\/p>\n","protected":false},"author":1,"featured_media":585,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[5],"tags":[103,119,122,118,117,100,56,116,120,121,115],"_links":{"self":[{"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/posts\/576"}],"collection":[{"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/comments?post=576"}],"version-history":[{"count":10,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/posts\/576\/revisions"}],"predecessor-version":[{"id":593,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/posts\/576\/revisions\/593"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/media\/585"}],"wp:attachment":[{"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/media?parent=576"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/categories?post=576"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/tags?post=576"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}