Die Bedeutung von Agilität in der Softwareentwicklung

Das Wichtigste vorab in Kürze:

• Versuch einer Definition des agilen Arbeitens
• Besonderheiten und Schwierigkeiten im Agilen
• arbeiten mit Frameworks und Praktiken
• Zusammenarbeit zwischen Kunde und Projektteam
• Voraussetzungen, um agil arbeiten zu können

Madita Thomas aus dem PR-Team hat sich mit unserer Kollegin Jasmin Sommer getroffen, die seit 2018 als Projektleiterin und Agile Coach bei neuland arbeitet.

Versuch einer Definition des agilen Arbeitens

Was heißt agiles arbeiten in der Softwareentwicklung, Jasmin? Gibt es eine allgemeine Definition des Begriffs?

Viele verbinden mit der agilen Arbeitsweise einige Vorteile, die diese verspricht: Man ist bspw. in der Arbeit flexibler, kann das Produkt besser und schneller ausliefern und effizienter arbeiten. Ich würde behaupten, dass viele genau aus diesem Grund die agile Arbeitsweise einsetzen wollen und sich mehr mit den Vorteilen als der allgemeinen Definition befassen.

Anstatt einer Definition, würde ich lieber die Abgrenzung zur klassischen Arbeitsweise betrachten, denn genau auf die Unterschiede kommt es an und durch sie können die Vorteile erreicht werden. In der klassischen Arbeitsweise gibt es zunächst viele voneinander abgekapselte Phasen, die nacheinander abgearbeitet werden. Ich habe dort zuerst eine Anforderungserhebung, eine Konzeption, die Implementierung, die Testphasen, um nur ein paar zu nennen. All diese Phasen gibt es theoretisch auch in der agilen Arbeitsweise, sie sind im Agilen aber viel enger zusammen, überlappen sich und werden iterativ immer wieder durchlaufen. Im Agilen habe ich also nicht erst zwei, drei Monate die Anforderungserhebung, dann drei, vier Monate Konzeption, sondern spezifiziere immer wieder die Anforderungen für den Teil, den ich auch dann in diesem Moment, oder zumindest sehr zeitnah, entwickeln möchte. Dadurch spare ich mir Arbeit, die ich zum aktuellen Zeitpunkt noch gar nicht brauche, wie bspw. eine Spezifikation für ein Feature, welches ich erst in einem halben Jahr oder Jahr entwickeln kann.

In der klassischen Arbeitsweise, wird alles genau ausspezifiziert, was zum Einen dann natürlich mehr Zeit kostet, zum Anderen aber vielleicht auch gar nicht mehr aktuell ist, wenn ich es dann entwickeln möchte. Die Anforderungen können sich bspw. geändert haben, vielleicht wird das Feature gar nicht mehr benötigt? Oder es wird eben in einer anderen Form benötigt. Vielleicht haben sich nicht die fachlichen Anforderungen, aber die Technik verändert, auch dann kann es sein, dass mein Konzept, so wie ich es vor langer Zeit definiert habe, nicht mehr passt.

Quelle: https://www.stoegerpartner.de/agiles-projektmanagement/

Ein weiterer Punkt, der sehr viel Zeit in der klassischen Softwareentwicklung eingenommen hat, war die Dokumentation. Dadurch, dass die verschiedenen Phasen oftmals durch völlig unterschiedliche Personen durchlaufen wurden, musste natürlich alles sehr genau dokumentiert werden. Auch hier unterscheidet sich die agile Arbeitsweise. Das Team besteht aus Personen, die all diese Phasen abdecken können und das Projekt gemeinsam durchlaufen. So sind auch Entwickelnde schon bei der Anforderungserhebung und Konzeption an Board. Es braucht daher eine nicht so ausführliche Dokumentation wie zuvor, was nicht nur Zeit spart, sondern auch weniger fehleranfällig ist, da so weniger Missverständnisse entstehen.

Die Kommunikation wird in der agilen Arbeitsweise über eine umfassende Dokumentation gestellt.

Wodurch zeichnet sich die agile Arbeitsweise also aus?

Ein paar Beispiele, wie die kürzere Time-to-Market-Zeit (TTM), dass das richtige Produkt entwickelt wird und eine höhere Effizienz, haben wir ja eben bereits angesprochen. Ebenso fokussiert die agile Arbeitsweise auch eine höhere Qualität, genau wie auch eine höhere Kunden- und Mitarbeitendenzufriedenheit. Diese ganzen Vorteile ergeben sich meiner Meinung nach vor allem durch die Grundhaltung der agilen Arbeitsweise, die im agilen Manifest festgehalten wird.

Das agile Manifest ist sehr grundlegend und unabhängig von Methoden und Technologien, daher kann es als der kleinste gemeinsame Nenner in der agilen Arbeitsweise bezeichnet werden. Verschiedene Wissenschaftler*innen haben hier 2001 festgehalten, was die agile Arbeitsweise auszeichnet.

Aufgebaut ist das agile Manifest aus vier agilen Werten, die als die Grundsätze der agilen Arbeitsweise verstanden werden können und zwölf agilen Prinzipien, die etwas detaillierter sind und somit die Leitsätze der agilen Arbeitsweise sein können.

Der zweite Wert besagt bspw. genau, was wir eben besprochen haben: "Funktionierende Software mehr als umfassende Dokumentation". Es geht also darum, dass der Fokus auf einem Stück Software liegt, welches funktioniert und schnell ausgeliefert werden kann, anstatt einer umfassenden Dokumentation. Muss ich mir also bereits alles ins kleinste Detail für die gesamte Software überlegen, ausformulieren und festhalten? Oder kann ich nicht lieber schauen, wie ich schnellstmöglich schon einen Wert schaffen kann und das Stück Software für diesen einen Fall bauen und schon einmal an den Markt bringen?

Zweiteres wird also in der agilen Softwareentwicklung getan. Dort ist es zwar nicht so, dass gar nichts dokumentiert wird, nur der Fokus ist nicht so stark auf der Dokumentation wie es im klassischen Arbeiten war. Ebenso gibt es natürlich einen groben Plan, welche Probleme die Software lösen soll und wie sie in etwa aussehen könnte, das wird in der agilen Arbeitsweise häufig in einer Vision festgehalten. Die Vision ist dabei aber nicht so stark definiert, wie es bei der klassischen Arbeitsweise mit den Pflichten- und Lastenheften bekannt ist, sondern sie gibt nur eine grobe Zielrichtung vor. Wo man auf dem Weg abbiegt, wird also noch nicht so klar definiert, sondern je nach Feedback und neuen Erfahrungen entschieden. Und das ist für mich persönlich der eigentlich entscheidende Punkt:

In der agilen Arbeitsweise entwickelst du iterativ, in einem definierten Zyklus, an deinem Produkt und holst dir aber während der Entwicklung ständig Feedback ein.

Durch dieses Feedback merkst du sehr schnell, ob du in die richtige Richtung läufst und auch Anforderungsänderungen treffen dich nicht so hart, als wenn du alles fertig entwickelt hast und es erst dann bemerkst. Du bleibst dadurch flexibler und siehst ziemlich schnell, ob du einen Mehrwert lieferst.

Besonderheiten und Schwierigkeiten im Agilen

Bei neuland arbeitet jedes Team unterschiedlich agil. Wieso ist das so und warum ist das vielleicht eine Besonderheit?

Ja, ich würde behaupten, dass jedes Team unterschiedlich agil arbeitet. Wir haben teilweise auch Parallelen, die meisten von uns arbeiten in Iterationen, die zwei Wochen lang sind. Viele von uns haben auch das inkrementelle Deployment, also dass wir dann wirklich was auf die produktive Umgebung bringen. Manche haben das ein bisschen gesteigert im Continious Deployment, d.h. jede Codeänderung geht sofort produktiv.
Wir versuchen uns alle an Scrum zu orientieren, aber dadurch, dass unsere Kunden alle sehr unterschiedlich agieren und wir natürlich mit unseren Kunden eng zusammenarbeiten und nicht von ihnen unabhängig arbeiten wollen, passen wir unsere agile Arbeitsweise dementsprechend immer an.

