Are you trapped within a traditional waterfall development environment? Do you long for the ability to change to an agile environment? It's not as easy as some may lead you to believe, but it's not impossible either. Perhaps the first step should be to incorporate an iterative approach first. A modified waterfall approach would interject incremental and iterative development on top of a waterfall structure. This would allow for a clear depiction of when client reviews will occur and when "final" deliverables can be expected.
Incremental development allows for smaller, structured portions of the larger product to be designed and developed as a base in order to be built upon for later increments. Each increment is built, tested and refined before being considered complete.
This iterative nature allows for creative, development, and testing to occur on smaller portions of the project at the same time. This workflow allows for refinements to the design and implementation to be handled early on. It can help to not only catch and fix bugs in the early stages, but also improve the likelihood of minimal errors at the end of the project lifecycle.
The incremental and iterative approach can be interpreted in many ways, but the underlying philosophy relates to breaking down a project into phases. To properly adopt the process we begin by clearly setting an expectation of how the phases are organized. As a general outline I have included four phases below: Inception, Elaboration, Construction and Transition.
Inception
The inception phase is the planning phase of the project including Account, Creative, Dev, Producer, QA and UX. This is when it is determined what the general steps of the project will be based on beginning development in the wireframe stage.
Elaboration
Elaboration is breaking the project down into small, testable, incremental chunks of the overall project. This could begin with general templates, then navigation, global elements, then individual page content that is separated by subject matter or category. Special interactive elements can also fall into a separate increment and may be broken down further if multiple or complex interactions exist.
Project Backlog
The project backlog contains the portions of a project that have yet to be developed. The items in the backlog should be divided by practice: Creative/Dev/UX. As items are completed in one practice, they can be moved to the backlog of the next practice.
Construction
The construction phase includes the iterative development of the items within the backlog throughout the project.
In Process Items
The "in process" items are brought over from the "backlog" when work begins on that portion of the project. When in development, the developer should also ensure that all cross browser concerns are addressed during the development of that portion. This will alleviate the burden of cross browser compatibility testing and development on the project as a whole at the end of the project.
QA Items
The items in QA are either in QA already or are ready to be sent over to QA. These items should have already been alpha tested by the developer and within a completely testable state.
In Routing Items
The items in the "in routing" column are those items that have been developed and are either off to be screenshot or in true routing. Some items, while testable amounts of content, may not qualify as enough of the project to route.
Transition
The transitional phase includes, but is not limited to, moving the project from development to either a staging environment or into final deployment.
Done/Complete Items
While the "done" column does not necessarily relate to the project overall, it does relate to the portion of the project that has been completed from the backlog. As a portion of the project is developed and passes QA it can be moved to the "done" column. If issues come back from QA, the item does NOT go back to the "in process" column. Instead the item should remain in the QA column until it has passed QA.
If a developer is working on the next item in the backlog and the previous item has not passed QA, the item in development should be put on hold until the item that has been returned from QA has been resolved and returned to QA. Changes to the code for an increment that has been returned from QA can affect the code for the next increment. Since many of the items in this model are considered smaller portions of the next iteration it only makes sense to build upon an approved foundation rather than going back to fix earlier issues at a later date.
