Agile Softwareentwicklung ermöglicht einen flexiblen Umgang mit Aufgaben, die das Team selbstständig und ohne viel bürokratischen Aufwand angehen kann. So viel Freiheit das auch mit sich bringt – an einige Regeln sollten sich alle Beteiligten halten, damit nicht am Ende doppelt und dreifach Zeit investiert werden muss, um Fehler aufzuarbeiten.

Von Anfang an sollte jeder wissen, was seine Aufgabe im Team ist. Es ist natürlich möglich, sich in andere Bereiche einzuarbeiten und nicht nur starr den eigenen Zielen zu folgen. Aber jeder muss wissen, wofür er zuständig ist und was in seiner Verantwortung liegt. So gibt es immer einen Ansprechpartner und Fragen können problemlos adressiert werden.

Natürlich ist das Design einer neuen Schnittstelle wichtig. Oder die Social Media-Einbindung und die Belebung des neuen Instagram-Kanals. Wenn aber das zugrundeliegende Angebot noch gar nicht läuft, ist das alles herzlich egal. Es sollte also klar sein, welche Schritte wann zu erledigen sind und was aufeinander aufbaut.

Jede Arbeit im Team erfordert Absprachen zwischen den Teammitgliedern. Nicht alles wird in der ersten Planungsrunde festgelegt und ein agiler Softwareentwicklungsprozess kommt ohne Veränderungen praktisch nie aus. Dazu ist es unerlässlich, dass alle Teammitglieder immer über Veränderungen informiert sind und diese schriftlich formuliert werden, um sich in Zukunft darauf berufen zu können. Es ist schön und gut, wenn zwei eine Absprache treffen – dann ist es aber wichtig, dass das ganze Team diese jederzeit einsehen kann.

Die Arbeit an großen Projekten sieht auf den ersten Blick immer überwältigend aus. Umso wichtiger ist es, die konkreten Arbeitsaufgaben so weit es geht zu abstrahieren. Abstraktion zwingt einerseits alle, den gesamten Arbeitsauftrag zu durchdenken („was ist zu tun“, „was baut aufeinander auf“, „wo fangen wir dafür an“ …) und entsprechend strukturiert an die Aufgabenverteilung zu gehen. Außerdem steigt natürlich auch die Motivation im Team, wenn schnell Erfolge zu sehen sind.

Kaum ein Projekt kommt absolut problemlos vom Start zum Ziel. Viel wahrscheinlicher ist es, dass Schwierigkeiten auftauchen werden oder sich Ungereimtheiten zeigen, mit denen dann umzugehen ist. Deswegen ist es so wichtig, immer wieder ehrlich zu testen, wo man steht. Es ist erstmal kein Beinbruch, wenn das Projekt hinter dem Zeitplan liegt, solange man weiß, wo man ansetzen muss, um wieder in die Spur zu kommen.

Es klingt so simpel, aber oftmals endet dann doch ein Arbeitsschritt im Chaos, weil irgendeine Information auf der Strecke geblieben ist. Gemeinsames Arbeiten ist nur so gut wie die Kommunikation der Teammitglieder und das nicht nur während der Meetings, sondern auch in der weiteren Arbeitszeit. Ehrlichkeit ist dabei besonders wichtig: Denn nur, wenn jemand zugibt, dass er nicht vorankommt, kann jemand anders ihm helfen und die Planung angepasst werden.

Je besser sich alle Beteiligten in einem Bereich auskennen, desto schneller werden die Aufgabenbeschreibungen zu einer Art Ratespiel für Außenstehende. Aber auch wenn es eher unnötig erscheint, ist es wichtig, alle Arbeitsschritte klar und deutlich zu umreißen, sodass jeder folgen kann. Weil der Auftraggeber mal reinschauen will, weil ein neues Teammitglied für einen kranken Kollegen übernimmt oder die Dokumentation später noch einmal gebraucht wird. Aber auch, damit ganz konkret klar ist, was wie umzusetzen ist. Sonst führt am Ende ein großer Interpretationsspielraum dazu, dass etwas anders läuft als gedacht, weil der darauf angesetzte Entwickler ganz frei an die Aufgabe herangegangen ist.

Oft wird vergessen, dass auch ein Entwickler, der versucht, wie ein normaler Nutzer zu denken, kein einfacher Nutzer wird, sondern immer sein Fachwissen im Hintergrund hat. Wer eine Funktion programmiert hat, wird immer wissen, wie sie zu nutzen ist – auch wenn er so tut, als habe er keine Ahnung. Deswegen: Immer wieder Tests machen, immer wieder Unbeteiligte mit dem Projekt arbeiten lassen. Je mehr Tests gemacht werden, desto weniger muss nach dem Launch feinjustiert werden, weil die Nutzer sich nicht zurechtfinden.

Vor allem bei kleineren Projekten ist es natürlich verlockend, einfach so drauflos zu arbeiten, anstatt sich wirklich abzusprechen. Besser ist es aber, sich jedes Mal einen Plan zu erstellen, Termine festzulegen, Deadlines zu setzen und Rollen zu verteilen. Das ist einerseits eine gute Übung für größere Projekte, andererseits strukturiert sich so die Arbeit schon vor dem Beginn und erleichtert die Umsetzung.

Natürlich ist es wünschenswert, wenn wirklich jeder Use Case von einer Software abgedeckt werden kann und das schon vor dem Launch. Allerdings führt ein solcher Ansatz schnell dazu, dass man sich in zu viele Kleinigkeiten verrennt und sich schlimmstenfalls Termine nicht mehr einhalten lassen. Deswegen ist es besser, ein Programm möglichst simpel aufzubauen. Sobald das Fundament steht, ist es kein Problem, es zu erweitern. Vorher allerdings kann das nach hinten losgehen.

Wer noch nicht genug von der agilen Softwareentwicklung hat, für den haben wir zum Weiterlesen noch einen weiteren Artikel mit Tipps und Tools zur agilen Softwareentwicklung.