Ich habe mal wieder etwas geschrieben bzw. an etwas mit geschrieben. Gemeinsam mit einem guten Freund habe ich den Artikel „Mit Geschichten zum Erfolg“ in der aktuellen Dotnetpro verfasst. Ziel dessen war einmal ohne die direkte Betrachtung von Scrum, Kanban und Co. über die Möglichkeiten aufzuklären die sich ergeben wenn man Anforderungen auf eine etwas andere Art als den typischen Use Case, nach ISO oder Sätzen wie: „The X shall Y“ verfasst.
Natürlich geht es dabei nicht zuletzt auch um Agilität und natürlich ist dieses Thema nicht unbedingt brand heiß oder absolut neu, aber uns ging es viel mehr darum die für den Entwickler wichtigen Kernfaktoren bei diesem Vorgehen hervorzuheben.
Zumindest aus meiner Sicht ist Agilität zu einem gewissen Grad zum Modewort verkommen, dass nicht selten genutzt wird wenn das Wort Chaos besser angebracht währe. Ein Prozess wird meiner Meinung nicht dadurch agil, dass die Anforderungen nur tröpfchenweise zu den Entwickler durchsickern. Er wird auch nicht dadurch agil, dass man jeden Morgen 15 Minuten im Kreis sitzt und über Probleme redet. Er wird agil, weil tatsächlich auf Veränderungen eingegangen werden kann ohne all zu große Reibungsverluste befürchten zu müssen und dafür ist es notwendig, dass das Team zu jeder Zeit den aktuellen Ist-Zustand der Software kennt und sich ebenso bewusst über den zukünftigen Soll-Zustand ist.
Kern dessen ist daher die User Story. Ganz einfach weil sie alle notwendigen Infos auf einen Blick darstellt ohne dabei ein bestimmtes Vorwissen vorauszusetzen. Sie ist einfach zu verstehen und verbietet die nachträgliche Diskussion darüber nicht. Im Gegenteil, sie fördert die Diskussion auf eine normalsprachliche Weise ohne das Geschwurbel, dass ich regelmäßig lesen muss weil irgend wer versucht sich nach allen Seiten hin abzusichern.
Genau diese Aussage ist mir aber in anderen Veröffentlichungen, Bücher ausgenommen, die ich bisher gelesen habe etwas zu kurz gekommen und so haben Stefan und ich uns darüber her gemacht das zentrale Wissen dazu zu destilieren und einmal ohne den Verweis auf Scrum usw. zusammen zu fassen, in der Hoffnung gleichzeit erklären zu können warum jedes einzelne Teammitglied davon profitiert.
