Re: [scrumdevelopment] Request for reference/reading material - Developer Stories
> If the PO is not controlling all their time, there will be trust issues.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.If the software is being developed for an external, paying customer, I could totally see how it might create trust issues if the PO did not control all of the dev team's time.Anyway, thanks for the feedback. This is an area that I just don't feel like, we as a community, have a great answer for -- and maybe that's ok. Your and Bill's articles are certainly a good start.-------
From: Ron Jeffries <ronjeffries@...>
Sent: Monday, February 25, 2013 5:26 PM
Subject: Re: [scrumdevelopment] Request for reference/reading material - Developer Stories
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.
- 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