Agile & Waterfall In The Same Project - The Collision Of Idealogies

 One project I worked on involved several suppliers designing and building separate modules to be used in the construction of the full product - this is nothing new in software engineering, but whilst I led the testing for one of the modules developed using (loose) agile methodologies (in fact, upon reflection, very loose! ), the other players used traditional ones. And boy did this make it chaotic!

During the majority of the project the team I was in performed agile testing - along with providing instant feedback to the developers on evolving functionality, we built an automated regression test suite for UAT-level coverage. At the same time though, due to lack of appreciation of the problem in hand and not looking to the future, the project management team neglected to work out what would happen when the two paths would ´collide´ during the final SIT/UAT testing phase. This lack of foresight meant that when the teams using the traditional cycle wished to start the six week-long testing of their product with ours in month 5, they required a stable and fully developed application on which to do so. The problem was that at that time our team was still producing new features which, until completed, would not allow this form of structured testing to be executed. No thought had been given to the need for all integration aspects to be there - I had raised it as an issue early on but was still unaware of the size of catastrophy winding it´s way to our door.

What ensued was a very problematic and chaotic spell of SIT where daily deployments were attempted and large numbers of blocking defects were uncovered. This introduced huge overheads such as continual environment updates, constant questioning on exactly what functionality was there and available to test and the basic fact of frequently changing code providing real instability and thus multiple test reruns. It also meant that the testers had to get involved in manual testing phases of integration between the modules whilst trying to keep up with new feature development.

The clear points it showed me were

1) If a project team permits the use of agile methodologies for development of one module and not for others (for whatever reason - in this case due to multiple companies being involved), there is a much higher risk of not completing a thorough testing effort and much more administration/tracking overheads.

2) If agile methodologies are to be used, EVERY task must be put into the product backlog. Attempting to manage the project with more than one base planning method will (I think) come unstuck every time (please correct me if I´m wrong!).

Rather than plan the delivery of functionality for every sprint in the project on day 1 and then try to link it all to the waterfall plan of other modules over a 6 month (or so) period, compile the normal product backlog and add the integration tasks for the other modules to it. Then manage the project on a sprint-by sprint basis, monitoring expected delivery dates from the traditional cycle(s) and adding them to sprints a week or so in advance. Then there will be much more accuracy in estimates, expectations and MUCH less guess work.

Or just do it all using agile, it´ll be much easier.