Much of the literature of agile software development is concerned with the concept of "self-organizing teams."...
On the face of it, it seems a simple idea: let those responsible for delivering the software decide themselves how best they should work. But the details of that organization, the nature of those decisions the team makes, are rarely made explicit.
Most agile teams are co-located, working all together in one space. But there are also high-functioning telecommuting agile teams in the world, and working on such a team is a different (and, done well, very rewarding) experience. One unique aspect of telecommuting agile teams is that much of the team organization and workflow must be made explicit and documented in writing, because the verbal conversations that would normally happen in a co-located team room are shifted to other media: issue tracking systems, IRC, email, wikis, etc. This pervasive, necessary, critical documentation required by telecommuting agile teams exposes the practices of high-functioning agile teams in a way that is impossible for co-located teams to demonstrate.
High functioning agile teams are constantly tuning two aspects of their work: team roles and team workflow.
Workflow is critical
For a co-located team, stories and tasks are usually index cards on a board, so the team can move them around, write on them, put them up and take them down. Telecommuting agile teams need to manage more information about their stories and so devise systems to manage that information.
One agile telecommuting team manages their workflow on a wiki. Each story has its own wiki page, and each component of the story and each task for the story is a link off the main wiki page for each story. The workflow moves from concept to development to test to release in a very public way, with the status of each story indicated by particular tags that can be manipulated by anyone on the team to show what needs to be done next to the story.
For example, a story might start by being tagged "Analysis." This tells the team that their feedback is needed. The story might move from there to "In Development," when coding has started. This tells the team that there is code being created for them to read and to run. Sometimes the development gets stalled by a lack of information in the story, so the tag might switch back to "Analysis."
Once the story has working features, the status might move to "Testing." Dedicated testers now control the workflow, and may move the status back to "In Development" or "Analysis" if the feature is found to be implemented incorrectly. When the software for the story is tested well, the tester might change the status to "Release," indicating that attention from system administrators is required to package the software for production.
These are not handoffs in the traditional sense. Since every step of the process is open to every member of the team, it is a matter of ceding authority for the whole workflow to the proper team members at the proper time.
Another agile telecommuting team has a dedicated tool from Atlassian called "Greenhopper" that emulates cards on a board. Greenhopper is highly configurable, and this team has pushed the configuration of Greenhopper to the limit in order to accommodate their own particular workflow.
Note that both teams function very well in the complete absence of what is usually called "management." With a well-designed workflow and a conscientious team maintaining that workflow, typical management activities of coordination and information dispersal are simply not required.
Team roles as a continuum
It is likely that people on an agile team have titles describing the work they do: product owner, Web designer, developer, system administrator, tester, etc. In practice, though, the roles often overlap considerably. The product owners or the Web designers or the testers might be actively contributing to the code base. The developers might be doing testing and business analysis. The work that needs to be done is simply done by those who are capable of doing the work.
So while each team member might have a special area of expertise, there are some activities done by everyone. For one thing, everyone is a business analyst. Everyone reads the stories, everyone contributes to making those stories as clear as possible to everyone else. Without a shared understanding by the whole team of what needs to be done, it is impossible to do anything well. And on a telecommuting team, the amount of wasted effort incurred by misunderstanding can be orders of magnitude higher than on a co-located team. A telecommuting agile team spends a LOT of time writing.
For another thing, everyone does quality assurance. QA is the work of creating, maintaining, and improving the process that everyone follows. Everyone on the team has a vested interest in getting the right information to the right people at the right time, so the software development process and the tools to manage that process are being adjusted constantly.
Finally, everyone automates. The more robust automation that is in place, the more time each person on the team can spend exercising their particular talent and specialty. So developers automate unit tests so that they can code better, web designers create templates so that they can design better, testers automate regression tests so they can spend more time testing new features, system administrators automate deployment and maintenance tasks. And each person on the team contributes to making all of this automation as effective as it can possibly be for the others. This is, after all, what computers are for.
Working in the continuum
On a high-functioning agile team, whether co-located or telecommuting, there are no silos or hierarchies. There is simply work that the team needs to do, and there are times when each role on the team is in a position to make the decisions about what needs to happen next in the course of that work. As the stories move toward completion, there are no handoffs in the traditional sense; after all, everyone on the team always has access to all of the information for all of the work. Instead, there is a recognition by everyone on the team that a product owner is expert at creating stories, so the product owner makes those sorts of decisions. A developer is in the best position to decide how the code should be created. A tester is in the best position to decide whether the code is suitable for use. These shifts of authority along the continuum of practice are graceful and routine, controlled by the workflow the team has designed.