50233RE: [scrumdevelopment] Re: Break from sprinting - a strategy sprint
- Feb 2, 2011I have tried to make a contribution to this group, and I do hope that I have had some success.
But I am now a little tired of the snipes and barbs that my offerings seem to elicit.
So, I have decided to retire from the field and cease to participate in this group. This may be interpreted as me throwing a hissy fit, or taking my bat and ball and going home, or whatever other motive you may ascribe ... but it doesn't matter.
Ron's latest barb about finding employment in the food industry was just a little too bitchy for me.
So, as the saying is "he was a good cook, as good cooks go, and as good cooks go, he went".
I have attached a couple of files to this final email, for the information of anyone who is interested ... one is a summary set of slides of my various publications and presentations, the other is the full paper I published about adopting agile methods in student projects. Read them if you will, ignore them if you have found my writing to be tedious and only worthy of someone who should be employed at MacDonalds (where, I must say, I have often found friendly, efficient service, so I really don't mean any insult to those good folk).
> To: email@example.com
> From: ronjeffries@...
> Date: Wed, 2 Feb 2011 19:09:12 -0500
> Subject: Re: [scrumdevelopment] Re: Break from sprinting - a strategy sprint
> Hello, Roy. On Wednesday, February 2, 2011, at 6:34:41 PM, you
> > I have always had the impression that trying to 'update' a legacy
> > system, in the way that I think you are indicating, can turn into
> > a quick sand swamp of frustration and fire fighting (excuse the mixed metaphors).
> > I honestly think that it is usually better to use the legacy
> > system as a 'prototype' for the new system, and, instead of trying
> > to patch the old system, you develop a new system in parallel.
> > At least, this is the theory of the thing, and is probably a
> > difficult game to sell. But I have really had a lot of experience
> > seeing people trying to 'fix it' when, if they scratched the old
> > and developed the new, with the same intention that the old was
> > developed for, it would save a lot of time.
> Have you ever been engaged in a project to rewrite a legacy system?
> I'd like to hear about the results: your blase presentation of this
> idea tells me that if you've done it, you must know some secrets
> that I do not.
> I have been involved in several conversions, and I would prefer
> never to do it again, even with an Agile approach (but more about
> what I'd do if I had to below). What happens is:
> 0. All the following criteria are absolute and highest priority.
> 1. We need all the functionality of the old system.
> 2. It has to be completely compatible with the old system.
> 3. All the bugs have to be fixed.
> 4. There are some bugs which, if fixed, would break compatibility.
> 5. We have many new features that are absolutely critical.
> 6. It has to be much easier to use and better looking, while
> remaining completely compatible.
> 7. Conversion from the old system has to be trivially easy,
> absolutely seamless, and perfect.
> 8. The situation is time critical. We are already late.
> 9. We will be adding a few new important features to the
> old system. We're sure that you won't have any trouble adding
> them to yours. Be sure to watch version reports to find out
> what they are.
> After that, it starts to get really ugly. Every project of this kind
> that I've been involved in turned into a death march where most of
> us would have preferred actual death. Except for one: The Chrysler
> C3 project. It went really well except for being scrapped at the end
> despite that it was working fine.
> Now then. What would I do, faced with this opportunity?
> One possibility: Refactor the old system into a better system. This
> is not easy, as it requires great refactoring skill. However, if you
> do not have great refactoring skill, where do you get off telling us
> you are qualified to rewrite this giant steaming pile to make it
> Another possibility: Strangle the old app. Implement new
> functionality in a clean way, and eviscerate the old system one bit
> of functionality at a time, calling out to the new. This might
> continue forever; it might be that we'd call it good enough and
> stop; it might be that we would use the momentum of the new stuff
> working to continue forward.
> Yet another possibility: Build a new system as if we were one of our
> competitors. The new system is intended to be so good and so full of
> new capability that it wipes out the market for the old one, without
> ever needing to match it feces for feces.
> Absent any of those possibilities, I'd consider finding gainful
> employment in food services.
> Ron Jeffries
> It is a bad plan that admits of no modifications. -- Publius Syrus (ca. 42 BCE)
> To Post a message, send it to: scrumdevelopment@...
> To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
> <*> To visit your group on the web, go to:
> <*> Your email settings:
> Individual Email | Traditional
> <*> To change settings online go to:
> (Yahoo! ID required)
> <*> To change settings via email:
> <*> To unsubscribe from this group, send an email to:
> <*> Your use of Yahoo! Groups is subject to:
- << Previous post in topic Next post in topic >>