Re: [scrumdevelopment] Request for reference/reading material - Developer Stories
drags down your velocity.> you have technical debt (interest payments) that
Agreed> The PO might plan to ditch that whole section of code; the team might not know that. Doing a lot of
> workfor 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 achievethe 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.-------
From: Dan Greening <dan@...>
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 GreeningManaging Director, Senex Rex LLC, http://senexrex.comEmail: dan@... Phone: +1 (415) 754-8311, Skypeid: drgreeningOn Mon, Feb 25, 2013 at 4:26 PM, Ron Jeffries <ronjeffries@...> wrote:Hi Charles,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.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.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.
- Thanks a lot, George.Rgds-AN
On 4/20/13 10:16 AM, A Narasimhan wrote:
> Recently there was a mail on Agile Scaling by Ron Jeffries which went
> 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>
Every email has a trailer that includes:
> Visit Your Group
You can go there to search for messages.
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org