Agile Arbeitsweisen in der Praxis

Agile Arbeitsweisen zum Steigern der Teameffizienz

Lange Zeit war es üblich, dass der Chef oder ein anderer Vorgesetzter Aufgaben verteilten und Zuständigkeitsbereiche festlegten. Du kennst diese Vorgehensweise eventuell aus deinem Alltag immer noch und bist dir daher eventuell nicht darüber im Klaren, dass es Alternativen gibt. Doch es ist so, dass die stark hierarchische Gliederung und deren Arbeitsweise – insbesondere in der Softwareentwicklung – oft als überholt gilt und so langsam ersetzt wird. Es findet ein Umdenken statt, denn ein Team kann sich durchaus selbstständig organisieren, auch wenn man das vielleicht nicht denkt. Das bringt viele Vorteile für das Team mit sich und es lohnt sich daher, dies einmal zu betrachten.

Vorneweg möchte ich jedoch schon direkt sagen, diese Alternativen in meinen Augen nicht für jeden Bereich geeignet sind. In manchen Branchen oder Arbeitsbereichen macht eine klassische Gliederung und eine klassische Verwaltung von Aufgaben mehr Sinn. Daher gilt es genau zu überprüfen, ob die bestehende Arbeitsweise geändert werden kann und sollte. Nicht in jedem Team funktioniert die Selbstorganisation. In der Produktion beispielsweise lässt sich ein solches System in meinen Augen eher schwierig umsetzen. In anderen Bereichen, wie der Softwareentwicklung oder auch ein sozialen Einrichtungen, könnte es in meinen Augen durchaus funktionieren.

Wie kannst du dir das agile Vorgehen in der Entwicklung vorstellen?

Die grundlegenden Ideen bei einer agilen Arbeitsweise, liegen in der Flexibilität des Teams und der Zufriedenheit der einzelnen Teammitglieder. Insbesondere die Flexibilität spielt in unserer schnelllebigen Zeit eine große Rolle. Auf geänderte Anforderungen soll man schnell reagieren können, da der Kunde im Mittelpunkt steht und auch zu späteren Zeitpunkten noch Vorstellungen einbringen können soll.

Zu Beginn eines Projekts, werden die Aufgaben bzw. Teilschritte oder auch Anforderungen gesammelt, besprochen und ausgearbeitet bzw. genauer spezifiziert. Diese wandern dann – bildlich gesprochen – in einen großen Topf wo sich jeder etwas heraus nehmen kann, das entweder erledigt werden muss oder etwas, das ihm besonders liegt. Im Laufe der Zeit entsteht daraus dann das finale Produkt. Doch auch während der Arbeit kann es oftmals zu unerwarteten Aufgaben oder Fehlern kommen, welche wieder als neue Aufgabe in den großen Topf wandern, um so von einem Teammitglied bearbeitet zu werden. Üblich ist es ebenso, dass man sich die Aufgaben in Etappen einteilt. Diese Etappen werden Sprints genannt und sind zeitlich festgelegte Abschnitte im gesamten Projektverlauf.

Die Zielplanung

Bevor die Arbeit für alle beginnen kann, benötigt es selbstverständlich einen Auftrag durch den Kunden. Dieser definiert seine Anforderungen bzw. Erwartungen an das zu enstehende Produkt und bespricht diese mit dem Unternehmen. Das Unternehmen verpflichtet sich in seinem Lastenheft, was es alles umsetzen wird. Dadurch ist im Nachhinein auch sicher gewährleistet, was versprochen wurde und was nicht. Das Lastenheft ist also der Teil des Unternehmens, zu welchem man sich in Absprache mit dem Kunden verpflichtet. Erwartungen können nicht immer so umgesetzt werden, daher kann es hier zu Differenzen kommen.

Aus dem Kundengespräch geht das oben genannte Lastenheft hervor, aus welchem unterschiedliche User Stories gebildet werden. User Stories sind einzelne kleine Funktionalitäten oder Teile des Produkts, welche Schritt für Schritt durch die Entwickler umgesetzt werden müssen. Diese Funktionalitäten werden meist noch in ihrer Schwierigkeit geschätzt und daraus werden die Zeiten bis zur Umsetzung abgeleitet. Dies erfordert natürlich ein gewisses Maß an Erfahrung, weshalb dieser Vorgang nicht vom ersten Projekt an eine exakte Schätzung ergibt. Aus diesem Grund darf man auch nicht sofort verzweifeln, wenn es beim ersten Versuch etwas holprig lief. Ebenso ist es für Anfänger sehr schwierig eine Einschätzung zu geben, weshalb man hier in meinen Augen stark auf erfahrene Kollegen hören sollte.

Aber auch unter den erfahrenen Kollegen gibt es teilweise sehr große Differenzen beim Schätzen. In meinen Augen wäre es daher nicht verkehrt, wenn man ein Mittelmaß findet, welches zum höheren Wert tendiert.

