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
    Dan, ... drags down your velocity.  Agreed ... whole section of code; the team might not know that. Doing a lot of ... I don t know about buy-in , because
    Message 1 of 107 , Feb 25, 2013
      Dan,

      > you have technical debt (interest payments) that
      drags down your velocity.
       Agreed

      > The PO might plan to ditch that whole section of code; the team might not know that. Doing a lot of
      > work
      for automated regression testing would then be waste.
      I don't know about "buy-in", because they sounds like "approval".  But, as I stated before, if the Dev Team makes their work completely transparent, then the PO will have several chances to weigh in on the value of the Dev Team's work, even if they cannot control 100% of it.

      > If you can't have a conversation about how some planned work contributes to dollars, or at
      > least helps achieve
      the company mission, you have a problem.

      Agreed, though I also agree that it's difficult to create a NPV.  But, I'm not sure it's that much more difficult then creating/attempting a NPV for normal PO features, either.  My view on the PO side is that we should *at least* attempt to estimate NPV/ROI for features, then iterate on those estimation efforts to get better at forecasting value (sort of the "Lean Startup" type strategy for validations).  So, maybe that's what my view should also be for technical debt resolution or improvement efforts. 
       
      -------
      Charles Bradley
      Scrum Coach-in-Chief
      ScrumCrazy.com




      From: Dan Greening <dan@...>
      To: scrumdevelopment@yahoogroups.com
      Sent: Monday, February 25, 2013 5:43 PM
      Subject: Re: [scrumdevelopment] Request for reference/reading material - Developer Stories



      Hi Charles and Ron,

      Here's how I view it. If you are doing work to reduce technical debt it HAS to have an ROI. If you are not working on a piece of code, but your team spends a lot of time doing manual regression testing every sprint, it is paying the interest on that long-ago borrowed principal (when you wrote feature code without automating tests), you have technical debt (interest payments) that drags down your velocity.

      I think we all agree on this topic, because we probably also agree that if you plan to work on automating regression testing, you should get the Product Owner's buy-in.  Here's why: The PO might plan to ditch that whole section of code; the team might not know that. Doing a lot of work for automated regression testing would then be waste.

      I'm a big fan of everyone attempting (not necessarily achieving) to put a "net present value" on anything they plan to do. The attempt brings home that you have to be thinking about value, whether branding value, user happiness value, increased monetization, or reduced effort for future features (i.e. technical debt repayment).  If you can't have a conversation about how some planned work contributes to dollars, or at least helps achieve the company mission, you have a problem.

      Dan Greening
      Managing Director, Senex Rex LLC, http://senexrex.com
      Email: dan@... Phone: +1 (415) 754-8311, Skypeid: drgreening

      On Mon, Feb 25, 2013 at 4:26 PM, Ron Jeffries <ronjeffries@...> wrote:
       
      Hi Charles,

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

      I think some of this comes down to a disagreement between you and I on whether the PO gets to control all work being done by the Dev Team or not.   My view is that the self organizing dev team can choose how much PB to take on, and what they do with the rest of their time in the sprint is completely up to them -- so long as they are completely transparent about what they are spending their time on, and as such, can be held accountable for their actions. 

      If the PO is not controlling all their time, there will be trust issues. In addition, it is rare -- tho perhaps not unheard of -- for teams to really need to back off much on the features in order to clean the code. Cleaning code in areas we're not putting features in is speculative and therefore inherently a bad idea. Cleaning code in feature areas is just what we do.

      That said, if the team decides to back off on its support of features -- which I do not recommend -- then that work, by the nature of the assumption, is not product backlog items.

      Ron Jeffries
      I try to Zen through it and keep my voice very mellow and low.
      Inside I am screaming and have a machine gun.
      Yin and Yang I figure.
        -- Tom Jeffries






    • 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, 2013
        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.