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. 

Mit Kanban den Schuldigen finden!

Erstellt am 16 Januar 2018
von Schreibe einen Kommentar

Neulich hat sich Bernd sehr über seinen Kollegen Günther geärgert. Erst hat er ihm fest zugesagt die Schnittstelle zu implementieren, zu testen und auch noch im Wiki zu dokumentieren. Dann verschob er immer wieder die Termine und zuletzt reduzierte er seine zugesagten Leistungen. Bernd war dann froh, nicht noch die Implementierung machen zu müssen. Hatten seine Kollegen ihn also zurecht unter vorgehaltener Hand vor Günther gewarnt? Da traf es sich gut, dass Bernd von einem Vorgehen hörte, das Kollegen wie Günther sicher entlarvt.

[Source 1]

Die Kunst eines Teams, sich selbst zu organisieren

Erstellt am 9 Januar 2018
von 2 Kommentare

Abenteuer und eine Kiste voller Gold und Perlen! Zu meinem elften Geburtstag hatte ich mir eine Schatzkarte gewünscht. Ich wollte meinen Mut beweisen und selbständig und unabhängig sein. Heute weiß ich, der größte Reichtum ist die Gruppe von Menschen, mit denen man tagtäglich zusammenarbeitet. Und das größte Abenteuer ist es, ein Team dahin zu begleiten, die Kunst der Selbstorganisation zu lernen.

Mein erstes selbstorganisiertes Team vor 20 Jahren ergab sich eher zufällig: die Leute, die uns sagen sollten, was wir wie zu tun hatten, hatten sich schlichtweg geweigert, diese Rolle zu übernehmen. Das klappte zufällig ganz gut – irgendwie war jeder in dem Maße eingebunden, in dem er es wollte. Die Arbeitsergebnisse stimmten. Kein Grund zur Beschwerde.

Als der System Product Owner mit dem Daily Build den Stairway to Heaven hinaufstieg

Erstellt am 10 Oktober 2017
von Schreibe einen Kommentar
This entry is part 4 of 4 in the series Agile Organisationsentwicklung

Giorgio Vasari II - Jacob's Dream - Walters 372508

Dass neue Technologien die Arbeitswelt verändern, manchmal schnell, manchmal langsam und unmerklich, das ist heutzutage offensichtlich. Dieser Wandel vollzieht sich auch in der Arbeitswelt der Erfinder und Entwickler. Es fängt damit an, dass wir am Entwicklungsplatz Neuerungen in den Entwicklungsgegenstand einbringen können. Dieser wird dann virtuell gebaut und wir können sofort testen. Klingt jetzt nicht atemberaubend, nur war das früher mit viel mehr Wartezeit verbunden.

Warum sind agile Teams produktiver?

Erstellt am 3 Mai 2016
von Schreibe einen Kommentar

Was macht gute agile Teams aus? Nach meiner Erfahrung spielen vor allem folgende Faktoren dabei eine entscheidende Rolle:

  • die Größe des Teams,
  • die Möglichkeit, den Goldstandard der Kommunikation zu nutzen, die Kommunikation von Angesicht zu Angesicht,
  • die gute Mischung der Fähigkeiten (cross functional team) und
  • die Stabilität über einen längeren Zeitraum.

iStock_000008364248Small

Die Größe des Teams ist dabei wohl der entscheidende Faktor. Dies wird auch durch eine zunehmende Zahl von Studien belegt.

„Tooleinführung?”. „Ja klar, äh nein, ich mein Jein!“

Erstellt am 29 Februar 2016
von Schreibe einen Kommentar
This entry is part 2 of 2 in the series Storytelling

Im letzten Artikel unserer Blogserie beschäftigten wir uns mit den alltäglichen „Impediments“ eines  agilen Entwicklerteams. Nachdem das Product Backlog und das Sprint Backlog kurzfristig Opfer einer Reinigungsfachkraft geworden sind, wurde der Wunsch nach einem Werkzeug unter dem Team laut, um die Ergebnisse nachhaltig zu digitalisieren.

Wer bin ich – und wenn ja, wieviele? Requirements Engineers in der Sinnkrise…

Erstellt am 9 September 2014
von Schreibe einen Kommentar
This entry is part 1 of 1 in the series Casting für Product Owner

