Switching from Agile to Waterfall Methodology
Good Afternoon every one.
We have been following Agile methodology and we have completed almost18 sprints. Later on client has added additional complex features and 2 more applications came to limelight. They have revised the methodology and found that Waterfall methodology is the best suited for our current project. As far as Test team is concerned we wanted to utilize the story cards / test cases and other test artifacts. Fortunately we have some time to transition to Waterfall model completely.
Generally people tend to switch from Waterfall model to Agile model, however in our case it is the other way around.
Can any one please suggest me the best practices or some tips to have this transition smooth.
Thanks in advance,
If it's waterfall you should have time in the planning stage to pull in your old material, but its all in how you adjust your practices to the new model. Good luck!
Nothing learns better than experience.
"So as I struggle with this issue I am confronted with the reality that noting is perfect."
Now wasting blog space at QAForums Blogs - The Lookout
Really great to hear that this kind of situation is possible in current business where one can move from agile to traditional SDLC. I would like to hear from you on how did you managed to pull this off. The challenges i can guess as
1. Team to adjust back from fast paced Agile where tester's questions are being answered almost immediately by dev team or product team.
2. The defects logged by QA team won't be quickly reviewed by dev team.
3. QA team has to wait for longer days to see the new sample UI which can be available for test coverage.
4. Very slow in builds from dev team and QA team would have to sit idle most of the days.
Both waterfall and agile have their own pros and cons.
One of the most important pros for Waterfall (for a QA team) is... to have a chance to implement a "Complete project testing life cycle" approach.
Here, apart from re-using of the artifacts from the earlier agile projects (such a test scenarios, test cases etc...), you can actively involve the testing team to perform ambiguity analysis (or requirement reviews) with the business teams.
In waterfall - the more your requirements are clear, the much better is your application build. Moreover, this is excellent bug prevention approach and leads to a very high-quality product.
Apart from the above, I also suggest to go "Iterative" (if that is a possibility). Iterative methodology of managing projects helps in longer duration implementation times but also takes in the "agility" of agile. What this means is -
1. The senior management along with the release manager can define "iterations" that represent smaller waterfalls (or elongated sprints of 3-4 Or 5-6 month duration).
2. Scope out major releases for such time-frames and have the business teams define detailed requirements along with reviews (just like a waterfall).
3. QA/testing team plays a major role by ensuring the "complete project test life cycle" is implementable with such a timeline in place.
Even though, the project delivery still happens after a year (or lets say after 16-18 months), the team builds-up a lot of confidence with the already built application with these defined milestones.
I would say the key differentiator whether or not to choose Agile vs Waterfall is your dependencies on outside work or other teams.
Because waterfall (In this case I'll refer mostly to RUP, there are other flavors of waterfall with their advantages and disadvantages) has a wide range of up front documentation and consideration such as SDS, SRS, SAS, IA, etc... Almost every specification is spelled out, which makes it easier for outside contractors to run with the ball and have it ready for their new wide receiver that just got drafted. Since it relies less on undocumented knowledge, it makes it easier to switch contractors mid cycle, bring on new talent (scale up), etc...
Agile (I'll referring mostly to Scrum and Kanban, since that's what I've worked in), I think work best with small teams working on a single product, with regular release cycles. Since everyone is already on the same page, it gives enough freedom for the engineers to do what they want and change their minds if something isn't working out. It's great for things that have lots of unknowns as it allows the ability to experiment and iterate on design.
Another model not many people have heard of is the Spiral model. It starts off waterfall like, design documentation is done at a high level, and initial implementation is targeted at getting the basic skeleton in place. Then it becomes iterative like Agile as more details are fleshed out working towards a major release. The idea here is to bring in some of the cross team advantages of waterfall, but still give teams the freedom to iterate on the finer things without those becoming blockers.
Everyone has a different opinion but what i feel is something else i mean things that help us with managing things in a better way is how it has to be.
SO learning the output of it actually give us the way of doing better in the possible way.
And also think of the positive side of waterfall.
1. No more outside overhead of words such as velocity, spike, and stories entering meetings.
2. No more scrambling around.
3. Time to think of what you are working about without having to be concerned of the iteration.
4. Having full documentation so new people can get up to speed.
Tags for this Thread