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. 

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.

Kanban als Methode zum Umgang mit Änderungen im RE

Erstellt am 22 November 2017
von Schreibe einen Kommentar

Beim RE kommt man nie umhin, auch über Anfragen für weitere Anforderungen zu sprechen. Hierbei geht es jedoch nicht um späte Anfragen für Änderungen nach einem Design-Freeze oder nach Serienreife, welche über ein Change-Control Board laufen, sondern um Anfragen, die bestenfalls bereits in einer frühen Entwicklungsphase berücksichtigt werden sollten. Warum ich heute über Kanban schreibe ist, dass diese Anfragen strukturiert, visualisiert, nachvollziehbar und transparent im Team dargestellt werden müssen.  Hierfür eignet sich beispielsweise Kanban. Wie stellt man also sicher, dass Entwicklungsprojekte Anfragen von Kunden umfassend dokumentieren und umsetzen?

Vorbereitet sein auf den digitalen Wandel

Erstellt am 25 September 2017
von Schreibe einen Kommentar

Die „Digitale Revolution“ hat begonnen, sie verspricht uns viel: Internet of Things, digitale Produktion und Industrie 4.0, autonome und vernetzte Systeme… Digitalisierung und digitale Technologien verändern unser Alltagsleben. Keiner weiß genau, wie unsere Welt am Ende dieser digitalen Revolution wirklich aussehen wird. Und vor allem: Welche sozialen und wirtschaftlichen Konsequenzen wird die Digitalisierung der Welt nach sich ziehen? Und können wir uns darauf vorbereiten?

Weniger ist mehr

Erstellt am 20 September 2017
von Schreibe einen Kommentar

Wir leben in einer Leistungsgesellschaft. Etwas leisten bedeutet, etwas zu machen. Wir werden danach beurteilt, was wir machen. Wenn etwas nicht funktioniert, müssen wir etwas dagegen machen. Wir denken praktisch immer additiv. Wenn etwas nicht funktioniert, mach mehr, und zwar typischerweise mehr vom Gleichen, also von dem, was eh schon nicht funktioniert hat.

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.

Anforderungen strukturieren – 2. Techniken

Erstellt am 26 April 2017
von 1 Komment
This entry is part 2 of 3 in the series Anforderungen strukturieren

Im letzten Blog „Anforderungen  strukturieren – 1. Kriterien“ haben wir vorgestellt, welche Kriterien für die Strukturierung von Anforderungen relevant sind. Heute stellen wir Ihnen im 2. Teil dieser Blog-Serie ein paar Ideen und Konzepte vor, die die Anforderungsstrukturierung ermöglichen. Wir wollen die Frage beantworten: „Welche technischen Möglichkeiten gibt es, um Anforderungen zu strukturieren?“

Wenn der Sturm sich nicht legt, dann bauen wir eben Windmühlen

Erstellt am 27 September 2016
von Schreibe einen Kommentar

Titel-FallschirmspringerAufblende: Seit einem halben Jahr diskutieren Sie nun ein fachliches Thema mit mehreren Fachabteilungen. Aber der Sturm der Konflikte will einfach nicht aufhören. “Soll ich etwa eine Windmühle bauen?” denken Sie, schon fast verzweifelt.

Ziele und Nutzen des systematischen Umgangs mit Anforderungen

Erstellt am 19 Juli 2016
von Schreibe einen Kommentar

Ziele von Anforderungen und Requirements EngineeringKürzlich wurde ich wieder gefragt, wie sich der Aufwand von Requirements Engineering rechtfertigen lässt. Immer noch beobachte ich, dass die Tätigkeit des “systematischen Umgangs mit Anforderungen”, dies ist eine moderne Übersetzung des englischen Begriffs “Requirements Engineering and Management”, zu wenig Akzeptanz innerhalb der Unternehmen findet. Es werden verschiedenste Gegenargumente vorgetragen: Für das Projektmanagement ist es viel zu teuer, für die Entwickler und Fachabteilungen ist es “unmotivierter Mehraufwand” oder “Overhead für Dokumentation”, für manche agile Teams ist es “alter Hut” und für erfahrene, gewachsene Fachabteilungen ist es “nicht notwendig, das haben wir schon immer so, ohne Anforderungen, gemacht”.

Gewiss, der systematische Umgang mit Anforderungen kostet Zeit und Geld, und der Aufwand muss adäquat an die Struktur und die Gegebenheiten der Organisation, des zu entwickelnden Produktes oder Dienstleistung angepasst werden.