In my current project there was a unanimous decision to follow agile methodology. This is the first time we are going Agile so may be we have not followed it strictly. The question I have is about the Agile principle "Incremental Design". We had a release which was scheduled to complete in 1 year time-frame. We divided this major release into four sub releases ( 1 per quarter). We did not spend too much time in the architecture and design phase upfront as we thought of doing it the Agile way (evolving the design as we move along i.e. sub release wise). With this approach what we saw is as the design started changing in subsequent minor releases this kind of impacted the already delivered prior sub releases. Every sub release was integrated and had considerable QA effort involved. This whole effort kind of went into the drain as the design changed in the subsequent sub release and these changes derailed what was already delivered in previous sub releases. We had to kind of rework and redo a lot of stuff. I think we have missed something here.
Could someone post their comments on the above and enlighten about proper approach towards "Incremental Design".
It certainly sounds like you missed or misunderstood something...
Can you tell us more about the impact on the earlier sub releases?
Where did that "considerable QA effort" come from?
Did you practice continuous integration? Automated acceptance and unit testing?
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Did you have iterations within the release cycle? Or were your releases your iterations?
Joined: Oct 23, 2003
Yes we did have continuous integration of our unit tests. This worked very well but that is not my question here.
I am actually trying to understand how people go about incorporating incremental design.
To reiterate we had divided our major release into 4 sub-releases. The design changes of our subsequent sub-releases was impacting the functioning of our prior sub-releases. Due to these design changes in our subsequent releases we had to revisit the previous releases. To answer Eric's question yes we had iterations within the release cycle so we had allocated time for system integration testing as well as QA testing for each sub-release.
Things overall worked well but this was one of the important lesson learned and we would want to gather facts so we can avoid such hurdles in our future projects.
Incremental design evolution always entails the risk of rework.
The whole point is that this risk, which often realizes in some extent, is worth taking because you learn so much about the problem, solution and context along the way.
The significant testing effort you mention is the biggest reason for test automation being so frequent topic of discussion in the context of agile methods. You need automation to make your pace of development sustainable and not get bogged down by the continuously increasing effort needed for regression testing.
I'm still not totally clear on what you did, but it sounds to me like you didn't take continuous integration as far as I you probably "should" have. In my experience, system integration testing should be done at least once a day (for example on a nightly build), on the fully integrated system - that is, on the functionality of the current sub release, *plus* all prior sub releases.