Loading ...
Sorry, an error occurred while loading the content.

RE: Commitment to Definition of Done

Expand Messages
  • m.babrawala@yahoo.com
    ... From: Charles Bradley - Scrum Coach CSM PSM I Sent: 13/07/2011, 10:21 PM To: scrumdevelopment@yahoogroups.com Subject: Re: [scrumdevelopment] Re:
    Message 1 of 43 , Jul 13, 2011
    • 0 Attachment
      -----Original Message-----
      From: Charles Bradley - Scrum Coach CSM PSM I
      Sent: 13/07/2011, 10:21 PM
      To: scrumdevelopment@yahoogroups.com
      Subject: Re: [scrumdevelopment] Re: Commitment to Definition of Done


      Good points Jeff.  This concept of progressively moving towards a great DoD is covered in the last two pages of the Scrum Guide.  OTOH, I've never really liked the way those last couple of pages is written -- it's confusing, and the process it describes is kind of a difficult solution for some teams to grasp.

       
      -------
      Charles Bradley, CSM, PSM I
      Experienced Scrum Coach
      My blog: http://scrumcrazy.wordpress.com/


      >________________________________
      >From: Jeff Anderson <Thomasjeffreyandersontwin@...>
      >To: "scrumdevelopment@yahoogroups.com" <scrumdevelopment@yahoogroups.com>
      >Sent: Wednesday, July 13, 2011 8:36 AM
      >Subject: Re: [scrumdevelopment] Re: Commitment to Definition of Done
      >
      >
      >
      >
      >
      >Avi,
      >
      >
      >Great advice.
      >
      >
      >It points to a VERY important point. Don't your treat your original DOD as sacrosanct. Remove some of these if the team isn't ready for it. Be transparent about impact, but it's important to have the team have a DoD that they feel they can accomplish. Many beginner teams really struggle with TDD and CI plus the work. 
      >
      >
      >Get them there incrementally, but get them into the habit of meeting or striving to meet what they do leave in the DOD. 
      >
      >
      >
      >
      >Jeff Anderson
      >
      >agileconsulting.blogspot.com
      >http://twitter.com/thomasjeffrey
      >
      >
      >
      >On 2011-07-13, at 4:41 AM, avi_a@... wrote:
      >
      >

      >>+1 on celebrating the positive team commitment.
      >>Now it's your duty as SM to steer that commitment in a positive direction.
      >>
      >>Remind the team that the DOD is their contract with the PO.
      >>Check with the team the items that they choose to remove - if they truly think those items are redundant, make it official and remove them from the DOD. Make sure this is coordinated with the PO and that the team fully understands the impact - for instance, what impact will not doing unit test have in the long run. On the other hand, remind them of the positive reasons they included that line in the DOD in the first place - was it to ensure there are on bugs? whas it to reduce headaches later on? was it to improve their skills? once they remember the reasons, they might not be so quick to give up on it.
      >>
      >>If they still think that they should do unit tests, check with them and with the PO why they don't have enough time to do them during the sprint. If the PO also understands the need for unit tests, he/she should be willing to remove some stories form the sprint in favor of having the remaining stories "truly done".
      >>
      >>But in the end remember that it's the team's responsibility to define the way they work best - within themselves and in coordination with the PO. Don't try and push them into doing something that doesn't fit them and that the PO doesn't want.
      >>
      >>BTW something that I find helps - during the sprint planning, when making the list of tasks, remember to refer to the DOD as a reminder of "what does our DOD tell us that we need to include in the taskboard?"
      >>For instance - if the DOD has "all code is unit tested" in it, this means the team needs to include a task saying "write unit tests".
      >>
      >>Once all the tasks are written down, have the team estimate the tasks (including the unit-testing task), and before committing to the sprint check with them if the total number of task-hours exceeds their capacity for the sprint.
      >>
      >>This helps the team identify capacity problems early, and adjust their sprint commitment accordingly before the sprint starts. If they find that the total task hours is too much they should negotiate with the PO removing a story.
      >>
      >>HTH
      >>Avi
      >>
      >>--- In scrumdevelopment@yahoogroups.com, "Dennis van der Stelt" <dvdstelt@...> wrote:
      >>>
      >>> Hi there,
      >>>
      >>> I'm at a small company where we're heavily investing into Scrum and I've got great commitment from management so far.
      >>>
      >>> The problem however is that a team on a new project specified their own "Definition of Done" (I had no input as SM in it) but they don't commit to it. Because they knew that, because of multiple reasons, they probably wouldn't make the sprint, the did two things
      >>>
      >>> - Started crunching some extra hours. That's good, because it shows commitment.
      >>> - Dropped almost all things from the definition of done, specifically unit tests, have their functionality initially tested by a fellow developer and have their code reviewed.
      >>>
      >>> Everyone was happy because work got delivered, but my feeling nothing has changed, because we already did this 4 years ago. Back then we also dropped unit tests the moment we felt pressure (which was ALWAYS, so we have virtually no unit tests) and we pay heavily on quality. Every single person knows that in months or years, we'll pay the price for not doing all this.
      >>>
      >>> How should I react? How can I make the team committed to their Definition of Done?
      >>>
      >>> Thanks in advance! :)
      >>>
      >>
      >>
      >
      >
      >
      >
      >
    • Geetha Anand
      HI Could some one mention about the contents of the DOD as mentioned in scrum Guide - last 2 pages? thanks regards Gee
      Message 43 of 43 , Sep 12, 2011
      • 0 Attachment

        HI
         
        Could some one  mention about the contents of the DOD as mentioned in scrum Guide - last 2 pages?
         
        thanks
        regards
         
        Gee

         
        On Tue, Jul 12, 2011 at 3:09 AM, Laurent Bossavit <lolists@...> wrote:
         

        Hi Dennis,


        > - Dropped almost all things from the definition of done,
        > specifically unit tests, have their functionality initially tested
        > by a fellow developer and have their code reviewed.
        >

        "Definition of Done" is a hypothesis. Once something is Done, you
        shouldn't ever have to go back to "fix" it.

        The first time this happens falsifies the hypothesis.

        So, in your case, the first time someone "in the user's shoes" finds a
        bug that could have been caught by a unit test, the DoD is falsified.
        (This could be you. Everyone has is entitled to go poking at the app
        looking for bugs.)

        At that point the rules of the game *require* that the Team do
        something about it. Not suggest, not encourage: *require*.

        As in, if you don't do something about it, you have your head
        officially and publicly in the sand.

        The rules of the game do not specify *what* you have to do about it.
        If someone on the Team has a hypothesis that drawing a pentagram
        around their desk and lighting a candle at each point before coding
        will prevent bugs, and their reasoning carries with the Team, we're
        allowed to have a go at testing that.

        The imperative, though, is that reality wins over speculation, each
        and every time.

        Does that help?

        Cheers,
        Laurent


      Your message has been successfully submitted and would be delivered to recipients shortly.