Loading ...
Sorry, an error occurred while loading the content.

50225RE: [scrumdevelopment] Re: Break from sprinting - a strategy sprint

Expand Messages
  • Roy Morien
    Feb 2, 2011
      Let me know which MacDonalds, Ron.
      > To: scrumdevelopment@yahoogroups.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
      > wrote:
      > > 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
      > better.
      > 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
      > www.XProgramming.com
      > 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:
      > http://groups.yahoo.com/group/scrumdevelopment/
      > <*> Your email settings:
      > Individual Email | Traditional
      > <*> To change settings online go to:
      > http://groups.yahoo.com/group/scrumdevelopment/join
      > (Yahoo! ID required)
      > <*> To change settings via email:
      > scrumdevelopment-digest@yahoogroups.com
      > scrumdevelopment-fullfeatured@yahoogroups.com
      > <*> To unsubscribe from this group, send an email to:
      > scrumdevelopment-unsubscribe@yahoogroups.com
      > <*> Your use of Yahoo! Groups is subject to:
      > http://docs.yahoo.com/info/terms/
    • Show all 19 messages in this topic