Agile Software Development for Projects Large and Small
Agile software development is generally regarded as an activity geared for small projects. In fact, many see larger project size as a boundary condition for most agile software processes. These boundary conditions are the conditions under which a given process will not be effective. Every software development process has boundary conditions.
One of the proven practices found in most agile software development processes is the utilization of small teams. However, small teams have nothing to do with project size. Many large projects have been made successful by small teams. The Microsoft Solutions Framework (MSF) has advocated the small team approach since its inception. In fact, larger projects often utilize a team of smaller teams to scale up the process.
There is certainly more to building large projects than the organization of its teams. A centralized architecture that provides cohesion between the teams is also a necessary element. This architecture partitions the system so that each of the smaller teams has their own sandbox in which to work. A well-partitioned system minimizes the dependencies between the teams.
The architecture may also eliminate functional redundancy by centralizing common services. These common services are used by other teams rather than having each of the teams create their own. To the common services team, the development teams are their customers. Since every system has differences in functionality and technical approach, there is no single system topology that works across all of the software system domain. However, many of these topologies can be discerned from high level patterns of other, similar systems.
Finally, there must be techniques for bringing large systems together. “Holes” may appear between groups that provide bugs or gaps in functionality. Scenarios and storyboards may be used to “tie” the system together. These scenarios are critical to integrating the pieces and ensuring that the disparate parts look like a single system. We utilize scenarios and storyboards on Visual Studio Team System.
Scaling a project down is even easier. The MSF Team Model has been carried over into version 4.0 and we utilize a matrix to suggest ways to combine roles. For example, the role of “architect” and “developer” is often combined as it is helpful for architects to have an understanding of the internals of the system. Often, architects are the most experienced developers on a project. Some role combinations are not recommended. See the MSF Team Model for the list of these combinations.
MSF for Agile Software Development contains six roles, the business analyst, project manager, architect, developer, tester, and release manager. To play any of these roles, you must simply possess the necessary skills. Your job title may be different. You may also play multiple roles. In other words, the MSF Team Model allows a lot of flexibility in the way that you organize your team. The wisdom that was invented in the first version of MSF was refined over the past decade and is now embedded in our new agile software development process.
