• Home
  • About
  • What Type of “Done” are You?

    What Type of “Done” are You?
    What Type of “Done” are You? This is certainly one of the central questions of Scrum. Does it involve testing, integration testing, user acceptance, documentation, or all of these?
    It is up to you – as a company – to define what Done means.
    A “done” task at the end of a sprint means it is a fully working and shippable increment of the product, and it is an increment you want to built upon in your subsequent work. The size of the task “done” does not matter much, it can be small as long as it is “done”, according to the definition. So better do it well or it will show up again later in your backlog and retrospectives …
    Questions like these – all focused on the core aspects of the Scrum methodology – were discussed at the ScrumMaster certificate workshop at the Entwicklertage Karlsruhe [http://www.andrena.de/Entwicklertag/2010/], 21.-22.6. One of the godfathers of Scrum, Ken Schwaber, was performing this workshop with around 30 people in the Schlosshotel Karlsruhe. Canoo was contributing well, providing 10% of the participants. The workshop was a lot of fun, full of exercises, jokes, anecdotes and insights.
    Scrum is an empirical process and therefore requires some experience. Reading a book about it gives you an idea, but you have to practice and live it.
    What do you think, does a Scrum Master have to be at the daily scrum meeting? That was an interesting question to discuss. On one hand, the ScrumMaster is directly accountable for the Scrum process by definition. Therefore he had better attend the meeting and help remove impediments. On the other hand, the purpose of the meeting is not to report to the Scrum Master. It is for the team to get an understanding where they are and what is going well or not.
    Is it correct if management attends a Spring review meeting and applauds you for your success? What should you do if the product owner reshuffles the whole product backlog against your better knowledge? Given 20 Mio. Dollars to expand your company, how would you scale your initial team of 7 to 70? How do you write an offer based on the Scrum approach to a fixed business request?
    Scrum is based on transparency and commitment, it establishes local predictability in highly complex and globally uncontrollable projects. It makes risks and defects highly visible. Its time to get rid of the “feature finish metronome” in our heads.
    Some of the most important aspects we learned from the training were:
    - deliver a shippable increment within each sprint, otherwise you have nothing to build upon
    - select no more work then you can finish properly
    - work on one thing at a time
    - product owner must learn to demand less. Take it as an opportunity to focus on value not quantity
    - when under pressure, drop low value items not quality
    - people are able to form and manage their teams on their own
    At one point, Ken made an interesting historical note about the early days of Scrum: It’s not that the world was missing the truth with respect to development. But what made Scrum possible was a change in development environments towards integrateable and automatically testable systems, a feature that first arose back in the days of smalltalk projects. Lucky for us, we were born too late…
    Ken Schwabers concluded with the words: “I think we have one of the best profession one can imagine; do your best to transform it back into  something enjoyable!”
    Thanks Ken

    What Type of “Done” are You? This is certainly one of the central questions of Scrum. Does it involve testing, integration testing, user acceptance, documentation, or all of these?

    It is up to you – as a company – to define what Done means.

    A “done” task at the end of a sprint means it is a fully working and shippable increment of the product, and it is an increment you want to built upon in your subsequent work. The size of the task “done” does not matter much, it can be small as long as it is “done”, according to the definition. So better do it well or it will show up again later in your backlog and retrospectives …

    Questions like these – all focused on the core aspects of the Scrum methodology – were discussed at the ScrumMaster certificate workshop at the Entwicklertage Karlsruhe, 21.-22.6. One of the godfathers of Scrum, Ken Schwaber, was performing this workshop with around 30 people in the Schlosshotel Karlsruhe. Canoo was contributing well, providing 10% of the participants. The workshop was a lot of fun, full of exercises, jokes, anecdotes and insights.

    Scrum is an empirical process and therefore requires some experience. Reading a book about it gives you an idea, but you have to practice and live it.

    What do you think, does a Scrum Master have to be at the daily scrum meeting? That was an interesting question to discuss. On one hand, the ScrumMaster is directly accountable for the Scrum process by definition. Therefore he had better attend the meeting and help remove impediments. On the other hand, the purpose of the meeting is not to report to the Scrum Master. It is for the team to get an understanding where they are and what is going well or not.

    Is it correct if management attends a Spring review meeting and applauds you for your success? What should you do if the product owner reshuffles the whole product backlog against your better knowledge? Given 20 Mio. Dollars to expand your company, how would you scale your initial team of 7 to 70? How do you write an offer based on the Scrum approach to a fixed business request?

    Scrum is based on transparency and commitment, it establishes local predictability in highly complex and globally uncontrollable projects. It makes risks and defects highly visible. Its time to get rid of the “feature finish metronome” in our heads.

    Some of the most important aspects we learned from the training were:

    • deliver a shippable increment within each sprint, otherwise you have nothing to build upon
    • select no more work then you can finish properly
    • work on one thing at a time
    • product owner must learn to demand less. Take it as an opportunity to focus on value not quantity
    • when under pressure, drop low value items not quality
    • people are able to form and manage their teams on their own

    At one point, Ken made an interesting historical note about the early days of Scrum: It’s not that the world was missing the truth with respect to development. But what made Scrum possible was a change in development environments towards integrateable and automatically testable systems, a feature that first arose back in the days of smalltalk projects. Lucky for us, we were born too late…

    Ken Schwabers concluded with the words

    I think we have one of the best profession one can imagine; do your best to transform it back into something enjoyable!

    Thanks Ken

    canoo meets ken

    Canoo meets Ken

    Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
    • Y!GG
    • Webnews
    • Digg
    • del.icio.us
    • DotNetKicks
    • Facebook
    • Google Bookmarks
    • Newsrider
    • Newstube
    • TwitThis
    • YahooBuzz

    Leave a Comment

    This is a captcha-picture. It is used to prevent mass-access by robots. (see: www.captcha.net)

    You must read and type the 5 chars within 0..9 and A..F, and submit the form.

      

    Oh no, I cannot read this. Please, generate a