Like this thread. Definitely agree with Ron and Charles. FWIW: We re having success basically following the rules Charles laid out. My current project is builtMessage 1 of 107 , Feb 28View Source
Like this thread. Definitely agree with Ron and Charles.FWIW: We're having success basically following the rules Charles laid out.My current project is built on legacy code that didn't have much automated tests and was developed with a kind of rapid-prototype mindset. It had a mix of DRY and non-DRY code and we discovered some basic design issues that worked well for short term success but were not aligned with the project's long term goals. It also had too many Maven POMs resulting in some dependencies that were hard to work with. All this had been done in good faith by good developers who were under pressure to deliver user stories in short time.It took us a while to figure all this out. We started out using a standard scrum task board with user stories. After a few (3-week) sprints we realized we too were missing the target. We'd get new features but not be aligned with long term goals. And it was getting harder and harder. As a whole-team, we decided to (1) change how we interpreted the user stories, and (2) add a swim-lane for technical debt (I like Charles' "IBI" name better, may change that). The board makes it very clear how much current effort is going toward debt-reduction and how much is going toward features. The PO is continually aware and, of course, can redirect us at any time to fit his risk & delivery needs. We work to keep the balance and the intention is to pay down until we don't need the technical debt swim-lane. This is working pretty well, but we haven't got to our goal of no swim-lane yet. I must add, though, none of it would be possible if it weren't for good open communication between all the team members.Another goal of ours, of course, is to stop creating debt. This goal is key, but also hard to implement. There are so many opinions about what makes quality crafted code, how tests should be done, etc. I tend to be a real stickler for what I find works and have caused people to miss estimates by vetoing code reviews and making them start over (what? you wrote the test afterward? I don't want to maintain that! …). But I know I'm not perfect and I also know that others don't know the same rules and or don't feel comfortable vetoing. In this imperfect world, stuff gets built and it's not uniform and there's always the chance of over-testing areas that don't break and getting the wrong abstraction for some bit of reuse, etc. Stuff happens. The frustration of that is a big part of what makes me strive to be better, to see the picture as holistically as I can. It's a journey.,chrisOn Feb 26, 2013, at 11:38 AM, Charles Bradley - Professional Scrum Trainer and Coach <chuck-lists2@...> wrote:I think it's worth mentioning, FWIW, that in our Scrum.org PSM Class, we teach this approach to technical debt:
1. Stop creating debt
2. Make a small payment each Sprint
3. Repeat from 2Again, to be clear, I do not, in any way, endorse "developer stories", "technical stories", or any other similar thing being on the product backlog.My endorsed approaches, in order of my preference, are:2. The above Scrum.org PSM approach (in which case I would suggest representing this work as sprint backlog tasks)3. Ron's "Boy Scout Rule" approach -- only resolve technical debt on code that is currently being touched. (Note that I recommend using this approach *in addition* to one of with the previous two)It's also important to note that I generally do not think "bugs" are technical debt. More on that topic at the improvement backlog link above.-------
From: Charles Bradley - Professional Scrum Trainer and Coach <chuck-lists2@...>
To: "email@example.com" <firstname.lastname@example.org>
Sent: Monday, February 25, 2013 6:33 PM
Subject: Re: [scrumdevelopment] Request for reference/reading material - Developer Stories100% 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 From: George Dinwiddie Sent: Saturday, April 20, 2013 8:55 PM To: email@example.com Subject: Re:Message 107 of 107 , Apr 21View SourceThanks 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