Achieving Agile Software Development with Large Teams

Distributed Teams, by David Hussman

Most agile practices ask project members to keep communication channels open and filled with honest dialogue, without regard to the message content. Nowhere is this more important than on an agile project with distributed teams. Along with the usual technical challenges of distributed development, agile development brings even more challenges, mostly aimed at those outside the development teams.

Project managers, coaches, and customers need to be vigilant when it comes to listening to and addressing the developer’s concerns; tracking successes and failures; the way in which story content is gathered, organized, and presented; and the consistency of the process and the development environments.²⁰ With distributed teams, the need to embrace change and make the necessary corrections to the direction of the project sooner than later is even greater. Just as the last car of a long train starts moving long after the first, so too does change take longer to move through the distributed teams.

The following list of best and worst practices might help those outside the development group find and address needed changes before the project strays too far from the correct path. Many of the listed items apply to any scaled, agile project, but their importance is heightened when the development teams are distributed:

Best Practices

• Customer agility: Ensure that customer teams can make any necessary changes by keeping the ratio of customers to developers as low as possible (one customer to three or fewer developers; the larger the project, the smaller the ratio). The ability of the customer team to react and change direction can be difficult when stories cross team boundaries and teams struggle to bring portions of a software solution to fruition. For example, if five people are writing a book together, with each person working on a different chapter, the lucidity and cohesiveness of the book is proportional to the amount of time the authors spend discussing the book with each other.
• Group speak: The more often that project managers, coaches, and trackers discuss planning and development issues, the better. Although this discussion can take place over e-mail, at a wiki site, and through non-verbal channels, ensure that at some point there are conference calls or video conferences. If possible, have a different team lead the discussion on every call (this helps all involved to embrace the project). Also, as teams grow and change, each group starts to form its own view of the project picture. Sharing your team’s lingo with other teams can aid in maintaining a common view and provide cross-team insight.
• Common acceptance: If possible, ensure that each team is building and testing against a common set of hardware and software (if this is not possible, discuss the environmental differences regularly). The closer the environments, the better the level of acceptance testing. Try utilizing a common acceptance testing strategy, and whenever possible share the data sets used for testing. Try to start automated acceptance testing early, and run the tests as often as possible.
• Developer rotation: Often times, teams in the same building feel as disconnected from each other as teams separated by states or countries. If possible, move players from team to team. If the players cannot colocate, explore the notion of rotating the work done by the teams instead of the team members themselves. This may seem like an unrealistic suggestion, but it may be a way to help maintain a healthy project whose members have a holistic perspective.

Worst Practices

• Technical stratification: It is often a natural fit for distributed teams to work on subjects that they are familiar with (this is often why distributed teams are brought into a project). If at all possible, avoid splitting development tasks across technical boundaries. Try instead to plan and develop toward functional goals and subdivide the work from that perspective (this will avoid the classic producer-consumer relationship between teams, where one team has finished all its work and is left with nothing to do).
• Failure to communicate mock implementations: As teams may not have everything that they need in order to complete a particular feature, they may choose to mock or stub-out temporary solutions.²¹ This is fine (and, if everyone is using the same code base and acceptance tests, it can be quite clear), but make sure that the interfaces to the mocks or stubs are agreed upon by all.
• Loss of iteration synchronization: In most cases, it is best to keep all teams on similar iteration boundaries. It may be that the teams (and more importantly, those in charge of the planning) find a steady state with varied iteration boundaries. In either case, ensure that the iteration synchronization is as constant as possible. Again, as with scaled, agile projects, if a team has an iteration schedule slip, even of just a couple of days, planning issues may arise that are best dealt with by moving the incomplete features to the next iteration. The difference may seem small, but the consistency will benefit the project plan.

Conclusion

Distributed teams using agile practices face many of the same problems that subteams face when agile projects scale to large numbers. The need for vigilant and constant communication is exacerbated. Small issues can quickly grow large or span several iterations if not known to all team members. One team’s frustration can affect other teams without it even knowing it. Strive to keep process, schedules, and environments constant, and when they change (as we know they will), notify all involved as soon as possible. The more that can be shared between teams (source code, data, and so on), the easier this task will be. Ensure that planners listen to the developers, and help them listen to one another.

Open Source, by Dierk König

The open source movement derives its name from the practice of sharing the source code of a valuable product among an arbitrary number of developers. This so-called collective code ownership means that the code belongs to all these developers. They are entitled to change it and are responsible for the final result.

In the context of this book, open source projects may be of interest because they share properties of both large and agile projects. They make use of agile practices while suffering from the same problems that large projects have in regard to team distribution.

I’m not so bold as to claim that open source produces better results in general. Sure, lots of open source products are widely known for having excellent quality with zero costs to the user. But I’m the first to admit that there are also numerous sloppy projects out there that will never produce anything useful. However, maybe we can take something from the successful ones!

Distribution

It is evident that the physical co-location of all of the contributors to an open source project is impossible. However, we have observed that members of the core editing team of an open source project sometimes get together to tackle a special issue, often sacrificing personal time and money. The collaboration then looks like an Extreme Programming pair programming session.²³

Even the users of open source software hold events so they can get together and share their experience. The Eclipse Code Camp is one example.²⁴

If the open source people put so much effort into overcoming the obstacle of distribution, can we—in paid time—go upstairs to pair up with the database guy?

Idiosyncrasies

An open source contributor is not forced into anything. If you do not like anything about the project (the setup, the code style, the technology, the people, and so on), you can leave at any time or even fork (make a new project based on the old one).

This, and the fact that a lot of people write contributions in their spare time, leads to a project staff that likes the applied work style, or at the very least accepts it. The number of complaints is noticeably small.

One could claim that open source projects are not limited in time, scope, or resources, and therefore do not need the measures of control that are applied to in-house projects. This is not really true. Running an open source project in your spare time, knowing you have only a few hours a week to work on it, makes you think hard about what to implement next.

Open source is opportunity-driven. Whoever needs a feature the most will implement it and submit the contribution. Nothing is produced for the shelf. Contributors undertake their tasks without anyone telling them to.

Developers know that their code will be read, literally, hundreds of times. This is motivation enough for them to achieve high code quality, and it is a good opportunity to show off their professional expertise.

Now, without any imposed order, programmers do what they think is appropriate; surprisingly, this does not result in total chaos, but rather in automated testing techniques, stable and frequent builds, ubiquitous version control, flexible architectures, and self-documenting code. Most astonishing is that these programmers manage to achieve something that most organizations do not: mutual respect among team members.

Architecture

Open source projects typically do not start with an up-front architecture (Eclipse may be an exception), but they always have one in the end. The opportunity-driven nature and the resource constraints of open source force contributors to practice reuse. This is especially apparent in the Jakarta project family.²⁵ Every project is built on other projects, which were built on projects that came before them, and so on.

The new challenge is to manage project dependencies, a well-known problem that most big organizations struggle with. Open source offers an easy yet powerful alternative: Let the user decide.

Another idiosyncrasy of open source architectures is the focus on extension points and pluggability. JUnit,

ANT, and Eclipse are perfect examples of this approach.²⁶

Just think of the effect that applying the principles of open source software would have on your corporate IT projects.

Project Structure

In open source projects, you typically see a core team of editors with write access to the repository. The requirements for becoming an editor differ on every project. Some do not have any restrictions, while others only grant write access to contributors that consistently submit quality work. Some projects have a fixed group of editors.

The core team decides whether contributions from the outside get incorporated or rejected.

Communication channels are highly self-organized. The flow of information typically takes place on mailing lists.

Project Setup

For open source projects, having a self-contained build is absolutely crucial. It is no wonder that open source projects were the pioneers of build automation. The same holds true for the use of versioning systems, nightly builds, and automated self-testing.

As the source code is highly visible, a new degree of rigor is applied to the end result. The source code is subject to excruciating review and refinement. Its compliance to every standard in use will be checked for all platforms the community uses. The contributor has total control over how to achieve this result. Assessing results rigorously but giving developers freedom to use their own work style is a strong agile move that large projects can follow as well.

Documentation

Typically, in open source software there is not a lot of external documentation. The code must speak for itself. Although it may seem unusual, this strategy works well on open source projects, where the code, especially the test code, must reveal its intention.

Successful projects are often accompanied by articles and even books. The usage documentation that comes with the distribution typically contains only very basic help for the beginner.

It appears that any necessary external documentation gets written on request. For example, in Canoo WebTest, we had a fairly complicated security use-case.²⁷ A user volunteered to write the documentation for this, provided that someone helped him figure out what to do.

The result seems to be a good balance between the two extremes of lacking all the necessary information and having excessive documentation in which the important information is hidden among pages and pages of unnecessary text.

Planning

Frankly, there is no long-term planning whatsoever. There are exceptions, but for most open source projects, there is only a little short-term planning. The reason for this is to save the developers unnecessary work by not prescribing long-term directions of any greater detail than a common vision. Directions are derived solely from user feedback.

The most challenging part of adopting open source strategies in corporate IT projects may be trusting in the evolution and refinement of a complex adaptive system that is beyond managerial control.