Entwickeln mit agilen Frameworks

Erstellt am 1 August 2018
von Schreibe einen Kommentar

Viele versprechen sich von agilen Vorgehensweisen die reibungslose Umsetzung von Entwicklungsprojekten. Unterstützung findet man in vielen verschiedenartigen „agilen Frameworks“. „Agile“, gesprochen: /ˈæʤl/, bringt natürlich nicht die Lösung aller Probleme. Jedoch kann ein Vorgehen anhand agiler Vorgehensweisen und Frameworks deutlich bei der Entwicklung helfen, gerade wenn man mit sich stark verändernden Märkten und komplexer werdenden Systemen konfrontiert wird.

Requirements Engineering für die 3 Amigos

Erstellt am 11 Juli 2018
von Schreibe einen Kommentar

Software beginnt als Idee, als eine Vision. Wenn der Visionär selbst Softwareentwickler ist, reicht das vielleicht schon, um ein großartiges Produkt zu entwickeln. Wenn dieser Visionär aber kein Entwickler ist, muss er das, was in seinem Hirn ist, in die Hirne anderer übertragen, die mit ihm die Software entwickeln. Und das geht nicht ohne Kommunikation.

shutterstock-

Agilität – eine Frage der Haltung

Erstellt am 26 Juni 2018
von Schreibe einen Kommentar

Wenn ich gefragt werde, was Agilität für mich ausmacht, dann fallen mir nicht die Tools und die Praktiken ein. Agilität ist eine Haltung, die viele verschiedene Aspekte hat.  Für mich sind gerade zwei  Prinzipien relevant, die die indische Forscherin Saras Sarasvathi beschrieben hat. In ihrer Theorie des Effectuation geht es darum, das Naheliegende zu tun und radikale Selbstverantwortung zu üben – in Bezug auf meinen Anteil am Produkt, als auch in Bezug auf die Kommunikation und Zusammenarbeit mit anderen.

Viele Menschen nehmen diese Haltung von sich aus ein – andere werden sich schwertun. In ihrer Organisation werden beide Spektren vertreten sein. Es gilt, die richtige Haltung zu erkennen, zu fördern und gegebenenfalls Haltung ganz neu zu lernen. Das Schöne ist, es gibt einen Weg das zu tun. Und diesen Weg zeigt uns Saras Sarasvathi. Die indische Proffessorin hat erforscht, warum Menschen erfolgreich sind. Ihre Zielgruppe waren Entrepreneure. Sie hat sich Handlungsmuster und Entscheidungsmaximen angesehen und daraus Prinzipien abgeleitet. Entrepreneure – also Startup-Gründer- sind deswegen relevant für uns, weil diese am unmittelbarsten mit verändernden Märkten, als auch mit neusten Technologien arbeiten. Also auch für uns eine gute Quelle, um sich was abzuschauen.

 

Affordable Loss statt Return on Invest

Ein Entrepreneur evaluiert seine Ressourcen und frägt sich dann, welche dieser Ressourcen er/ sie investieren kann, ohne sich selbst existentiell zu bedrohen. Nicht der ROI entscheidet, was zu tun ist, sondern der affordable loss. Nicht „was kann ich gewinnen?“, sondern „was darf ich verlieren?“ treibt meine Handlungen. Das diszipliniert, das Naheliegende zu tun und den ersten kleinen Schritt zu machen (die 15% Lösung), statt jahrelang auf den einen Investor, die eine gute Idee zu hoffen, die dann nie kommt. Im Scrum ist das mein stehendes Produktteam, und mein Sprint. Ich weiß, wieviel ich investieren muss, was mein Einsatz ist. Ebenfalls wie beim Startup kann ich in der Produktentwicklung im Komplexen nicht wissen, was mein Ergebnis sein wird. Ist das Ergebnis nicht das, was ich brauche, sollte ich umsteuern – pivot genannt. Ich weiß jetzt, dass meine Ressourcen (mein Scrum Team) mit neuen Zielen vermutlich besser investiert sind. Iteration für Iteration kann ich jetzt sehen, ob zu den eingebrachten Ressourcen neue Ressourcen oder Stakeholder dazugekommen sind. Ich kann so neue Ziele definieren und gegebenenfalls skalieren. So können sich auch Hindernisse oder Zufälle später als nützliche Ressourcen erweisen. Das beste Beispiel ist dafür die Zitrone – wenn man direkt reinbeißt ist die Schale bitter und das Innere sauer. Wenn ich das Ganze aber mit den richtigen Zutaten mische, dann bekomme ich Limonade. Und was kann an einem so schönen Sommertag erfrischender sein?

 

Radikale Selbstverantwortung

Doch der zentralste Punkt ist der der radikalen Selbstverantwortung. Stellvertretend dafür steht das Bild des Piloten. Steuert dieser auf einen Berg zu, so hat er zwei Möglichkeiten – zum einen, er schreit den Berg oder seinen Co-Piloten an, der Berg möge doch aus dem Weg gehen. Oder er berechnet, wie lange es denn dauert, bis der Berg von alleine errodiert? Alles nicht das, was ein Pilot machen würde, oder? Er fokussiert sich auf das, was er ändern kann.  Nur das, was man selbst verantwortet, kann man auch verändern. Mit dieser Haltung wird es einfacher, Ownership für die erzeugte Qualität zu übernehmen. Echte Craftsmanship ist dann gefragt. Doch was ist, wenn ich der Einzige in meiner Firma, in meinem Unternehmen bin, der diese Haltung verinnerlicht? Wir glauben, dass Haltung nur dann gelernt werden kann, wenn sie auch vorgelebt wird. Wenn der Einzelne sich selbst nicht mehr so wichtig nimmt, und sich in den Dienst des Ganzen stellt, können andere von ihm lernen. Ein zweiter Schritt ist die Dringlichkeit. Wenn durch Transparenz jedem klar ist, was gerade passiert, wenn die Dringlichkeit von Veränderung erlebt und gespürt werden kann, dann können alle zusammenhelfen und das Ruder herum reißen.

Es gibt noch viele weitere Schritte, die zur agilen Transformation von Unternehmen beitragen können. Lesen Sie dazu unsere Landscape der Agilen Transformation.

Die Haltung der Agilen Welt erfordert viel Disziplin. Es ist mit Sicherheit nicht der leichte Weg, aber der, der Erfolg zumindest wahrscheinlicher werden lässt, in einer Welt, in der nichts sicher ist. Da ist es gut, jemanden an der Hand zu haben, der eine Außenperspektive liefern kann – und der Erfahrung mit dem Vorleben der Agilen Haltung hat. Gerne unterstützen wir Sie dabei.

Anforderungen mit User Stories und Akzeptanzkriterien agil managen – nur wie?

Erstellt am 25 Januar 2018
von Schreibe einen Kommentar

Haben Sie sich auch schon mal gefragt, wie Sie Anforderungen in Ihrem Produktentwicklungskontext mit User Stories systematisch strukturieren sollten? Unter ständig einprasselnden Kundenäußerungen und neuen Erkenntnissen sollen alle Beteiligten wissen, was gefordert ist. Zudem soll genügend Information vorhanden sein, damit das Geforderte umgesetzt werden kann.
Die Grundlage für diese Fragestellungen bilden Anforderungen. Anforderungen stellen das Bindeglied zwischen Kundenwunsch und dem Produkt(inkrement) dar. In vielen Projekten wird die Frage nach einer Systematik zur Strukturierung von Anforderungen gestellt. An dieser Stelle will ich eine Vorgehensweise vorstellen, um mit Hilfe des sog. generischen Informationsmodells die erforderlichen Verantwortlichkeiten zu klären. Dabei kommen User Stories und Akzeptanzkriterien zum Einsatz.

Abbildung 1: Generisches Informationsmodell für Anforderungen (angelehnt an [2])

Warum Agil?

Erstellt am 19 Januar 2018
von Schreibe einen Kommentar

Wir bei HOOD hören die Frage “Warum Agil ? öfters und stellen diese Frage auch ebenso häufig. Um beim Finden einer Antwort zu helfen, haben wir uns überlegt, wir gehen einen für uns neuen Weg. Es ist ein Film entstanden, welcher einen kleinen Einblick geben soll, warum Agilität sinnvoll sein kann. Wenn Sie das auch so sehen oder vielleicht doch ganz anders, dann freuen wir uns auf Kommentare und Diskussionen.

Sie haben weitere Fragen?

Wenn Sie weitere Fragen haben, welche Ihnen auf der Zunge liegen, dann schreiben sie uns. Das HOOD-Videoteam (bestehend aus Alejandra Armendáriz, Moez Kribi und Alexander Holike) möchte die meist gestellten Fragen in nächsten Videos beantworten, getreu unserem Motto „Gemeinsam Neues voranbringen“.