Aus dem Agilitätsraster geht u.a. ja auch hervor, dass es viele verschiedene agile Praktiken gibt und nicht jedes Team tatsächlich alle Praktiken durchführen muss. Manche Praktiken machen für einige Teams Sinn, für andere eben nicht. Das meinte ich gerade mit dem Aspekt, dass man sich bei jeder Praktik über den Hintergrund Gedanken machen sollte und dann muss man bewerten, ob sie für einen in dem eigenen Gebiet sinnvoll ist. Wir haben bei neuland Kunden, die nur mit drei Mitarbeitenden von uns betreut werden, und wenn man ihnen sagen würde, sie müssen alle zwei Wochen ein Architektur-Meeting machen, ist das für sie eventuell ein totaler Overhead, da sie sowieso ständig gemeinsam über die Architektur sprechen und dafür kein Meeting benötigen. Das ist völlig in Ordnung und richtig so - ein reifes Team kann glaube ich sehr gut einschätzen, was sie benötigen und was nicht. Wenn man völlig neu in der agilen Arbeitsweise ist, würde ich empfehlen, mit einem Framework wie Scrum erst einmal zu starten. Reifere Teams können sich aber durchaus ohne Frameworks selbst an den Praktiken bedienen oder sie bewusst weglassen und arbeiten so viel effektiver.

Ein anderes Beispiel, wo wir speziell als Partner unserer Kunden auch nicht unabhängig sind, wäre das Continious Deployment. Wenn ich auf Biegen und Brechen versuche dieses einzuführen, obwohl das bei mir gar keinen Sinn macht, weil ich meine Änderungen nicht sofort auf einem Produktivsystem brauche, da es bspw. ein Backoffice-System ist, was sowieso nur alle drei Wochen mal von jemanden benutzt wird oder andersherum, es so häufig genutzt wird, dass zunächst erst Schulungen durchgeführt werden müssten, dann ist das halt ein Overhead, wo sich der Outcome nicht lohnt.

Das heißt, unsere Teams orientieren sich dort schon stark mit den Kunden. In erster Linie schauen wir da natürlich, was in diesem Umfeld überhaupt Sinn macht. Daneben spielen natürlich aber auch die technische Infrastruktur und die Organisation des Kunden eine Rolle. So kommt es, dass jedes Team bei neuland unterschiedlich agil arbeitet, eben soweit es im Rahmen des Projektes Sinn macht und inwieweit es auch mit unseren Kunden zusammen möglich ist.

Welche Schwierigkeiten und Hindernisse birgt das agile Arbeiten?

Wenn man agil arbeitet, sagt man eigentlich, dass es keine Hierarchien gibt und das Team komplett autonom arbeitet. In der Realität ist das bei großen Firmen einfach nicht so.

Wenn wir jetzt uns als neuland alleine betrachten, ist das meiner Meinung nach innerhalb von neuland absolut so, dass die Teams völlig autonom arbeiten. Das sieht man bspw. daran, dass jedes Team eigentlich anders arbeitet.

Wenn wir mit dem Kunden zusammenarbeiten, sind wir in der Rolle des Partners, oder wenn man es mal etwas anders ausdrücken möchte: Wir sind für die Kunden ein Dienstleister. Da ist es dann nicht zwingend so, dass wir immer völlig autonom arbeiten können. Auch bei den eigenen Kundenteams, die ich kenne, ist es nicht so, dass sie komplett autonom sind. D.h. wir haben hier irgendwie immer ein bisschen Fremdbestimmung oder -einwirkungen und müssen auch bspw. ein Reporting oder eine Timeline liefern. Eigentlich gibt es das in der agilen Arbeitsweise einfach nicht, d.h. man muss sich mit den Informationen, die uns die agile Arbeitsweise dennoch bietet, versuchen, etwas hinzulegen.

Es gibt da Möglichkeiten z.B. bei den Timelines: Wir messen die Velocity von unserem Team. Das heißt, wir messen, wie viel Storypoints wir in zwei Wochen schaffen. Mit dieser Velocity und dadurch, dass wir unsere Tickets in Storypoints schätzen, kann ich ungefähr sagen, dass es in zwei Monaten fertig sein kann. Das ist dann nicht fix, aber d.h. man kann schon eine ungefähre Aussage treffen. Das ist aber eigentlich nicht der Sinn der Velocitiy und das sollte einem durchaus bewusst sein. Wir nutzen es, um so unseren Kunden gerecht zu werden und dennoch nicht in ein völlig klassisches Projektmanagement zu verfallen.

Eigentlich nimmt man die Velocity, um zu sehen, ob man Fortschritte in Richtung des Ziels gemacht hat oder ob es nachgelassen hat, um sich selbst einfach zu verbessern. Das heißt, da werden die Instrumente so ein bisschen abgewandelt genutzt, um die Schwierigkeiten, die manch einer vielleicht in der agilen Arbeitsweise sehen mag, auszuloten.

Dass die Teams völlig autonom sind, wäre in der optimalen Welt tatsächlich so, dann entscheidet auch alleine das Team über das Produkt. Das kenne ich so in der Realität nicht. Es ist beim Kunden oft tatsächlich so, dass einige Entscheidungen nochmal über die Managementebenen gehen müssen. Aber was man da halt auch wieder machen kann, ist, dass man dem Team einen gewissen Freiraum gibt. Sodass vielleicht große Entscheidungen dann vom Management abgesegnet werden müssen, auch gerade wenn es um Budgets geht, aber dass man sonst tatsächlich viel in die Teams auslagert. Das wäre auf jeden Fall sehr empfehlenswert und so kenne ich es bisher mit unseren Kunden auch.

Arbeiten mit Frameworks und Praktiken

Ist die agile Arbeitsweise also sozusagen eine neuland-Spezialität?

Die agile Arbeitsweise macht neuland schon aus und ist allen Mitarbeitenden sehr wichtig, da wollen wir uns auch nicht verbiegen lassen.

Die Arbeitsweise ist immer mehr verbreitet. Das agile Manifest gibt es ja nun auch schon sehr lange, aber die agile Arbeitsweise gibt es tatsächlich sogar noch länger.

Das bekannte Scrum von Ken Schwaber und Jeff Sutherland wurde bspw. bereits im Jahr 1990 festgehalten. An der Uni wurde es zu meiner Zeit, vor bereits fünf bis sechs Jahren, immer noch als total innovativ dargestellt. Wenn man sich umhört, sagt fast jede Firma, dass sie heute agil arbeitet. Man merkt aber ganz oft, dass sie es eigentlich nicht tun.

Um agil zu arbeiten, gibt es Frameworks, die man nutzen kann, wie z.B. Scrum, das teilweise auch bei neuland eingesetzt wird. Da ist es so, dass es keine Projektleitung gibt, dafür aber die Rolle des Scrummasters, um darauf zu achten, dass die Prozesse richtig funktionieren. Es gibt einen Productowner, der*die für die Entwicklung des Produktes hauptverantwortlich ist. Bei manch einem Unternehmen werden allerdings dann einfach Projektleitende als Scrummaster benannt und es heißt "jetzt arbeiten wir agil". Man muss jedoch nicht Scrum einsetzen, um agil zu arbeiten, genauso wie man nicht gleich agil arbeitet, wenn die Projektleitenden nun auf einmal Scrummaster heißen.

Viel mehr sollte man sich darauf konzentrieren, zu verstehen, warum gewisse agile Praktiken angewandt werden, welche Idee hinter ihnen steckt und das im Unternehmen verinnerlichen und umsetzen.

