RSS Feed

Posts Tagged ‘Scrum’

  1. Definition of Done (DoD)

    August 9, 2012 by Tino Seeber

    Oder:

    Wie und warum wir in SCRUM Qualitätsstandards definieren



    Soll eine Story oder ein Tasks als „done“ bezeichnet werden, müssen alle das gleiche Verständnis darüber haben, was „done“ bedeutet. Obschon es hierbei signifikante Abweichungen zwischen verschiedenen Scrum Teams gibt, müssen die Mitglieder eines Teams zur Gewährleistung der Transparenz ein gemeinsames Verständnis haben was es bedeutet, wenn eine Arbeit abgeschlossen ist. Dafür sorgt die „Definition of Done“.

    Die Definition of Done (DoD) ist eine Checkliste von Aktivitäten, die zur Implementierung einer User Story gehören und die Qualität der Software beeinflussen. Dazu gehört beispielsweise das Schreiben von Kommentaren, Unit Tests und Design-Dokumenten. Die DoD wird von den Beteiligten zu Beginn eines Projektes festgelegt, kann aber im Laufe der Entwicklung angepasst werden. Die DoD hilft zu Beginn eines Sprints, die Anzahl und den Umfang der Tasks festzulegen. Am Ende des Sprints dient die DoD neben den detaillierten Anforderungen für eine spezifische User Story dazu, zu entscheiden, ob eine User Story als done akzeptiert wird.

    –> DoD = Qualitätsstandards

    Daraus folgt:

    Eine Story (Task) ist nicht “done” bis sie die definierten Qualitätsstandards erfüllt. – Seeber, 2012


    1. Entwicklung einer DoD anhand des Sprint-Ziels “shippable product”


    Frage: What is a potentially shippable product?

    “A shippable product is one that has been designed, developed and tested and is therefore ready for distribution to anyone in the company for review or even to any external stakeholder.” – Dhaval Panchal, 2011

    Die DoD ist immer ein elementarer Bestandteil eines Vertrages zwischen ProductOwner (oder dem Kunden) und dem Team und regelt den Lieferumfang für jede Einzelbeauftragung durch Stories in jedem Sprint sowie für das Gesamtprodukt.

    –> Team und PO entwickeln gemeinsam die Qualitätsstandards (DoD)


    2. Die DoD ist nicht statisch


    Eine DoD ist nicht in Stein gemeißelt und kann sich über die Dauer eines Projektes verändern:

    Preparing a single definition of done that suits every situation is impossible. Each team should collaborate and come up with the definition that suits its unique environment.

    Organisationen bzw. Teams finden es oftmals schwierig zu Beginn einer agilen Vorgehensweise eine fertige DoD zu erstellen – daher ist sollte man step by step vorgehen um die eigene DoD stetig anzupassen und zu verbessern. Feedback aus dem Retrospektive Meeting kann hier helfen die DoD weiterzuentwickeln.

    –> Wichtig: Falls Anpassung/ Weiterentwicklung der DoD, dann nur VOR Beginn eines neuen Sprints und in Absprache zwischen Team & PO


    3. Beispiele für DoDs


    a) Sehr einfach:
     Code Complete
     Test Complete
     Approved by Product Owner

    b) Komplexer:
     Code Complete
     Unit tests written and executed
     Integration tested
     Code reviewed
     Performance tested
     Documented (just enough)

    c) Noch komplexer:
     Der Code erfüllt die Code-Konventionen und ist sauber geschrieben (Refaktoriert, aussagekräftige Namen, keine Duplizierung, inline Kommentare und Code-Dokumentation)
     Alles (Buttons, Hilfe, Tooltips, Fehlermeldungen, …) ist in deutsch und englisch
     Es gibt für alle nichtrivialen Klassen Unit Tests, die fehlerfrei durchlaufen.
     Der Code + Unit-Test sind eingecheckt.
     Der Code wurde auf dem Integrationserver getestet.
     Die Hilfe ist erstellt.

    Tipp: Keep it Simple (as possible) – keiner möchte unzählige Checklisten durchgehen.

    Fragen? Best Practices?



    simyo - Prepaid und Postpaid Handytarife




    Follow me on Twitter, Facebook, Xing or Linkedin.


  2. ScrumMaster Skills.

    August 4, 2012 by Tino Seeber

    My current Client is looking for a ScrumMaster – so the question popped up, what Skills should the ideal ScrumMaster have?

    The ideal SrumMaster needs tha ability:

    … to lead a Team.
    … to communicate.s
    … to manage Processes.
    … to think outside of the box.
    … to make decisions.
    … to think analytically and creatively.
    … to be persuasive.

    The most important Skills for a ScrumMaster are:

    1. Servant Leader – Must be able to garner respect from his Team.

    2. Communicative and social – Must be able to communicate well with people.

    3. Persistent and Assertive – Must be able to ensure AScrum concepts and principles are applied correctly and make sure team understands these values [especially important for new teams].

    4. Learning and Continues Improvement – Must continually be learning new tools and techniques to manage oneself and a team. Apply new practices in daily work.

    5. Conflict Resolution – Must be able to facilitate discussion and facilitate alternatives or different approaches

    6. No command and Control Attitude – Must strive to make a team self-organized.

    7. Transparent – Must be seeking for open and honest atmosphere in a team and in a company.




    Follow me on Twitter, Facebook, Xing or Linkedin.


  3. Neue BMW Webseite – State of the Art.

    Februar 25, 2012 by Tino Seeber

    Na endlich!

    Nach mehr als 1 Jahr Arbeit ist sie fertig – die neue BMW Webseite. Zunächst für den Markt in Österreich wird sie demnächst weltweit “gelauncht”.

    Zusammen mit Boris Gloger habe bei BMW Scrum eingeführt und zu Beginn des Projektes die beiden Team Content & Communication übernommen. Schön zu sehen, dass Kleinigkeiten woran das Team sich tagelang den Kopf zerbrochen hat, nun reibungslos funktionieren. In dieser Zeit habe ich viel gelernt und ich hoffe, das Team auch das ein oder andere von mir.

    In jedem Fall bin ich sehr stolz, dass ein so klasse Produkt dabei herausgekommen ist – das derzeit der automobile Benchmark in Europa ist.

    BMW ist zudem die beste deutsche Marke im globalen Social Media Ranking.




    Become a Fan of IK:MIT!
    Follow me on Twitter, Facebook, Xing or Linkedin.


  4. New Scrum Guide 2011 – a lot of Changes.

    August 9, 2011 by Tino Seeber

    The New Scrum Guide 2011 is released by Ken Schwaber and Jeff Sutherland. A lot of Changes are made – details will follow a soon as I have read the whole story.

    Download the Newest Scrum Guide – 2011.


  5. Jeff Sutherland coaches Google

    Oktober 15, 2010 by Tino Seeber

    Or: Self-Organization – The Secret Sauce for Improving your Scrum team

    Jeff Sutherland at Google’s Headquarters teaching Google Developers in Scrum


  6. How to increase Productivity in a Scrum Team.

    Oktober 10, 2010 by Tino Seeber

    Increasing the productivity of a Scrum Team is one of the Scrum Master’s top aims.

    Here the facts you should consider for increasing a Scrum Team’s productivity:

    - Communicate

    - Work as a Team

    - Work in 2-weeks sprints

    - Use small user stories that can be completed in a day or two

    - Work on a small number of stories at once

    - Product Owner has to write clear user stories and acceptance tests

    - Scrum Master has to identify and solve impediments

    - Use a strong and clear Level of Done

    - Individuals may (should!) cross disciplines to get things done without unpredictable wait times

    - Make achievable commitments based on past results


  7. Scrum Master Checklist

    Oktober 8, 2010 by Tino Seeber

    Four Pages helping a Scrum Master succeed:

    Download Scrum Master Checklist (PDF) – english (by Michael James)

    Download Scrum Master Checklist (PDF) – german (translated by The Codovation Blog)


  8. Presentation: Why Scrum Works.

    Oktober 7, 2010 by Tino Seeber


  9. I like: Scrum2Go.

    September 26, 2010 by Tino Seeber

    Doing Scrum and looking for an App that will support you?

    Scrum2Go is a simple focused App for iPhone and iPod Touch, that covers all everyday activities in Scrum life cycle. With team velocity tracking and impediments notifyer.


  10. The Marshmallow Challenge.

    September 20, 2010 by Tino Seeber

    Or: Build a Tower, build a Team.

    It’s a team exercise in which the participants have to build a tower using a supply of (dry) spaghetti, tape, string and marshmallow. The goal is build the highest structure possible within 18 minutes.

    It turns out that recent Kindergarten grads do better than the average adults. And MBA’s do worse than average adults. But why is that?

    The Kids work iterative (like Scrum) and get instant feedback on what they do. They start working on the problem immediately, make several attempts to solve the problem – they iterate. The adults tended to look for the “single right plan” (watererfall) and tended to think about the marshmallow late in the process. They often produced only one actual prototype, just before the deadline – usually to watch it fall down shortly after the marshmallow is attached.