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.-------
From: Ron Jeffries <ronjeffries@...>
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.
- 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