The software industry does a very poor job of learning from its history. In 1968, Melvin Conway gave us Conway's Law, which states that organizations that design systems are constrained to produce designs which are copies of the communication structures of these organizations.[1] In other words, the design and architecture of software is a reflection of the team or teams that built it. Agile practices speed software delivery and increase software quality by increasing communication and sharing valuable information. The team structure and collaboration methods in place are critical aspects in ensuring the development team delivers resilient, adaptable, and high quality software.
Team Structure
It should be no surprise that large software projects have a higher failure rate than do smaller projects, and that larger teams are more difficult to manage than smaller teams. For large projects, dividing the system into smaller systems, or modules, is one technique to make development a bit more manageable. Herein lies the rub. Failure to share information across these smaller teams of developers results in each module having a separate architecture, inconsistent user experience, and disparate levels of quality depending on the practices employed by each team. This is the heart of Conway's Law. While SOA may be the architecture model du jour, the benefits of loose coupling and service transparency can work against a team if developers rely solely on the service interface as the means to communicate.
To avoid the integration
Advertisement
and quality issues that surface when teams work in isolation, team cross-pollination is important. Experienced developers from each team must communicate on a regular basis to discuss architectural, functional, and technological issues. The structure and makeup of the teams have a significant impact on the teams' ability to communicate. I've found two common models used when organizing teams of developers:
Process Organization. With this structure, groups of developers focus on developing complete business processes. Each process may or may not be part of a larger, consolidated system. The group of developers emphasizes building front-to-back functionality, including all user interface, business logic and data access functionality. The greatest benefit is that developers gain a more intimate understanding of the business process and tend to be more connected with business objectives. For larger systems, with many smaller teams of developers focusing on developing support for business processes, Conway's law tends to surface quite readily.
Technology Organization. With this structure, groups of developers focus on working with a certain technology. For instance, one group of developers might be solely responsible for the data access layer, with others focusing on the business layer, and others focusing on integration with external systems. This allows developers to gain a significant amount of expertise with specific technology, such as Hibernate in the data access tier. But all too often the teams lack a clear and concise vision of the business goals of the project. Without this understanding, developers tend to emphasize technology excellence over business excellence. In addition, integration issues can easily arise if developers across tiers fail to communicate.
Since I've found it produces more positive results, I favor process organization over technology organization since developers gain a more intimate understanding of the business processes they must support. The challenge with process organization, however, is avoiding silos that cut off the smaller teams of developers from each other. Encouraging technology experts from within each process team to share information across teams is one way to avoid silos from developing. For instance, a usability expert that spans teams is one way to ensure the system maintains a consistent look and feel. If Hibernate is used as the data access framework, an expert well-versed in Hibernate can offer guidance to ensure access to data is done consistently, reliably, and performs well. Assigning individuals to these roles does not always work. Instead, I'd recommend that companies allow technology experts to emerge from within the process teams and establish a plan for them to fulfill the requirements of this new role while allowing them to participate with their process teams.
Team Collaboration
Favoring process organization offers many advantages, but one significant disadvantage is having small teams working in silos. It's imperative to establish communication channels that span disciplines and teams. I caution against using heavy forms of documentation as the preferred means of communication, keeping in mind that the value of a document is not the document itself, but the thought that went into creating the document.
Project Wiki. A wiki is a form of documentation, however a wiki is really a collaborative environment where all individuals are encouraged to participate. Unlike other forms of project documentation produced by the few for the many, a wiki is the product of all team members' contributions. A project wiki can assume a life of its own as team members use the site for reference material and other useful project information. I would advise against locking down areas of the wiki and limiting edit access to wiki gatekeepers only. A wiki is a community where all team members contribute and share useful information.
Automated Build. The most important artifact produced by the software development team is the source code. It is the only reliable measurement depicting the current state of the application. If the source doesn't compile, the application is not functional. Building on a regular schedule, such as hourly, helps ensure the team is on track. Incorporating e-mail notification into your build process informs all developers of the status of the build. Additionally, producing a build website allows the team to review important statistical information related to the application such as design quality, code quality, and percentage of code under test.
Automated Testing. Executing test cases frequently offers another form of very useful feedback related to the functional correctness of the application. Developers can be notified of failed tests, including an indication of an area of the application that needs immediate attention. Notifying all developers of test status keep the team informed of the functional state of the application. When teams of developers are organized around process, automated integration testing helps the technology experts that span teams evaluate test results for the system and points to potential problem areas.
Instant Messaging. When developers are not located within close proximity to each other, open communication can be difficult. Instant messaging helps developers address simple, quick questions. If the conversation grows too complex, separate face-to-face discussions should take place.
Daily Stand-ups. Short 15 to 30 minute development team meetings where developers present current issues and daily milestones are useful in helping maintain open communication channels. Daily stand-ups should avoid detailed discussion on any topic and when issues do arise, developers should be responsible for following up with each other in separate breakout sessions.
Developer Involvement. Early in the software lifecycle, teams meet with business clients to identify system requirements. As the high level business processes are identified that require system support, it's important to involve developers in these meetings. This works very well when process organization is favored over technology organization, and developers have the advantage of absorbing the context of each important discussion that takes place.
Prototypes and Demos. Regularly scheduled prototypes and functional demos involving team members and business clients ensure that all team members remain in touch with the core business objectives surrounding the development effort. For the development team, prototypes and demos offer insight into other processes that developers may not be intimately familiar with. For business clients, it gives them a complete view of the integrated system. It's important to begin hosting prototypes and demos early in the development lifecycle to help identify inconsistencies across processes, system navigation and workflow issues, and duplication of effort. Wire frames and screen mock-ups can be used as prototypes before a functional codebase is available. As the system grows, functional demos replace the prototypes.
The Agile Matrix
Figure 1 illustrates the Agile Matrix, a cross-pollinating software development team. Teams of developers are responsible for fulfilling the requirements of core business processes, while technology experts working on process teams are responsible for mentoring and communicating across project teams on the most appropriate use of practices, patterns and technologies relevant to a specific tier or specific role. Open channels of communication must be present across all teams and all team members must advocate the use of techniques to ensure that intense collaboration prevails. The result is multiple levels of communication that span teams, roles, and ultimately projects.
Figure 1: The Agile Matrix
Toward Reuse
Many organizations attempt to establish enterprise reuse initiatives centered around technology. Certainly, technology has a significant impact on the success of these initiatives. But frankly, reuse is more of a social issue than a technology issue. Most reuse initiatives I've encountered have been pushed down from the top of the organization. While buy-in from upper level management is critical in adopting and succeeding with any new technology, experts in the field must be responsible for establishing the practices that make these initiatives successful and communication is key. Reuse committees and standards bodies are flawed as they establish guidelines and standards that are theoretically sound, but pragmatically cannot work and result in alienating developers.
With the support of management, practitioners must be responsible for working together to establish and hone team practices that each team member understands. Agile practices contribute to a teams success as module boundaries are established, component granularity is carefully considered, and dependencies are refactored and refined.
Conclusion
Agile practices such as test-driven development, refactoring, and continuous integration are critical factors in helping a team deliver reliable software quickly. Equally important, especially on larger development efforts, are teams that embrace techniques encouraging intense collaboration. Rapid feedback, consistent use of technology, and alignment with business objectives are achieved when teams establish open channels of communication and make information accessible and readily available. As the development team unites and each member contributes, technology and team leads naturally emerge to guide the development effort. As team harmony grows, so too will the resiliency, reliability, and reusability of the software system.
About the Author
Kirk Knoernschild is Senior
Technology Strategist at TeamSoft, where he leads based on his firm belief in
the pragmatic use of technology. In addition to his work on large development
projects, Kirk shares his experiences through courseware development, teaching,
writing, and speaking at seminars and conferences. Kirk has provided training to
thousands of software professionals, teaching courses on UML, Java J2EE
technology, object-oriented development, component based development, software
architecture, and software process.
Articles 
