Short news on Twitter

    Follow us on Twitter
    Posts mit dem Label Rollen in Scrum werden angezeigt. Alle Posts anzeigen
    Posts mit dem Label Rollen in Scrum werden angezeigt. Alle Posts anzeigen

    Dienstag, 25. November 2008

    Cross Functional Teams in Scrum

    Viele Projekte verwenden die weit verbreitete drei Schichten-Architektur. Oft sind in diesen Projekten je ein Entwickler für je eine Schicht zuständig . Doch solche nicht “cross-functional” Teams haben einige Nachteile:

    In Scrum Teams sollten alle Teammitglieder in der Lage sein, an beliebigen Anforderungen des Product Backlogs zu arbeiten. Was passiert, wenn das Teams nicht können, habe ich erlebt:

    • Eine Umverteilung von Arbeit ist nicht möglich, da diese konkret an Personen gekoppelt ist
    • Komplette Sprints können (im Sinne des Business Value) ergebnislos bleiben, wenn ein Teammitglied ausfällt, da es eine vollständige Schicht betreut. Somit kann nahezu keine Anforderung umgesetzt werden
    • Es entsteht manchmal ein schwächeres Team Commitment, da die Teammitglieder selbst den Fortschritt nur wenig beeinflussen können, auf Grund der nicht möglichen Umverteilung von Arbeit.

    Tja, wie sieht die Wirklichkeit an diesem Punkt aus? Gibt es Entwickler, welche alle schichtrelevanten Technologien beherrschen? Ist das Utopie?

    Ich glaube, das hängt vom Kontext des Projekts ab. Projekte haben unterschiedliche technologische Tiefen. Abhängig von diesen Tiefen ist das notwendige Wissen, um sinnvolle und qualitativ hochwertige Änderungen zu machen.  Wenn die Spannbreite über alle Technolgiebestandteile sehr hoch ist, mag dieses Vorgehen nicht möglich sein. In größeren Teams können Entwickler aus gleichen Schichten Fluktuationen besser abfangen.

    Cross-functional Teams bleiben weiter ein Diskussionspunkt. So habe ich sie auch bisher wahrgenommen.

    Montag, 10. November 2008

    Zuständigkeit für Sprint Backlog Items

    Was passiert eigentlich, wenn eine Person Sprint Backlog Items für alle anderen Teammitglieder im Vorfeld anlegt, um eine Planungssitzung zu verkürzen?

    Die Erfahrung, die ich gemacht habe: In der Planungssitzung herrschte nur geringe Beteiligung des Teams. Jeder akzeptierte die Sprint Items, welche auf sehr hohem Niveau erstellt waren ("Erstellen der GUI"), da dem Ersteller kein weiteres Detailwissen vorlag. Während des Sprints entstanden Unklarheiten, wer jetzt was zu bearbeiten hat, was dieser oder jener Task überhaupt bedeutet. Des Weiteren fehlten viele Sprint Backlog Items. Andere blieben unangefasst.

    Kurzum: Wenn die Teammitglieder nicht selbst die Tasks anlegen, identifizieren sie sich nicht mit den Aufgaben und verstehen diese nicht zwangsläufig. Finger weg von "Vorgaben von oben" bei einem Scrumprojekt.

    Mittwoch, 15. Oktober 2008

    Werte eines ScrumMasters

    Ein interessanter Beitrag zur Rolle des ScrumMasters im Unternehmen, hat Jean-Pierre geschrieben. Ein Absprung dorthin lohnt sich, für den, der sein Verständnis oder die Ausfüllung der Rolle erweitern und nochmal prüfen möchte.

    Contact us

    XING XING