Re: [scrumdevelopment] Request for reference/reading material - Developer Stories
Regarding this article ,
It would appear that your advice is somewhat contradictory to Mike Cohn's advice here:
In particular, in the first and last phases of the "manual test technical debt cleanup", there is work that may or may not be related to the current functionality/code being developed.
Lee Henson, in his presentation on "Identifying, Managing, and Eliminating Technical Debt", talks about finding the project or product with the least amount of debt, and removing that debt (without any real reference to "current stories", or "current code"). I attended on instance of this talk and he also mentioned the strategy of tackling the test automation debt that has the highest value to the customer first -- but again, with no reference to what is being worked on currently(other than to say -- stop creating the debt in the first place, as you and I and others do).
I'm not saying I like Lee's or Mike's strategies are better than yours, but they appear to be credible strategies that are different than yours in at least the respect of "improve only code you're currently touching for current features".
I'm a huge fan of the "Boy Scout Rule" that you promote, and of creating clean code, "and all that jazz." I'm also a fan of self organizing dev teams and letting them decide "how" they want to create the product increment.
I just wonder if there might be occasions, when a self organizing dev team is trying to do the right thing by adding automated tests(or some other technical debt resolution), when they would need time to do this that might take away a small portion of "PO user stories" time. I'm not advocating that they call this work "user stories" or "technical stories" or things like that, but it would seem that it might be a worthwhile effort. In particular, adding automated tests to a high (customer) value part of the code that is known to be buggy/brittle, completely untested by automation, etc.
I mean, if a team works on high value code, and doesn't do so in a high quality way, then there is a chance that there is a bug that could cost the company hundreds of thousands of dollars. The first problem that they need to solve is to learn how to create high quality code to begin with -- I get that. But once that has been done, and in line with Cohn/Henson strategies, I just wonder if there is room to let a dev team self organize to decide that they need to spend some small percentage of time each sprint to resolve some technical debt (in parts of the code that are high risk and high value), alongside doing new feature work. Perhaps they could uncover this bug that could end up costing the company hundreds of thousands of dollars, not to mention saving time hunting bugs and modifying that code in the future.
I do agree with you that estimating the value of such work is very difficult, but estimating the value of new features is also very difficult, and that doesn't stop PO's from using their gut to make such decisions, either.
I also agree with you that there is a risk of a slippery slope to "refactorpalooza" -- and that's probably not a good strategy either.
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.
Anyway, just thoughts on the subject. I still do not believe in Developer Stories or anything remotely like that. OTOH, I feel like this "improvement" work sometimes might be fruitful -- and if so, we need to find a Scrum friendly way of planning and executing that work. I've documented my thoughts on that here:
From: Ron Jeffries <ronjeffries@...>
Sent: Monday, February 25, 2013 3:37 PM
Subject: Re: [scrumdevelopment] Request for reference/reading material - Developer Stories
Hi Charles,On Feb 25, 2013, at 2:45 PM, Charles Bradley - Professional Scrum Trainer and Coach <chuck-lists2@...> wrote:
You mention that there is a "rarely" a need to do this. Could please elaborate on what those "rare needs" look like? Maybe some examples?I can think of no case where I'd recommend this offhand.
- 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