Wir plädieren bei unseren Kunden immer sehr darauf, agil zu arbeiten, wie wir es in der Softwareentwicklung auch tun. Die Vorteile sind wir ja schon durchgegangen, ich denke, die sprechen für sich. Ich glaube, dass wir da bei neuland schon sehr fortgeschritten sind in der agilen Arbeitsweise - wesentlich mehr als andere und in Zusammenarbeit mit unseren Kunden hat es bisher auch immer gut funktioniert.

Also gibt es nicht DIE eine agile Arbeitsweise, nach deren Mustern oder Prozessen gearbeitet wird?

Das Fundament und der kleinste gemeinsame Nenner ist meiner Meinung nach immer das agile Manifest. Um ein anderes Beispiel für einen Wert zu nennen, steht hier: "Reagieren auf Veränderungen mehr als das Befolgen eines Plans". Dabei wird nicht genau gesagt, wie das überhaupt ausgeführt wird. Etwas spezifischer sagt es das Prinzip "Heiße Anforderungsänderung auch spät in der Entwicklung willkommen". Dennoch wird auch hier noch keine Praktik oder Methodik genannt, wie dies umgesetzt werden kann. Da gibt es dann verschiedene agile Praktiken, die angewandt werden können. Frameworks, wie z.B. Scrum, die viele dieser Praktiken zusammenfassen, helfen Teams, die noch nicht so viel Erfahrung haben, um die Praktiken selbst zusammenzusuchen. Sie besagen, wenn man dieses Konzept so nimmt und anwendet, dann wird eigentlich agil gearbeitet.

Es gibt viele unterschiedliche Frameworks und Praktiken: Extreme Programming (XP), Scrum, Kanban… also je nachdem, was man hinterher auch für einen Output haben möchte, können verschiedene Frameworks genutzt werden. Meistens ist es so, dass es in der Praxis ein bisschen angepasst werden muss und man sich eigentlich nicht streng an ein Framework hält, sondern es sich ein bisschen zurechtlegt. So kenne ich es zumindest bisher. Ich habe noch kein Team kennengelernt, welches streng nur nach Scrum arbeitet und hier keine Anpassungen vorgenommen hat, da muss man jedoch dazu sagen, dass wir hier bei neuland auch immer sehr erfahrene Teams haben. Grundsätzlich kann ich daher nur empfehlen:

Man sollte sich nicht nur Scrum anschauen, weil es das meist verbreitetste ist, sondern wirklich darauf achten, welchen Mehrwert es für mich haben soll und wie ich den erreichen kann. Sind alle Praktiken des Frameworks für mich sinnvoll? Fehlt mir eine?

Es ist so, dass Scrum oder XP sich "auch nur an den Praktiken bedienen". Sie sind ein Vorschlag für eine Reihe an Praktiken, die zusammen gut funktionieren, um ein Ziel zu erreichen. Bei Scrum wird der Projektablauf in den Fokus gestellt, der durch die ausgewählten Praktiken optimiert wird. XP stellt hingegen die Techniken der Zusammenarbeit in den Fokus.

Zusammenarbeit zwischen Kunde und Projektteam

Was macht die (gelebte) Agilität bei neuland vor allem für unsere (potentiellen) Kunden attraktiv?

Ich glaube attraktiv ist zum einen, dass wir nicht erst alles ausarbeiten, dann in fünf Monaten mit der Implementierung starten und dann fällt beim Testen auf, dass beim Konzept noch was hätte anders sein müssen. Wenn wir mal auf dieses Dienstleistungsverhältnis gucken, ist es ja tatsächlich so, dass viele Dienstleistende sagen, sie arbeiten auch agil, sie liefern auch regelmäßig, aber sie nutzen dennoch Pflichten- und Lastenhefte. Und wenn am Ende noch was fehlt, wird in diese Vereinbarungen geschaut und festgestellt, dass niemand daran gedacht hat. Meist wird das für die Auftraggebenden dann eine ziemlich kostspielige Angelegenheit. Und das haben unsere Kunden bei uns eben nicht, sondern wir schauen uns die Sachen immer wieder gemeinsam an und gucken, ob es in die richtige Richtung geht.

