you're reading...
Agile, Usability

Trends für Agile und Usability

Am Anfang des neuen Jahres plane ich meine groben Ziele. In diesem Jahr möchte ich eine bessere Überschneidung von „Agilen Methoden“ und „Usability Engineering“ erzielen. Bevor ich meine Aktionen plane, will ich erst mal festhalten, welche Trends ich für diese Themen erwarte…

Agile Methoden werden sich weiter durchsetzen
In den USA schreibt das Verteidigungsministeriums den Auftragnehmern vor, ihre IT Projekte mit agilen Methoden durchzuführen. Damit sind die agilen Methoden auch bei sehr konservativen Institutionen angekommen und werden sich auch in anderen Feldern weiter durchsetzen.

Siehe auch folgende Artikel von Jeff Sutherland:

Das Usability Engineering muß sich (weiter) dem agilen Vorgehen anpassen.
Der hauptsächliche Treiber der Entwicklung wird das agile Vorgehen sein. Und damit müssen sich die Techniken, Tools und Methoden des Usability Engineering sich in die Strukturen einfügen, die agile Methoden wie SCRUM oder XP vorgeben.

Das iterative Vorgehen in Sprints und eine einheitliche, umfassende Benutzererfahrung ist dabei eine besondere Herausforderung. Ein kontinuierliches, konzeptionelles Prototyping könnte hierzu ein Schlüssel sein, auf jeden Fall werde ich diese Idee vertiefen. Weiterführende Artikel findet Ihr hier:

Agile Projekte werden sich in immer diverseren Kontexten im Projektgeschäft einfügen.
Die agilen Methoden in der Entwicklung werden auf andere Abteilungen und Organisationen treffen, die gänzlich verschiedenen Vorgehensmodelle verwenden. Gerade in einem Konzern wird es viele Schnittstellen z.B. zum Controlling, den Fachbereichen, den Betrieb und anderen Abteilungen geben, die ganz anders ticken und nicht unbedingt von einem iterativen Vorgehen profitieren.

Und spätestens beim Geld hört der Spaß auf: das agile Vorgehen trifft hier auf eine Vielfalt von Budgetentscheidungen. Eine der Herausforderungen bei der Vergabe von vielen Projekten wird der Festpreis sein, ich bin gespannt ob und welche Lösungen sich dafür entwickeln werden.

Agile Methoden müssen besser skalieren
Bisher nehmen die (meisten) Verfechter und Evangelisten der agilen Methoden (zumindest unbewusst) an, dass sich die Mitglieder untereinander wenig voneinander unterscheiden. Und dass sie damit auch beliebig an jeder Stelle des Projekt einsetzbar sind bzw. sich Aufgaben aus dem Backlog selbstständig nehmen. („Hey, ich wollte schon immer mal eine relationale Datenbank in der 4. Normalform refaktorieren. Danach mache ich ein paar Icons fertig.“)

In der Realität spezialisieren sich die IT Kollegen auf nur einige, wenige Themengebiete, zum Beispiel auf Frontend, Backend, Projektmanagement usw. Durch ihr tiefes Know How und ihre Expertise in ihren angestammten Feldern, sind sie darin auch effektiver und produktiver als andere Mitarbeiter. Und es gibt viele Aufgaben, die kann oder sollte nur ein Spezialist lösen. Nur sind die gefragten Spezialisten oft nicht oder nur bedingt verfügbar, oder ihre Skills werden nur zu bestimmten Zeiten gebraucht. Damit stellt sich die Herausforderung an die agilen Methoden, einzelne Mitglieder/Spezialisten von Zeit zu Zeit ein- und auszugliedern.

Viele Firmen verwenden Outsourcing und lassen ihre Projekte von externen Anbietern entwickeln, oft auch in Ländern wie Ukraine, Indien oder China. Damit ist vor allem die direkte Kommunikation zwischen Projektmitgliedern betroffen, und schnelle Absprachen, Ad-hoc Entscheidungen etc. sind viel schwerer durchzuführen, als bei einem Team das zusammen an einem Ort sitzt. Hier sehe ich einen Bedarf, geeignete Tools zu wählen, die die Leichtigkeit der Kommunikation erhalten oder wiederherstellen,z.B. Kanban Boards, Chatrooms u.a.

Agile Projekte müssen ihr ROI beweisen.

Ich selbst bin überzeugt, dass ein agiles Vorgehen für die meisten IT Projekte das beste Vorgehen ist. Aber die Vorteile, die ich wahrnehme, sind eher qualitativer Natur: z.B. das reduzierte Risiko, die gesteigerte Produktivität oder die bessere Kommunikation sind eher „weiche Faktoren“. Vor dem gleichen Problem stehen auch Usability Experten: die qualitativen Faktoren mit einem niet- und nagelfesten Business Case zu belegen und so den Return on Investment darzulegen.

Obwohl Scrum & Co so weit verbreitet und seit Jahren etabliert scheinen, gibt es nur wenige Kennzahlen oder Metriken zum ROI! Um die agilen Methoden weiter zu verbreiten – in andere Abteilungen, Fachgebiete usw. – braucht es solche Belege für einen besseren ROI.

Advertisements

Diskussionen

Die Kommentarfunktion ist geschlossen.

Brian Heumann

%d Bloggern gefällt das: