How do Waypoint and Lean and Agile relate (or map) to the development cycle in a DTAP (Development, Testing, Acceptance and Production) environment?
DTAP is a (software) development method defining clear environments and sequential steps. A developer starts working on a feature and when he thinks it’s ready, she sends the feature to a test environment. The test environment is used to test if the feature behaves as expected. This is done either manually or through automated tests. If everything is okay the tester sends the feature from the test environment to the acceptance environment. The customer will see and ‘accept’ the feature if she’s satisfied (or if the feature is legally correct). Now the feature is ready to be move on to the production environment.
So how does this structured and sequential process fit in a Lean and Agile environment (utilizing Waypoint) ?
Well, actually, it fits quite comfortably if you allow yourself some conceptual freedom. In the aforementioned description I talked about a feature and not about a product (on purpose). When you look at the DTAP cycle per feature instead of the whole project you can utilize Lean and Agile tools to increase your development speed.
In the diagram below I show a mapping between DTAP and the Lean and Agile process. The diagram shows how the DTAP phases and environments map to the cycles of an Agile process.
The D, T and A (of DTAP) happen during each iteration. The team works on the development of a feature and deploys this feature, when ready, to a development or staging environment.
This feature is tested during the same iteration by the team, for instance using written Test Cases for each User Story and automated unit tests (for instance utilizing Test-driven development). The acceptance happens at the end of the Iteration during an Iteration Meeting. The benefit of an iteration meeting is that you only talk about the features in active development during the specific Iteration. This talk is with the whole team, including the customer and possibly some external stakeholders.
All stakeholders (including the customer) are involved in the acceptance of the feature. This turns the iteration meeting into a great continuous learning effort for the whole team (again, including the customer and other stakeholders).
When the product is finished and the release ends, the final product can be deployed to the production environment at once. Final deployment happens at the end of the release.
One good agile practice is continuous deployment. When you implement continuous deployment not only for your development and staging environment, but also for your production environment, you basically embed the P (of DTAP) inside your iteration cycle.
Using a Distributed revision control (DVCS) system for instance we here at Heyunka try to deploy to different environments as often as possible (Joel Spolsky wrote an excellent tutorial on how to use a DVCS system). When a developer thinks a feature is ready, he pushes his changes to the central development repository, which is deployed continuously to a staging environment.
Changes then are, at will, pulled to a QA repository and automatically deployed to a QA environment where they can be tested. If we think the features are ready to move to the production environment. We pull all the pending changes from QA into a production repository and deploy to the production environment.
As you can see DTAP and agile practices can work together easily. As with all Agile practices it (only) requires a bit of discipline to implement. Using a continuous deployment and good test practices try to reduce your DTAP cycle to fit at least in an iteration cycle.