Dadurch, dass wir diese schnellen und engen Feedbackzyklen haben, merken wir relativ schnell, wenn wir irgendwie in die falsche Richtung laufen oder irgendwo eine kleine Anpassung gemacht werden sollte. Das kriegt man immer relativ schnell mit rein und ist dadurch auch sehr flexibel. Natürlich haben wir unser Ziel, was wir verfolgen, aber es geht relativ schnell, dass wir schon mal ein Stück ausliefern. Dadurch können die Kunden auch sehr frühzeitig unsere Systeme benutzen.

Was manchmal vielleicht ungewohnt für Kunden sein kann, ist, dass wir ohne Roadmaps arbeiten, was v.a. die Konzerne dann vermissen. Das wird mit unserer Arbeitsweise sozusagen weggenommen, wir sagen ungern fixe Zeitpunkte inkl. des gesamten Umfangs zu. In der Realität, haben wir natürlich manchmal fixe Zeitpunkte, an denen etwas fertig sein muss, aber wir verständigen uns dort nicht bereits auf jedes einzelne Feature ein Jahr im Voraus. Also sagen wir dann, dass wir zu dem Zeitpunkt liefern, wenn es abgestimmt und einigermaßen realistisch ist. Wir commiten uns darauf, was ungefähr an Funktionsumfang drin ist und sorgen dafür, dass es laufen wird, aber ggf. fehlt noch eine Kleinigkeit oder der Feinschliff, den wir dann nochmal nachliefern. Dass es nicht rechtzeitig fertig wird, ist häufig eine Angst bei den Kunden, aber ich habe es in meinen bisher fünf Jahren bei neuland nie erlebt, dass der Zeitpunkt, an dem der Kunde etwas haben wollte, nicht geklappt hat.

Und auch hier haben wir wieder den Vorteil der kurzen Feedbackzyklen, sobald wir Bedenken haben, etwas nicht einhalten zu können, sprechen wir gemeinsam mit unseren Kunden. Ehrlichkeit und Offenheit sind uns in der Zusammenarbeit sehr wichtig.

Voraussetzungen, um agil arbeiten zu können

Für welche Unternehmen oder Teams bietet sich die agile Arbeitsweise an?

Um zu sagen, dass ein Team agil arbeitet, muss sich die Organisation auch darauf anpassen. Bleiben wir bei dem Beispiel, dass ein Team in der agilen Arbeitsweise selbstorganisiert arbeiten soll: Das kann es ja nur sein, wenn dem Team auch selbst die Verantwortung gegeben wird und gewisse Freiheiten zur Verfügung stehen.

Wenn das Team bspw. erst durch sechs Managementebenen gehen muss, um etwas absegnen zu lassen, dann kann das Team gar nicht agil arbeiten. Eine Unterstützung kann es daher sein, wenn das Unternehmen keine festen hierarchischen Strukturen hat. Man sollte zwei Dimensionen sehen: Also das Team nicht nur allein und losgelöst zu betrachten, sondern auch zu fragen, in welchem Rahmen es sich bewegt, wo kann es sich überhaupt bewegen?

Ich denke nicht, dass ein klassisch hierarchisches Unternehmen gar nicht agil arbeiten kann, aber es wird sicherlich schwieriger sein und es müssen gewisse Freiheiten gegeben werden.

