Vier gewinnt – Die Teamgröße macht‘s

Erstellt am 30 August 2016
von Schreibe einen Kommentar

Exponential FunktionVielfach wurde bereits über die Gründe geschrieben, dass kleinere Teams produktiver seien. Aber warum ist das so? Gefühlt würde ich sagen: „Na klar, je mehr Beteiligte, desto mehr Informationen und Meinungen sind zu verarbeiten.“ Und genau hierauf möchte ich in diesem Blogbeitrag eingehen: Die Entdeckungen der Gehirnforschung gepaart mit unseren eigenen Erfahrungen aus der Praxis und was wir aus der Korrelation lernen können.

Agile Softwareentwicklung benötigt mehr Werkzeuge

Erstellt am 23 August 2016
von Schreibe einen Kommentar

In den 90er Jahren und noch zu Beginn des Jahrtausends haben wir sogenannte CASE-Tools (Computer Aided Software Engineering) verwendet, um zuerst ein Design in Form eines großen, komplett durchdachten UML-Modells zu erstellen, bevor wir anfingen, die Details zu kodieren.

Jetzt mal ernsthaft…

Erstellt am 16 August 2016
von Schreibe einen Kommentar

Gehört die Frage nach „Neuer Führung“ zu „Arbeit 4.0“ oder doch eher zur „Digitalisierung“? Vielleicht tendenziell zu „New Work“ oder „GenY“? Wahrscheinlich kann es aber auch sein, dass es etwas mit der „Agilen Transformation“ zu tun hat. Oder war es „Transition“? (und wo war nochmal der Unterschied?)

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ß!

Können mit den Organisationsstrukturen des Industrialisierungszeitalters die Herausforderungen der Informationsgesellschaft des Wissenszeitalters gemeistert werden?

Erstellt am 26 Juli 2016
von Schreibe einen Kommentar
This entry is part 1 of 4 in the series Agile Organisationsentwicklung

Während sich die Gesellschaft weiterentwickelt hat, folgen viele Organisationsstrukturen immer noch den Regeln der Industrialisierung [1]. Die Hauptproblemfelder, warum Projekten in diesem Umfeld scheitern, sind:

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.

Das funktioniert bei uns nicht!

Erstellt am 13 Juli 2016
von Schreibe einen Kommentar

Diese oder ähnliche Aussagen („das geht bei uns gar nicht“) höre ich oft als Reaktion auf Änderungsvorhaben im agilen Umfeld. Dahinter steckt nicht nur normales Unbehagen im Angesicht von etwas Neuem und Unbekanntem. Es ist oft das intuitive Verstehen, dass dieses Neue nicht in den eigenen Kontext, in die gelebte Kultur passt.

autoSWIFT: Was können wir zur Beschleunigung von Innovationen aus dem Agilen Manifest lernen?

Erstellt am 27 Juni 2016
von Schreibe einen Kommentar

Komplexe Fahrzeugfunktionen wie das autonome Fahren, Car2Car-Kommunikation und Fahrerassistenzfunktionen stellen die Automobilindustrie vor neue Herausforderungen.

Eigentlich fast fertig? Die Definition of Done!

Erstellt am 17 Mai 2016
von Schreibe einen Kommentar
Definition of Almost Done

Definition of Almost Done

Es ist Freitag Vormittag, 09:00 Uhr; Zeit für unser Daily. Ein Kollege zeigt auf das Taskboard und sagt “Diese User Story ist eigentlich fertig und kann in unsere Done-Spalte gehängt werden”. Wörter, wie “eigentlich” oder „fast“ machen mich stutzig und ich kann nicht anders als nachzufragen, ob die Definition of Done für diese User Story erfüllt ist. Mein Kollege verneint und ergänzt: “Es fehlt noch die Betriebs-Doku”. Ich mache meine Kollegen aufmerksam, dass alle Kriterien der Definition of Done erfüllt sein müssen, damit eine User Story in die Spalte Done geschoben werden kann und somit als abgeschlossen gilt.