Re: [scrumdevelopment] What would be an appropriate agile approach to building a version 2.0?
- 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.
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