Außerdem sollte bedacht werden, dass die agile Arbeitsweise nicht immer und überall der richtige Weg ist. Es gibt das Cynefine-Framework, das einordnet, wie eine Arbeit ist. Die agile Arbeitsweise eignet sich für eine komplexe Umwelt. Hier sind die Umweltparameter nicht gänzlich zu analysieren und daher muss man das Verfahren "ausprobieren, erkennen, reagieren" anwenden, um zu einer Lösung zu gelangen. Bspw. haben wir im E-Commerce eine solche komplexe Umgebung, bei der man das Verfahren auch anwenden kann. Ist hingegen einfach nur etwas kompliziert, muss ich kein "ausprobieren, erkennen, reagieren" Verfahren anwenden, sondern kann mit good practices zu einem guten Ergebnis gelangen.

Durch die agile Arbeitsweise schauen wir uns nur einen kleineren Teil des Problems, innerhalb einer Iteration (eines Sprints), an und verlagern somit die Umwelt ins Komplizierte, weg vom Komplexen, und können dann im Sprint innerhalb der komplizierten Umgebung arbeiten, ehe wir wieder das Gesamtbild der komplexen Umgebung betrachten (alles in Einem). Für Unternehmen, die jedoch nicht im Komplexen arbeiten, kann sich auch eine klassische Arbeitsweise eignen. Oder dort, wo "etwas auszuprobieren" einfach ein großes Risiko mit sich bringt, wie bspw. in der Medizin, wo es um Leben oder Tod gehen kann.

Das Besondere an der agilen Arbeitsweise ist also, dass flexibel reagiert und eine Arbeitsumgebung geschaffen werden kann, in der es leichter ist, sich zurechtzufinden und zu arbeiten.

Wenn mein Team agil arbeitet, muss mein Kunde dann auch agil arbeiten?

Teils, teils. Ich glaube, der Kunde muss zumindest so strukturiert sein, dass er einiges an Verantwortung abgeben kann. Er muss damit leben können, dass wir u.a. keine Anforderungs- und Lastenhefte schreiben, dafür schreiben wir halt die User Stories. Aber gerade in der Zusammenarbeit mit uns bei neuland, muss der Kunde damit leben, dass wir nicht am Anfang eines Projekts ein Dokument mit der absolut fixen Deadline ausdefinieren und sagen, das und das ist die Funktion.

Und worauf der Kunde sich außerdem einlassen sollte, ist, dass wir gerne Anwender*innenfeedback haben. Das funktioniert jetzt beim Onlineshop nicht so einfach wie bei Backofficesystemen. Da ist es cool, wenn der Kunde das mit in die Hand nimmt und Anwender*innenfeedback, AB-Testing durchführt, da sind wir auch Fan von. Wir haben gerne Kontakt zu Kolleg*innen, die ziemlich nah am Operativen sind, und nicht nur am Strategischen, und sich wirklich die Features anschauen, sich damit auseinandersetzen und Feedback geben. Wenn das Feedback jedes Mal, weil man ein Dienstleistender ist, über die höchste Managementebene gehen muss, funktioniert das glaube ich nicht gut mit uns.

Viele unserer Kunden arbeiten nur in Teilen agil und besitzen dennoch ihre Hierarchien. Aber trotzdem funktioniert die Zusammenarbeit gut, weil gewisse Verantwortlichkeiten abgegeben werden und man in den engen Feedbackschleifen immer wieder zusammenkommt.

Vielen Dank für das interessante und schöne Gespräch, Jasmin!

Jasmin Sommer hat sich im Rahmen ihrer Masterarbeit "Agilitäts-Ausprägungen in der Softwareentwicklung" mit der Frage beschäftigt, ob wir wirklich agil arbeiten oder es nur behaupten. Entstanden ist dabei das Agiliätsraster: ein eigenentwickeltes Werkzeug, um die agile Arbeitsweise eines Teams in der Softwareentwicklung zu analysieren. Was das Agilitätsraster ist und wie es angewendet werden kann, kann in Teil 1 und Teil 2 der Artikelreihe "Was ist das Agilitätsraster?" nachgelesen werden.

Für Fragen und weitere Informationen zur agilen Arbeitsweise und dem Agilitätsraster stehen unsere Agile Coaches gerne zur Verfügung:

agilitaetsraster@neuland-bfi.de