Blog

FIS-SST

Scrum und Agile aus Sicht eines Entwicklers

Anna Nawrot


Agile und Scrum – Begriffe, die man kaum auseinanderhalten kann, letztendlich ist Scrum ein flexibles Agile Framework, das wir Softwareentwickler besonders gut kennen. Aber kennen wir sie wirklich, wenn so oft gewisse Aspekte doch falsch interpretiert werden?

Daily Scrum

In der Theorie einfaches Stand-Up Meeting, dass dem ganzen Team einen Überblick verschaffen sollte und einfache Antworten auf die Frage: „Wo stehen wir als Team“ liefert. So einfach es klingt, es wird immer wieder der Fehler gemacht, dass Teilnehmer dem Team darüber berichten, was sie den ganzen Tag gemacht haben! Das Team will es doch gar nicht so genau wissen! Deswegen sollte man sich immer wieder die Regeln vor den Augen halten, damit es kurz und knapp ausfällt.

DAILY REGELN:

Jede/r berichtet

  • Was er / sie seit dem letzten Daily gemacht hat
  • Was er / sie plant, bis zum nächsten Daily zu tun
  • Wo es Probleme gibt bzw. Hilfe benötigt wird

Jede/r Teilnehmer/in sollte in der Regel nicht länger als ca. 2 Minuten sprechen. Falls tiefer gehende Diskussionen nötig sind, sollten diese in ein separates Meeting ausgelagert werden!

Agil arbeiten

Agil heißt flexibel zu sein und auch, dass späte Änderungen der Anforderungen an das Projekt willkommen sind. Was aber, wenn die Anforderungen mitten im laufenden Sprint angefordert werden? Klar, in der Theorie sollte der Sprintumfang nicht geändert werden, in der Praxis sieht es nicht immer so einfach aus. Sollten daher die Entwickler, die mit Aufgaben zugeballert werden, freiwillig Überstunden mit einem Lächeln im Gesicht machen? Natürlich nicht. Man kann dem Kunden entgegenkommen, aber er sollte sich im Klaren sein, dass an dieser Stelle folgende Regel gilt:

Wenn was reinkommt, muss auch was raus, d.h.
NEXT with highest priority IN, LAST with lowest priority OUT

Stellen Sie sich Mal vor, es sollten zwei Flugzeuge starten, aber kurz vor dem Start geht das eine kaputt – dann wird man doch nicht alle Leute in ein Flugzeug reinquatschen, weil das unbequem und auch zu riskant wäre, nur einen Stehplatz zu haben – man versucht entweder die Flüge umzubuchen oder dem Kunden eine Übernachtung im Hotel anzubieten. So ist es leider auch manchmal während eines Sprints, wenn ungeplante Bugs aus der Produktion reinkommen oder dem Kunden auffällt, dass er noch unbedingt zeitaufwendige Änderungen in der Version haben will, dann sollte man Tickets mit der niedrigsten Priorität „umbuchen“ – also aus dem Sprint rausnehmen, anstatt alles zusammen zu quetschen mit den Gewissen – es wird nicht gut gehen und wir werden als Team abstürzen.

Es sollte zu den Ausnahmen zählen, dass die Tickets aus dem laufenden Sprint rausgenommen werden, wenn dies jedoch antrifft, sollte man das dem Kunden rechtzeitig früh kommunizieren.

Refinement Meeting

Refinement Meeting ist ein Prozess der Pflege des Backlogs, d.h. Ergänzung seiner Elemente, Hinzufügen von Details, Aufteilung und Schätzung von Aufgaben in kleinere Aufgaben oder einfach Entscheidung über die Reihenfolge der Umsetzung. Es ist sinnvoll, dass einmal die Woche ein Refinement Meeting stattfindet. Folgende Themen sollten berücksichtigt werden:

  • wo stehen wir als Team mit der nächsten Lieferversion?
  • haben sich die Prioritäten seitens des Kunden geändert und sollten bestimmte Tickets anders priorisiert werden?
  • gibt es neue Kunden Anforderungen, die mit der kommenden Version unbedingt geliefert werden, müssen (müssen Tickets rausgenommen werden?)
  • Haben sich die Prioritäten des Kunden geändert und sollten bestimmte Tickets anders priorisiert werden?
  • Hat das Team genug Tickets, die umgesetzt werden sollten?
  • Gibt es Blocker Tickets, die Arbeit verhindern?
  • Was muss für den kommenden Sprint konzipiert, geschätzt werden?

Termine im Sprint

Je regelmassiger der Sprint und somit Review, Retro, Planung und Tag der Lieferung, desto weniger Zeit wird das Team dafür verschwenden immer nachzuschauen und nachzufragen, wann was stattfindet. Bei den meisten Teams ergibt sich als empfehlenswert 4 Wochen Sprint, so hat man genug Zeit zu Entwickeln und das Review ist vom Zeitaufwand nicht so lästig. Zu schlechten Praktiken gehört die ständige Verschiebung von Lieferterminen (oder noch schlimmer – kurzfristig vor der Lieferung), denn es muss alles neu geplant werden und dementsprechend wird viel Zeit für Diskussionen verwendet, wann Review, Retro, Planning und Smoke Test stattfindet. Die größte Herausforderung dabei ist, dass die Kalendertermine der einzelnen Personen im Team oft auch international beachtet werden müssen und viele davon miteinander kollidieren.

Agiles Projekt, Agile Entwickler?

