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

Re: [scrumdevelopment] What would be an appropriate agile approach to building a version 2.0?

Expand Messages
  • Steven Gordon
    My understanding of ASP and .Net is that they interoperate just fine. Why not do the upgrade one component at a time to decrease risk, obtain partial benefits
    Message 1 of 2 , Mar 8, 2007
    • 0 Attachment
      My understanding of ASP and .Net is that they interoperate just fine.

      Why not do the upgrade one component at a time to decrease risk, obtain partial benefits sooner, and be able to demonstrate progress regularly?

      On 08 Mar 2007 13:36:04 -0800, tliikamaa <tliikamaa@...> wrote:

      At our company we're in the process of reiterating our whole system.
      The system is webbased and has "evolved" since 2001 with an average of
      4-5 developers. The application roughly consists of a lot of ASP
      scripts and a database. We've agreed (the whole organisation) that we
      need to take some time to rebuild the system, in parts or completely.
      We are a small business, 20 people in total about half is development.
      This system is our only product and livelihood.

      Our first approach was to build a completely new system from scratch,
      adopting new techniques (.NET, better architecture, different build
      environment and development tools). We've decided to use Scrum
      (instead of our first choice, MSF Agile, the one thing we've done
      right) with myself as the Scrummaster. A different group of people
      will still be working with keeping the existing system up and running.
      Fast
      forward. We've only in the middle of the second sprint but still what
      we see now is a trend in burndown that propably will become slightly
      better but I see no big changes coming. This is the burndown we will
      have, with this team-composition building software using these
      practices. The results are far from acceptable from the companies
      point of view. We will (propably) have to use a couple of years to
      even deliver something close to what we have today without adding any
      value (except better code, how's that for value). One misstake was
      that we wanted to reach "higher quality" but we are now trying to
      build "highest quality".

      So, I've come to the conclusion that building new from scratch isn't a
      feasible alternative, it's more something of a vision. I'm not forcing
      my believes on anyone but asking the team if they see any reasons why
      there would be a major change in burndown even after a few sprints.
      Most people are coming to my own conclusion. I'm planning an sprint
      termination (acctually terminating the whole project).

      Ok, enough ranting. Would a feasible approach in this situation be to
      sit down with the Product Owner, construct a new product backlog
      containing everyting we want to do with the existing system like:
      bugs, features, modules 2.0 and so on? We will propbably never be able
      to reach the same possible quality as rebuilding from scratch and we
      will propably be working on the backlog for a few years BUT we will be
      delivering value from scratch and continue doing it the whole time. Do
      you totaly disagree with me? Am I completely of target when falling
      back to reiterate the old system trying to reach "higher quality"?

      Still with me? Wow, thank you! I would be most thankful for any
      comments about the approach in particular and rebuilding systems in
      general.


    Your message has been successfully submitted and would be delivered to recipients shortly.