Alle User Stories wandern samt ihren Schätzungen in den Product Backlog, der Katalog welcher alle Anforderungen enthält. Dieser ist der große Topf an Aufgaben, aus welchem das Team mit Aufgaben ausgestattet wird.

Der Ansprechpartner für alle Fälle

Natürlich braucht ein Team, in dem mehrere Personen mit unterschiedlichen Charakteren und Hintergründen zusammen arbeiten, einen Ansprechpartner. Dieser soll in jedem Fall für alle Teammitglieder erreichbar sein, so dass dieser bei Problemen zu Rat gezogen werden kann. Dieser Ansprechpartner wird – im Falle von Scrum – als Scrum Master bezeichnet und er verwaltet den Product Backlog. Ebenso moderiert er auch die Schätzungen der User Stories und leitet die Besprechungen. In der Praxis ist er – meiner Erfahrung nach – auch oft die Person, welche Kundengespräche führt und damit die Schnittstelle zwischen Team und Kunde bildet.

In der Theorie wurde uns gelehrt, dass dieser Scrum Master oft auch eine Person von außen ist. Diese Person wird durch das eigene Unternehmen beauftragt und soll dafür sorgen, dass das Team ohne Störungen reibungslos arbeiten kann. Es ist jedoch so, dass diese Person oft sehr teuer ist und man diesen Posten dann eher intern besetzt. Manchmal kann es auch vorkommen, dass nach einer gewissen Zeit diese Rolle eher weniger benötigt wird, da sich das Team sehr gut selbst organisieren kann. Für den Anfang ist es jedoch immer ratsam, wenn eine Person den Überblick behält. Insbesondere wenn man die Vorgehensweise frisch umgestellt hat und sich in einer Testphase befindet.

Planungsmeetings

Die Planungsmeetings sind dazu gedacht, dass man sich für den jeweiligen Zeitabschnitt genau ausdenkt, was erreicht werden soll. Man teilt also die komplette Entstehung in unterschiedliche Abschnitte. In den jeweils kleineren Abschnitten arbeitet man sich dann Stück für Stück zum fertigen Produkt vor.

Bei der Planung muss man dann ebenso beachten, dass man die Abschnitte sinnvoll gliedert. Die Grundlagen können beispielsweise nicht erst nach der Feinarbeit begonnen werden, da die Feinarbeiten auf den Grundlagen beruhen. Es muss also eine Basis gegeben sein, dass andere Aufgaben begonnen oder fortgeführt werden können.

Tägliche Meetings, ein Kernelement

Trotz Software, welche das Organisieren vereinfacht, ist der menschliche Kontakt nicht zu vernachlässigen – auch wenn es manche Personen behaupten. Gerade in Gesprächen lassen sich manche Dinge meist besser erklären, als sie aufzuschreiben. Hierfür gibt es tägliche Meetings, wo jedes Teammitglied erzählt, was es an diesem Tag (oder am Vortag) erledigt hat. Dazu können Rückfragen gestellt werden und jeder ist auf dem aktuellen Stand der Dinge.

Diese Meetings sind auch ein idealer Zeitpunkt, um das kurzfristige weitere Vorgehen zu besprechen und Fragen in die Runde zu stellen, wenn man bei seinen Aufgaben auf Probleme stößt. Zudem sind sie gut, um festzustellen, ob man die Anforderungen korrekt verstanden hat oder ob man eventuell andere Ansichten als das Team hat.

Mein persönlicher Eindruck

Mein eigener Eindruck zu einer agilen Arbeitsweise ist durchaus positiv. Es gibt zwar immer wieder Optimierungspotenzial, das liegt jedoch auch an den Personen, welche das ganze umsetzen. Die Kommunikation ist meiner Meinung das wichtigste Element, denn es ist wichtig, dass auch jedes Teammitglied zu den Meetings erscheint und informiert ist. Meinen ersten Eindrücken nach zu urteilen ist es jedoch auch genau der Punkt der Kommunikation, welcher in der Praxis oft verbessert werden müsste.

Durch die täglichen Meetings ist jeder immer auf dem aktuellen Stand der Entwicklung und weiß, an welchen Ecken es noch viel Arbeit gibt. Ebenso kann man sich bei Problemen sehr gut abstimmen und schnell Hilfe erhalten. Hier kann sich jeder, der von der speziellen Thematik Ahnung hat, einklinken und man muss nicht lange nach einem geeigneten Teammitglied suchen.

Dieser Artikel entstand durch meine Erfahrungen und Erlebnisse in der Praxis. Theoretische Grundlagen sind daher eher dürftig und an vielen Stellen ausgelassen. Ebenso fällt der Beitrag an manchen Stellen eventuell etwas kurz aus, da ich meine Erlebnisse etwas Revue passieren lasse.