.png)
Large projects are often fraught with complexities as the collaboration between different sections of developers, analysts, and testers is difficult to establish. The most common approach to facilitate better collaboration and communication is to break it down to sub-teams. However, there is a downside to these sub-teams as they tend to create stove-piped subsystems when the communication thins down between these teams. Precisely, this approach could significantly result in a non-homogenous and inconsistent architecture.
Dividing at a Later Stage
It is suggested that instead of dividing the project in the beginning and then going about each sub-problem, begin with a core team. The core team is instrumental in building out a valid standard business case in a test-driven manner touching all of the primary business areas and framing most of the architecture. With a small team in action, a full agile methodology with collaboration works like a charm. With a significant portion of the architecture completed, the first phase comes to an end with a stable code base. It is now the time to divide by growing the development team and splitting it up into smaller teams to render the project into a functional system. Because the architecture has been built out in a test-driven manner the team has the exact amount of complexity that it can deal within a homogeneous architecture in different subprojects.
The Project Brain
After dividing the project into sub-teams, a team of analysts, developers, QAs, and managers are assigned to work on the big picture of the project “The project brain team”. After the division, each sub-team starts to be in its own world. They act like different organs in a human body. Each has its own function but they all need a brain to interact together. The overall project manager should have an overall vision of the project. He is responsible for planning the whole project and makes sure that sub-projects are going in parallel in a timely manner. Interdependent projects should have stories played according to the dependencies between these projects.
The master project manager is responsible for making sure that these stories are played in a timely manner to resolve dependencies and to be able to test integration between sub-projects as early as possible. Overall, managers will have to manage the whole project plan according to sub-teams’ plans and their projected velocity. Managers have to make sure the project will deliver on time. If a team needs extra resources due to missed requirements or underestimation of stories, resources may be acquired from other teams that are ahead of the plan.
