Seit Jahren wird versucht die agile Arbeitsweise aus der IT-Softwareentwicklung in die sogenannten alten (und manchmal auch analogen) Industrien zu verpflanzen. Dabei ergeben sich die unterschiedlichsten Lösungen aus Ausprägungen. Dies beruht vor allem darauf, dass agile Umsetzungszyklen je nach Produkt und Branche eine ganz andere Ausprägung haben. An verschiedenen Kernelementen agiler Organisation lässt sich dies sehr gut aufzeigen.
User Story – Die Anforderungen werden zumeist als User Stories definiert, die die Vorteile einer innovativen Neuerung in einer potenziellen Kundennutzung aufzeigen. Dies kann dann in Einfachheit, Zeitersparnis oder auch in emotionalen Effekten resultieren. Diese Beschreibung aus Nutzerperspektive ist dann allerdings keine exakte Grundlage für eine Quantifizierung bzw. Bewertung der zu erstellenden Neuerung und möglicherweise kein zwingender Grund für eine Kaufentscheidung. Hier muss die User Story weiterentwickelt werden und um geeignete weitere Research Untersuchungen. Hier kann es passieren, dass der erste agile Ansatz im Sinne von schnell und direkt mit einer klassischen Vorgehensweise verheiratet werden muss. Das wie kann so schon früh in die Prozesse eingreifen.
MVP und Prototyping sind die potenziellen nächsten Stopper in der konkreten Umsetzung von Agilität. Auch das Minimum Viable Product als minimale, lauffähige Produktversion bietet vielfältige mögliche Ausprägungen und Einschränkungen:
Ist es eine erste Kundenakzeptable Lösung oder fehlen noch wichtige Elemente wie ein Bedienkonzept und User Interface.
Ist der MVP bereits so weit designt, dass potenzielle emotionale Kaufanreize sichtbar werden?
Auch die Fragestellung, was ist ein Prototyp und wo fängt der MVP an, ist in der Softwareentwicklung sicherlich einfacher zu entscheiden als in der Baumaschinenindustrie.
Insbesondere da, wo die agile Vorgehensweise auf klassische Unternehmensfunktionen trifft, bleibt viel Spielraum für individualisierte agile Prozessstrukturen. Insbesondre große börsennotierte Unternehmen sind in Planungssysteme wie SAP und Veröffentlichungspflichten eingebunden, die wenig Flexibilität zulassen. Das sind denkbar schlechte Voraussetzungen für eine agile Budgetplanung. Auch im Bereich des Controllings werden Ziele festgelegt, aufgesplittet und die Erreichung kontrolliert. Dies ist am einfachsten auf Basis konkreter Zahlen zu bestimmten Terminen. „Fragen Sie noch einmal in 14 Tagen nach dem momentanen Sprint“ wird den wenigsten Controllern eine ausreichende Perspektive sein, genauso wie weiche Faktoren, „Machen sie sich keinen Kopf, die Stimmung im Team ist super!“.
So muss jedes agile Entwicklungsprogramm seinen eigenen Entwurf agil entwickeln. Die Herausforderung ist dabei Offenheit und die Gabe bessere Entwicklungen zu erkennen.
Für mehr Blogs und agiles Projektmanagement. Klicken Sie hier: https://www.soulbrands.de/startseite/blog/
Brauchen Sie einen Experten für ihr Projekt, dann schauen Sie hier: https://www.soulbrands.de/das_soulbrands_portfolio/