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.

„Deep Work“ als agile Praktik

Erstellt am 6 Dezember 2016
von Schreibe einen Kommentar

„Früher haben wir jeden Tag zwei bis drei Stunden in Meetings verquatscht, das war verschwendete Zeit“, sagte ein Entwickler kurz nach dem Beginn meines Engagements in seinem Scrum-Team zu mir. Aber dann: „Und jetzt quatschen wir den ganzen Tag im Team-Raum. Mit dem PO, mit UX- und Security-Experten oder weiteren Stakeholdern, um ‚schnell und direkt‘ Nachfragen zu Stories zu klären. Mit den anderen Entwicklern aus unserem Team, um Architekturen und Lösungskonzepte zu diskutieren. Mit den Kollegen aus anderen Teams, um Schnittstellen abzustimmen. Und jetzt mit dir, unserem Scrum-Master, weil ich davon genervt bin, dass ich nicht zum Coden komme. Vielleicht sollten wir das in der nächsten Retrospektive thematisieren; also schon wieder reden, reden, reden, anstatt zu arbeiten. Und oben drauf kommt noch die Zeit für die Selbstorganisation der Abteilung und die Beteiligung der Mitarbeiter an der Weiterentwicklung der Firmenziele.“

Wer ist der Architecture Owner?

Erstellt am 13 Januar 2015
von Schreibe einen Kommentar

SuperheroWer vertritt die Architektur gegenüber dem Product Owner, der sich primär für den  Business Value interessiert?
Wer ist dieser „Superheld“, der die Verantwortung trägt – ein „Architecture Owner“?

Produktionsseitige Anforderungen, die Produktion als Stakeholder

Erstellt am 24 Juli 2012
von Schreibe einen Kommentar

Der richtige Umgang mit den relevanten Stakeholdern ist ein Erfolgsfaktor für Entwicklungsprojekte. Während Anforderungen von Kunden, Anwendern, Auftraggebern, Normen, Zulassungsstellen die erforderliche Aufmerksamkeit bekommen, ist der Umgang mit wichtigen unternehmensinternen Anforderungsquellen wie der eigenen Serviceorganisation oder auch der Produktion noch häufig stiefmütterlich. Um letztere soll es in diesem Beitrag gehen, ist doch die kostengünstige, umweltverträgliche, ausschussarme,  zeitgerechte, ressourcensparende, flexible, qualitativ hochwertige Produzierbarkeit durchaus kritisch. Damit diesbezügliche Ziele von der Produktion erreicht werden können, muss die Produktentwicklung die Anforderungen der Produktionsorganisation kennen und verstehen. Designentscheidungen der Systementwicklung sind maßgeblich für die spätere Produzierbarkeit.