Collaborating in Agile Projects

Collaboration in the Waterfall process model

Besides working in short iterations, there’s something else that differentiates Agile from Waterfall, and that’s the way people in different roles work together.

In Waterfall, roles are linked to phases. Analysts provide requirements. Designers create a functional and technical design. Developers translate this into code. Testers validate that the code implements the requirements. If the application is complete, it’s handed over to the maintenance team. Because all phases are performed only once, resulting in a final product which is called a milestone, it’s characteristic that all roles are performed sequentially. The transition between the different phases occurs when the final product is handed over to the people who perform the role of the next phase.

Normally, this seems like a practical and manageable model. During any phase, there is only one active role. It also seems cost-effective. After all, during any one phase, all the other roles are not needed, they’ve finished their work and gone on to the next project. There are, however, some disadvantages to it.

During each phase, a role gains a lot of knowledge about the project, the domain of the customer, and the organization for which the project is implemented. Although this knowledge is recorded as well as possible in finalizing the phase, it’s impossible to transfer all knowledge in writing. After each phase, part of the knowledge remains in the minds of people who left the project.

Collaboration in Agile processes

Collaboration is arranged very differently in Agile. Regardless of the approach or methodology, Agile projects are focused on close collaboration between the different roles in teams. Not one after the other, but with each other. This immediately delivers added value.

Focus

All roles on the team focus on the same small set of work items to be realized in one iteration. This focus makes a team efficient.

Feedback

This joint work on a limited set of work items ensures that feedback from all roles is processed within a few days. In a Waterfall project, this often takes months.

Different view

Each role on a team has a different view of the work items. An analyst has a very different view of a user story or smart use case than a developer. A tester is focused on exceptions and acceptance criteria. This way, a work item is viewed from different angles at the same time.

Hand-over

There’s no throwing-it-over-the-wall approach when a document is delivered. The different roles work simultaneously on a work item.