„Bye-bye Management! Warum Management verzichtbar ist und wie agile Arbeit heute aussehen kann“ – Vortrag am 8. November

Zur Veranstaltung über Agile Unternehmenskultur und -werte am 8. November in Wiesbaden konnte neben dem Beitrag von Sven Peters über die Werte des australischen Softwarehauses Atlassian ein weiterer interessanter Vortrag gewonnen werden.

Niels Pflaeging, Gründer des BetaCodex Network und Autor, spricht über seine Sicht auf die Organisationen der Zukunft. Und gerne einmal sind seine Thesen eine Breitseite für klassische Unternehmensorganisationen. Die Financial Times Deutschland sagte einst über ihn: „Wenn Pfläging die Dogmen des Managements durchschüttelt, zerbröseln sie in seinen Händen.“ Auch der Titel seines Vortrags am 8. November ist vielversprechend:

„Bye-bye Management! Warum Management verzichtbar ist und wie agile Arbeit heute aussehen kann“

Wirtschaft und Gesellschaft haben sich verändert, aber die Managementmethoden sind gleich geblieben. Vieles, was jahrzehntelang als Standard galt, muss heute hinterfragt werden: Zielverhandlungen, Organigramme, individuelle Mitarbeiterbeurteilungen, leistungsorientierte Vergütung, Budgets und Plan-Ist-Vergleiche – alles Standards, aber alles heute noch zeitgemäß? Und wenn nicht, wie kann man es heute besser machen? Was tritt an die Stelle von Anweisung, Anreizung, Zielvereinbarung, Planung und Fremdkontrolle?
Niels Pfläging zeigt, dass Unternehmen, die auf traditionelles Management verzichten, dauerhaft erfolgreicher, sind. Er zeigt, wie unternehmerische Führung nach den Gesetzen eines zeitgemäßen „Beta“-Kodex tatsächlich funktioniert und wie sich Unternehmen aus dem Klammergriff von Kommandokultur und Bürokratie befreien.

 

Die Anmeldung zu dieser kostenfreien Veranstaltung über Agile Unternehmenskultur und -werte erfolgt über die XING-Eventseite.

——–

Immer auf dem aktuellen Stand bleiben? Neue Artikel gibt es über FacebookTwitter, E-Mail (oben rechts) oderRSS-Feed.

Produktentwicklung auf die schlanke Art

Wie viele von den Funktionalitäten, die wir in Software einbauen, bringt unseren Anwendern wirklich einen Nutzen? Zu häufig wird diese Frage gar nicht gestellt. Woran liegt das?
Häufig scheint die Überzeugung zu sein, das viel auch viel hilft. Eine endlose Feature-Liste erscheint attraktiv. Genauer betrachtet stellen Features, die den Anwendern keinen echten Mehrwert liefern, eher einen Kostenpunkt dar. Sie müssen gewartet werden und erhöhen die Komplexität einer Software-Anwendung sowohl für die Anwender, als auch die Betreiber.

Der überzeugte Lean Startup-Anwender und Buchautor Ash Maurya berichtet in einem Blogpost darüber, wie er selbst vorgeht, um nur Features in seiner Software bereitzustellen, die auch wirklich einen Nutzen für einen Großteil der Anwender erzielen.

Sein „Framework“ hierfür besteht aus mehreren Elementen. Zu jeder Zeit wählt er einen zentralen Zielwert, der angestrebt werden soll. Beispielsweise die Quote von Neu-Anwendern, die für eine dauerhafte Nutzung der Software aktiviert werden kann. Zu jeder Zeit gibt es nur eine zentrale Zielsetzung, die mit den Feature-Entwicklungsbemühungen erreicht werden soll.

Auf dem Weg von Entwicklung bis dauerhafter Aufnahme einer Funktionalität in den Produktumfang durchläuft sie vier zentrale Schritte.
Die erste Stufe beginnt mit der Priorisierung des Backlogs. Da es einen zentralen Zielwert gibt, kann die Priorisierung nach dem Beitrag für diesen Zielwert, im Verhältnis zu den für die Realisierung anfallenden Kosten, erstellt werden.
Wenn die Priorisierung geklärt ist, wird als nächstes das Top-Item genommen und durch Kunden-Interviews abgeklärt, wo genau das dahinter liegende Problem liegt. Es geht an dieser Stelle nicht darum, was die Kunden wünschen. Vielmehr geht es darum, warum sie etwas wünschen. Ausgehend von den Rückmeldungen der Kunden wird dann entschieden, ob etwas gemacht wird oder der Feature-Wunsch verworfen wird.

In der zweiten Stufe wird dann entschieden, wie das Feature umgesetzt werden soll. Es werfen hierfür erste Screens gestaltet und dann mit den Kunden, die auch interviewed wurden, dazu befragt. Es werden dann üblicherweise mehrere Iterationen durchlaufen, bevor eine Umsetzung angedacht wird.

Die Funktionalität wird dann in einem Continous Deployment-Prozess realisiert. Mit Hilfe eines Feature Flipper Systems kann dafür gesorgt werden, dass die Features auf das Live-System eingespielt werden, ohne dass sie den Anwendern zugänglich sind, bis sie fertig sind. Nach Fertigstellung wird die Funktionalität einer selektierten Kundengruppe zur Verfügung gestellt und von denen ein qualitatives Feedback eingeholt. Wenn dabei Fehler auftreten oder das Feedback negativ ausfällt, können noch vor einem größeren Roll-out Korrekturen vorgenommen werden.

Es folgt die vierte Stufe, wenn das qualitative Feedback zufriedenstellend war bzw. Nachbesserungen erfolgt sind. Die Funktionalität wird allen Anwendern zur Verfügung gestellt und quantitative Metriken gesammelt. Während die Messungen laufen, wird mit der Arbeit an der nächsten Funktionalität gestartet, denn meist dauert die Erhebung der metriken etwas. Dann folgt eine Auswertung der Zahlen.
Die Kombination von qualitativem Feedback und quantitativen Metriken sorgt für eine gute Entscheidungsgrundlage. Nur, wenn die Funktionalität sich als förderlich für den zentralen Zielwert herausstellt, wird es dauerhaft in der Anwendung belassen. Ansonsten fliegt es konsequent raus.

Die folgende Präsentation stellt das Vorgehen von Ash Maurya dar:

How We Build Features

View more presentations from ashmaurya

——–
TIPPS UND TRICKS ZUM PRODUKTMANAGEMENT VON INTERNETANWENDUNGEN
Immer auf dem aktuellen Stand bleiben? Neue Artikel gibt es über FacebookTwitter, E-Mail (oben rechts) oder RSS-Feed.

%d Bloggern gefällt das: