Big Teams and Agility

In Grass Roots Agile, I talked about some of the details surrounding how development teams can increase their agility, and I presented a diagram similar to what’s above that discusses how to measure and manage a system’s tested features. Here, I want to talk a bit more about the macro development process, and how I’ve used agile practices on large software development teams. I’ve used this structure with teams up to roughly 100 developers. I have no reason to believe it wouldn’t work on larger teams, though. Here’s the general mechanics illustrated by the diagram.

Team Structure

One of the keys to building big software projects is to break it down into a bunch of smaller projects. Each team in the diagram (Team 1, Team 2, etc.) represents a group of people working on one of these smaller projects. The smaller projects are organized around coarse grained units of business functionality and each team focuses on developing the complete unit of functionality (front to back).

Each of these teams consists of around two to five developers, a business analyst (BA), tester, UI designer, and customer. Depending on the size of the effort, some of these individuals may span teams. A project manager spans all teams. The developers on each of these teams focus on some aspect of technology expertise. Examples include a JSP expert, Hibernate expert, etc. These technology experts form alliances with experts on other teams, which is critical to ensure consistency with how the technology is applied project-wide (ie. the architecture). The technology experts will also spend some time on infrastructure code, such as system-wide error handling utilities and other important architectural aspects. Naturally, you adjust the size of the teams and the roles of team members based on various factors.

The Feature Board

The feature board is a virtual concept that represents the stream of requirements that flows from the customer to the development teams. It is the responsibility of the BA to make sure there are an adequate set of requirements on the feature board, to resolve conflicts, and manage change. Everyone on the individual teams should have the option to participate in discussions surrounding requirements. The feature board could be your typical project room whiteboard, but for large teams, that’s probably not going to work because you have a group of geographically dispersed developers.

Instead, the feature board is simply a snapshot of requirements, and each team pulls those requirements and starts working on them when ready. These requirements might come in the form of user stories, use cases, or something else. The format used is not as important as the fact that the feature board is organized in a way that each team can pull the next set of requirements for the part of the system they are working on when they are ready, while allowing project management to see a complete view of the system requirements.

Continuous Flow

One of the challenges with a large team is that it’s virtually impossible to get everyone aligned on the same iteration schedule. There is too much management overhead. This is one of the driving forces behind why skeptics don’t feel agile is a good fit for really big projects and teams. The economies of scale lead us to believe we need longer iterations because there is so much more to manage. But that’s flawed because it delays risk mitigation and discovery.

In practice, there isn’t a need to have each project team on the same iteration schedule, and in fact, because the teams pull requirements from the feature board when necessary, there isn’t a need for iterations at all. Instead, there is a continuous stream of work that flows from the customers to the development teams. As a team completes a piece of work, they simply release the code to the version control system, build it, and feed it right back to their customer in form of a functional system.

The Build

With each team releasing code, there is a continuous stream of feature rich functionality that is added to the system. Continuous integration and the automated build process holds it all together. Because we are building on a frequent basis, we’ve got a system of checks and balances in place to make sure no breaking changes enter the main product line.

Occassionally, we’ll hit a situation where two teams release incompatible changes. That’s the purpose of the build! When this does happen, the build breaks, the problem is identified, the teams fix the problem, and we’re back on track. This is a central part of the macro process. Without the automated build, it all falls apart. Once the build executes successfully, the application can be deployed to an environment where it’s accessible by the customers.

Closing the Loop

Adopt all the agile processes and practices you want, but increased agility completely falls apart unless you close the feedback loop. I’ve seen too many teams fail because they’ve stopped just short. Feedback is the crucial piece to ensure we close the loop, and because we’ve got a continuous integration process in place due to the automated build, we are able to effectively close the loop because we’ve always got a product that works. It’s important to leverage this. Eliciting frequent feedback from customers through weekly demonstrations is one way to close the loop.

We should also frequently execute a variety of tests. Not just unit and acceptance tests, but usability tests, performance tests, load tests, and more. Because the build is an automated process, we should incorporate code analysis and inspection tools into the process and output the results to a project dashboard that is accessible by the project team. In the end, closing the loop is going to help significantly in increasing project transparency.

In Summary

This is a very broad overview of how agile can work on big teams. In fact, I believe agile is more beneficial for large teams than it is for smaller teams. Small teams are inherently more nimble than bigger teams in the first place, and so agile is an obvious and natural fit. But on large teams, it’s not so obvious how agile practices can improve the team’s success. Above is one formula I’ve found that works very well.

Without question, there are numerous micro process mechanics that I haven’t discussed here. For instance, how often should the build run? (I say at least hourly). For really big systems, how do I keep the build running quickly? (You may need staged builds). What tools do I use to make this all happen? (You don’t need to buy anything, actually). And much more. But in general, the macro process above is a good way to get started.

From http://techdistrict.kirkk.com/