Sollten Sie mit ihrer Organisation agil werden wollen, sei Ihnen unser Blog-Artikel von Florian Engel empfohlen: Warum sie als Unternehmen erfolgreicher sind. 

Agile Engineering

Erstellt am 13 Dezember 2017
von Schreibe einen Kommentar

Die Autoren Arthur Kolb und Philipp Hecker gehen der Frage nach, ob sich Managementmethoden der agilen Softwareentwicklung in traditionellen Unternehmen (beispielsweise im Maschinenbau) anwenden lassen, und bewerten den Erfolg der eingeführten Methoden anhand der Mitarbeitermotivation [1].

Ausgehend von der agilen Entwicklungsmethode Scrum schlagen die Autoren vor, agile Methoden stufenweise einzusetzen, wobei der Umfang und die Intensität jeweils von der Komplexität sowie der Mitarbeitereinbeziehung abhängen. Hierzu stellen sie eine Anwendungsentscheidungsmatrix vor (Agile Application Map siehe [1]), die im Folgenden kurz vorgestellt wird.

Sprinten Sie schon, oder flüchten Sie noch?

Erstellt am 29 November 2017
von Schreibe einen Kommentar

Viele Entwickler wissen die Vorteile agiler Vorgehensweisen zu schätzen – doch es gibt auch eine große Zahl kritischer Stimmen. Die Stimmen derer, die von Schlagworten wie “agile”, “Scrum” oder “Sprints” rein gar nichts halten. Ich räume ein, dass agile Entwicklung nicht für jedes Projekt geeignet ist. Doch ich möchte in diesem Blog einem ganz anderen Phänomen auf den Grund gehen, welches die agile Entwicklung oftmals in schlechtem Licht dastehen lässt.

Ein Hardware Scrum Hackathon

Erstellt am 15 Juni 2017
von Schreibe einen Kommentar
This entry is part 1 of 1 in the series Hardware Scrum

Natürlich funktioniert Scrum auch für Hardware- und Systementwicklung. Dafür gibt es inzwischen genügend erfolgreiche Beispiele, viele an denen HOOD aktiv mitgearbeitet hat. Klar, es gibt ein paar Besonderheiten und einige Herausforderungen sind anders gelagert als in reinen Softwareentwicklungen, aber der Methoden-Bauchladen ist inzwischen voll genug um für unterschiedlichste Domänen passende Praktiken anbieten zu können. Einen signifikanten Unterschied gibt es aber nach wie vor in der Menge an Skepsis, die uns entgegen schlägt, wenn wir HW- und Systemingenieure in der agilen Transformation begleiten. Dabei ist der Wunsch, in kürzeren Zyklen risikoärmer auf Kundenfeedback reagieren zu können, durchaus genauso stark ausgeprägt wie bei den Softwareentwicklern.

Die abgespeckte Sprint-Retrospektive

Erstellt am 24 November 2016
von Schreibe einen Kommentar

Wenn Sie als Scrum Master arbeiten, dann erleben retro Sie wahrscheinlich auch, dass die Retrospektive nicht zu den heiß geliebten Scrum-Events gehört.  Ich habe aber die Erfahrung gemacht, dass Retrospektiven wirklich etwas bringen, nämlich Reflektion und Kommunikation darüber, was verbessert werden kann.

Ich bin daher ständig auf der Suche nach neuen Formaten, die von den Teams als nützlich empfunden werden. Das strikte Festhalten an 5 aufeinander folgenden Phasen ist meiner Erfahrung nach nicht notwendig, und manchmal sogar kontraproduktiv.

Scrum – the hard parts 2: sprint harder

Erstellt am 9 August 2016
von Schreibe einen Kommentar
This entry is part 2 of 2 in the series Scrum - the hard parts
Sprint_harder

Quelle: pixabay

Im ersten Teil dieser Serie habe ich meine persönliche Favoritenliste der „hard parts“ von Scrum vorgestellt und wie Sie diese gekonnt umschiffen können.

Auch im zweiten Teil möchte ich Ihnen einen bunten Strauß an Bad Practices und Workarounds anbieten – aus der Praxis, für die Praxis. Scheitern garantiert.

Viel Spaß!