Und es trifft nicht nur die Requirements Engineers (REs), es trifft auch die Business Analysten (BAs), wie ich im Gespräch mit einer Teilnehmerin am Scrum Day erfuhr: „Unsere Entwicklung arbeitet jetzt mit Scrum – und ich weiß gar nicht mehr, was meine Aufgabe ist…“. Dabei ist das Arbeiten als RE/BA in einem Scrum Team herrlich. So vielfältige Aufgaben und Möglichkeiten, sich und sein Wissen einzubringen, habe ich bisher nur beim Arbeiten in einem agilen Team gehabt. Der Transfer der agilen Werte und Prinzipien auf das Requirements Engineering und die Rolle Requirements Engineer in einem agilen Umfeld ist eine Herausforderung für viele Menschen und Organisationen. Die heutigen Zertifizierungen am Markt zu Scrum/Agile und Requirements Engineering haben eines gemeinsam: Sie konzentrieren sich entweder auf das Thema Agilität/Scrum oder auf das Thema Requirements Engineering. Auch “Agile Extensions”, wie sie der BABoK oder das PMI veröffentlicht haben, ergänzen nur die agile Sichtweise, sie bieten keine übergreifende integrierte Sicht. Meine Erfahrung in der Arbeit mit agilen Teams und Organisationen auf dem Weg zu mehr Agilität zeigt jedoch, dass gerade die Verbindung beider Themen in der Praxis Schwierigkeiten macht. Die Transferleistung gelingt nicht oder nur schwer.

Die Qual der Wahl – das Konferenzprogramm der Manage Agile 2014 steht fest

Erstellt am 29 Juli 2014
von Schreibe einen Kommentar

manageagile_2014_quadrat_500pxWir Frauen sind es ja eigentlich gewöhnt aus einem überreichen Angebot auswählen zu müssen. Das geht morgens schon los mit der Frage „Was soll ich anziehen“, setzt sich in der Mittagspause fort mit der Entscheidung ob „Salat, Gemüse, oder doch das Schnitzel“ und (ja, ich bediene jetzt wirklich jedes Klischee) endet mit Verlustgefühlen oder Gewissensbissen nach dem Besuch im Schuhladen (je nach Anzahl der erworbenen Paar Schuhe). Und nein, Sie sind nicht aus Versehen auf dem Blog einer Frauenzeitschrift gelandet – gleich geht’s weiter mit agil.

Xtreme Simplicity – mach’s doch mit der Hand!

Erstellt am 6 Mai 2014
von Schreibe einen Kommentar

Kürzlich nahm ich an einer Story Time eines Scrum Teams teil. Das Ziel war, Klarheit in einige User Stories zu bringen, um diese dann schätzen zu können. Als die Zeit für die Schätzung gekommen war, sehe ich mich um: Keine Planning Poker Karten, keine Handys (mit Poker-App) am Tisch, nichts… Wie will das Team schätzen? Ich stelle mich also auf eine langwierige Schätzsession mit vielen Diskussionen ein. Ich plane im Geiste schon meine anschließende Intervention, um das Thema relative Schätzung zu motivieren. Plötzlich geht alles ganz schnell. Auf ein Zeichen des Scrum Masters heben alle Teammitglieder eine Hand, die Schätzzahl wird notiert und es geht weiter. Was war passiert? Und wieder einmal habe ich etwas gelernt: es geht immer noch einfacher!

Warum ist es so schwer, ein Scrum-Team zu bilden?

Erstellt am 25 Juni 2013
von 2 Kommentare

Eine typische Organisationsform für System- und Softwareentwicklung sind Komponenten-Teams. Entwickler werden um Komponenten herum gruppiert, es gibt ein Team für Komponente X und eines für Komponente Y; dann gibt es auch oft Spezialteams wie ein GUI-Team oder ein Test-Team.

Eine andere weitverbreitete Organisationsform ist die Einteilung in Silos, Pools oder Services entlang der Disziplinen, also ein Requirements-Service, ein Design-Service, ein Test-Service (das eignet sich für Outsourcing angeblich sehr gut) und die Mitarbeiter dieser Services werden dann Projekten gemäß ihrer „Spezialisierung“ zugeordnet. Jeder Mitarbeiter arbeitet gewöhnlich in mehreren Projekten gleichzeitig.