Was sich bisher als sehr gute Praxis in meinen Teams erwiesen hat, ist die Flexibilität der Entwickler. Was bedeutet das genau? Aus meiner Sicht, dass sich die Entwickler in verschiedenen Bereichen zumindest gut orientieren. Klar, es wird nie so sein, dass sich ein Entwickler in allen Bereichen sehr gut auskennet, das betrifft meistens die kleinen Projekte, wo nur 1 Entwickler beteiligt ist, aber man sollte sich bemühen, dass sich zumindest 2 Entwickler aus dem Team in einem Thema auskennen. Das hat einige Vorteile:

  • man hat immer eine Vertretung während des Urlaubs oder einer Krankheit – die kommt ja selten geplant und achtet nicht drauf, ob dem Entwickler Tickets mit hoher Priorität zugewiesen sind,
  • man kann vom Urlaub zurückkommen und es warten am ersten Tag nicht 100 Tickets, die dringend geklärt und bis gestern(!) gefixt werden müssen,

Flexibel bedeutet aber auch, den anderen im Team eine Chance zu geben. Jeder Entwickler hat seine eigenen Erfahrungen und oft auch einen anderen Standpunkt. Wenn ein Entwickler aus dem Team nach langer Überlegung keine zufriedene Lösung für ein bestehendes Problem findet, dann sollte sich das Problem ein anderer Entwickler anschauen. Das gehört auch zum agilen Arbeiten – die Perspektive zu wechseln, mit den anderen Personen aus dem Team Probleme besprechen und gemeinsam nach Lösungen suchen.

Ein Know Issue ist manchmal besser als ein Fix

Auch wenn man agil arbeitet, bedeutet es lange noch nicht, dass man auf gewisse Probleme erst am Tag der Lieferung stößt. Beim Fehler beheben sollte man sich eines bewusst sein – je mehr man unter Zeitdruck fixt, desto mehr kann man kaputtmachen. Das ist leider eine Tatsache, die so oft vergessen wird. Wenn unter Zeitdruck gearbeitet wird, werden aus zeitlichen Rahmen nicht alle Testfälle beachtet, geschweige denn durchgeführt.

Anstatt dessen sollte man Ruhe bewahren (leichter gesagt als getan, aber Hektik hilft keinem!) und gemeinsam mit dem Product Owner/Scrum Master überlegen, wie kritisch der aufgetretene Fehler ist, welche Möglichkeiten der Kunde hat, den Fehler umzugehen und vor allem, welche Risiken der Fix mitbringen könnte. Hier muss man als Entwickler auch klar die Meinung sagen können, denn oft ist es nicht der Kunde selbst, sondern der Product Owner und Scrum Master, die den Druck machen. Man sollte daher die Risiken klar vorstellen und die Bremse ziehen.

HotFix sollte nicht zum HotChange werden!

Agil bedeutet flexibel, aber nicht, dass man gewisse Prozesse der Softwareentwicklung, wie es gerade passt, umbiegen kann. Ein Hotfix ist eine Lieferung von Paketen, um ein Problem in einem Softwareprodukt zu beheben – in der Regel oft, um eine bestimmte Kundensituation zu beheben. Es gibt aber Situationen, in denen der Kunde unter dem Vorwurf „das Team sei doch flexibel“ versucht neue Anforderungen in den HotFix zu erzwingen. Das ist keine gute Praxis und man sollte dran denken, dass sich der Kunde an gewisse Maßnahmen sehr schnell gewöhnt und diese als problemlos sieht – denn hat man einmal eine Ausnahme gemacht, so kann man die doch immer wieder machen, oder?

Agile Projekte unter Zeitdruck?

Ist es nötig, in einem agilen Projekt Druck auf den Endkunden auszuüben? In gewissen Maßen schon, vor allem wenn es um das Testen der Anwendung geht. Die Software sollte nach der Produktivsetzung oder ggf. schon in Integrationsumgebung möglich schnell getestet werden, am besten, in dem ein Endtermin für die Abnahme klar definiert wird. Wieso die Eile? Erstens, weil der Endkunde das Produkt nutzen wird und er eine andere Sicht drauf hat als der Entwickler und somit können auch frühzeitig gewisse Aspekte abgefangen werden, die bei der Konzeption vergessen worden sind. Zweitens – wenn die Testergebnisse erst Monate später geliefert werden, muss sich der Entwickler wieder neu reindenken, denn er ist schon längst aus dem Thema raus. Das kostet Zeit und damit auch Geld und dass sollte man den Kunden immer bewusst machen.

Schlusswort

Als Entwickler hat man immer das Recht, gewisse Prozesse zu beeinflussen und jeder von uns sollte eine Stimme bei den Entscheidungen im Team haben. Schließlich geht es um unsere Arbeit und unseren Alltag und meistens sind wir Entwickler am Ende von den Entscheidungen betroffen. Arbeiten unter Druck und großer Last können zu psychischen Problemen des Teams führen und die Arbeit uneffektiv machen. Daher sollte man gewisse Aspekte deutlich und in alltäglichen Situationen. Eine klare Meinung ist immer besser als Stillschweigen.

Kontaktformular

Lukas Schikora

Project & Operations Manager

Bitte zögern Sie nicht, mich telefonisch oder per E-Mail zu kontaktieren

Download

Damit der Download erfolgen kann, geben Sie bitte hier Ihren Namen und Ihre E-Mail Adresse ein.

Unternehmensinformationen herunterladen (PDF)

Damit der Download erfolgen kann, geben Sie bitte hier Ihren Namen und Ihre E-Mail Adresse ein.

Grenzüberschreitendes Unterstützungskonzept

Damit der Download erfolgen kann, geben Sie bitte hier Ihren Namen und Ihre E-Mail Adresse ein