no matter what life cycle model a team runs, the flow of change generally occurs as such: developer checks out code, make incremental change, performs incremental tests, submits change, continuous integration then performs build, test, deploy to QA. from a process perspective the majority of tasks that occur once the developer checks in code is symptom identification. continuous integration is symptom identification, it is a defensive process, defending against failure. consider the cost of all post development task and ask what percentage of effort and activity goes towards identifying symptoms and defending against failure. now consider this approach. the development team creates a reference product that is a close a possible to a production deployment. developers all have access to checking out a reference product, making incremental change, performing incremental test, or full on automated test (that would normally be performed post developer checkin) prior to checkin (this is called pre-integration) -- when the developer check their changes in -- they in affect are checking in a reference product -- now more activity downstream is focused on audit and tailoring the reference product (less efforts on identifying symptoms more effort on adding value). all downstream teams also move upstream ahead of development. their charter as an upstream team is to deliver into development everything that is necessary to produce a reference product and deliver a reference product successfully into continuous integration (they are adding value to the developers productivity and accuracy). now QA instead of primarily being a symptom identification effort has become a pro-active value added provider into development and an auditor on outputs. this will significantly reduce the context switching which in turn improves developer rhythm. It will also improve the ability for the development team to Pivot, whether large or small. What this does is engage the architects and developer in the end-to-end process as we've moved the developer closer to deployment, and the downstream folks, upstream where they play a huge role in the success of development versus developing tools and process to defend against failure. we'll start to see where most of the tools we've used for years are symptom identification tools and need to be revisited to become value add tools. BDD and TDD are examples of value add tools/practices. continuous integration as practiced today is a symptom identification tool -- it needs to be turned into a value add tool