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

Re: [scrumdevelopment] Request for reference/reading material - Developer Stories

Expand Messages
  • Charles Bradley - Professional Scrum Trai
    I think it s worth mentioning, FWIW, that in our Scrum.org PSM Class, we teach this approach to technical debt: 1. Stop creating debt 2. Make a small payment
    Message 1 of 107 , Feb 26, 2013
    • 0 Attachment
      I think it's worth mentioning, FWIW, that in our Scrum.org PSM Class, we teach this approach to technical debt:

      1. Stop creating debt
      2. Make a small payment each Sprint
      3. Repeat from 2

      Again, to be clear, I do not, in any way, endorse "developer stories", "technical stories", or any other similar thing being on the product backlog. 

      My endorsed approaches, in order of my preference, are:
      2.  The above Scrum.org PSM approach (in which case I would suggest representing this work as sprint backlog tasks)
      3.  Ron's "Boy Scout Rule" approach -- only resolve technical debt on code that is currently being touched.  (Note that I recommend using this approach *in addition* to one of with the previous two)

      It's also important to note that I generally do not think "bugs" are technical debt.  More on that topic at the improvement backlog link above.

      -------
      Charles Bradley
      Scrum Coach-in-Chief
      ScrumCrazy.com




      From: Charles Bradley - Professional Scrum Trainer and Coach <chuck-lists2@...>
      To: "scrumdevelopment@yahoogroups.com" <scrumdevelopment@yahoogroups.com>
      Sent: Monday, February 25, 2013 6:33 PM
      Subject: Re: [scrumdevelopment] Request for reference/reading material - Developer Stories



      100% Understand and respect that, Ron.  Giving advice over the interwebs needs to be safe advice.

      Thanks again, for your time, and for your valuable and ongoing contributions to our community.
       
      -------
      Charles Bradley
      Scrum Coach-in-Chief
      ScrumCrazy.com




      From: Ron Jeffries <ronjeffries@...>
      To: scrumdevelopment@yahoogroups.com
      Sent: Monday, February 25, 2013 6:06 PM
      Subject: Re: [scrumdevelopment] Request for reference/reading material - Developer Stories



      Hi Charles,

      On Feb 25, 2013, at 7:55 PM, Charles Bradley - Professional Scrum Trainer and Coach <chuck-lists2@...> wrote:

      Interesting that you mention that.  I've kind of found the opposite, and maybe that's because the teams I coach are often Shu level teams, co-located, where the PO is also internal to the org.  As such, the org/dev team is somewhat used to being able to call a "refactorpalooza" whenever they want(and any number of other bad habits).  I've found, on many occasions, that when the Dev Team mentions to the PO that they need to work on technical debt, or technical improvement (experimenting with a new tool, etc)for a small percentage of the sprint -- they are usually like "Ok, no worries."  It's like some sort of respect from the PO-- "I'm not technical, so I trust that you're doing the right thing here -- and I won't make a big deal out of it since it's a small percentage and I know you won't let it torpedo my features.  I'm the 'what' person -- you all are the 'how' people -- so I won't interfere in stuff I have no clue about.".  It's almost as if the PO is *too* trusting, in most of the cases I've observed.  

      Hm sounds like these teams are not working to any deadlines or something. I would favor a team having a sort of Google rule for use of 10% free time or something. That could be used to experiment with tools and so on. 

      I think that allowing time to "work on technical debt" is to bless technical debt as to some degree OK, and since IMO there is never a reason to write bad code, I do not favor being gentle about letting people clean it up. 

      There are many ways to do things. My concern is to set people in a place that is as close to guaranteed to work as possible, and in my opinion, technical stories are not safe in general. As far as refactoring and adding tests, they are prima facie evidence that the team has not been working up to snuff, and I don't see being all casual about that. I think low craftsmanship is a big deal and should not be treated as business as usual.

      A lot of other technical stuff, including checking out many tools, can be done as part of feature work. Where that's possible, I'd prefer that. 

      Once teams build up trust and a way of working that works for them, that's cool. Self-organization and all that. But when I give advice, I like to give safe advice.
      If not now, when? -- Rabbi Hillel









    • A Narasimhan
      Thanks a lot, George. Rgds-AN From: George Dinwiddie Sent: Saturday, April 20, 2013 8:55 PM To: scrumdevelopment@yahoogroups.com Subject: Re:
      Message 107 of 107 , Apr 21 7:50 AM
      • 0 Attachment
        Thanks a lot, George.
        Rgds-AN
         
        Sent: Saturday, April 20, 2013 8:55 PM
        Subject: Re: [scrumdevelopment] CONCERN: over continuing Schisming/Fragmentation of Scrum & Agile
         
         

        AN,

        On 4/20/13 10:16 AM, A Narasimhan wrote:
        >
        >
        > Hi:
        > Recently there was a mail on Agile Scaling by Ron Jeffries which went
        > something
        > like this:
        > ‘Collaboration works in a team but not so much in a building...’ etc.
        > There were several points covered in that mail on scaling. I somehow
        > deleted that mail.
        > Can someone re-send the mail please...You could also send it to my
        > personal mail
        > mailto:an.narasimhan%40yahoo.co.in <mailto:mailto:an.narasimhan%40yahoo.co.in>
        > Rgds-AN

        Every email has a trailer that includes:

        > Visit Your Group
        > <http://groups.yahoo.com/group/scrumdevelopment

        You can go there to search for messages.

        - George

        --
        ----------------------------------------------------------
        * George Dinwiddie * http://blog.gdinwiddie.com
        Software Development http://www.idiacomputing.com
        Consultant and Coach http://www.agilemaryland.org
        ----------------------------------------------------------

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