Home arrow Articles arrow Previous Editions
Collaboration Circa 2007 PDF Print E-mail
User Rating: / 0
PoorBest 
Written by Liz Barnett   
Monday, 08 October 2007

From the Editor More than any other types of software development teams, success on Agile teams requires collaboration among a broad community. Note that there are really two essential points here: that the Agile community is diverse and that its collaboration is effective. Just as we cite the "better, faster, cheaper" mantra to drive development priorities, so have we talked for years about the benefits of collaboration. Of course, team members must work together to achieve common goals. The greater the collaboration, the more likely that requirements will be met and issues will be resolved in a timely manner. So what is the "so what" with Agile collaboration? With a diverse, distributed community and corporate governance mandates, an Agile team must consider collaboration a key - if not the key - requirement. In this article, we'll explore the 2007 perspective and why an Agile team must think about collaboration differently.


What?
A common understanding of collaboration in the context of an Agile team may be useful. Merriam-Webster's dictionary defines the verb collaborate as follows:

To work jointly with others or together especially in an intellectual endeavor.[i]

Advertisement
For an Agile team, it's not sufficient to just "work together." The composition of the Agile team and its effectiveness present unique challenges. Agile collaboration requires inclusion and transparency, features that do not necessarily exist on traditional development teams.

Who?

Most Agile projects start by staffing a core group of developers, testers, team leaders, and a customer or proxy. But in order for an Agile team is to deliver business value, its community must expand to include business staff (beyond the product owner) and any other constituents that will benefit from the project's deliverables, including customers and business partners. The Agile Manifesto states that teams must value "customer collaboration over contract negotiation." This expanded view of community is essential when considering comprehensive collaboration solutions.

Further, the community must collectively be responsible for the product being developed. Metrics must effectively communicate community effort and progress. This means that team ownership - and thus team "credit" for completed work - must override any individual accolades. Individual expertise should not be ignored, but cannot dominate as is the case in most traditional projects where heroic efforts by specific staff tend to hog the glory.

Culture is a huge factor for Agile teams' success and will affect the way in which it collaborates. Jean Tabaka notes that in collaborative cultures, "the success of the organization hinges on how teams formulate, organize, decide, and deliver."[ii] The daily stand-up meeting provides the perfect environment for collaboration, although informal scenarios may actually be as effective.

Team members should also be conscious of their roles' boundaries. For example, Dean Leffingwell suggests that in the daily stand-up meeting, Scrum Masters or project leaders should not make technical decisions or report on anything outside of their responsibility.[iii] In this way, team members are forced to collaborate and solve problems, rather than rely on a leader to impose solutions.

Where?
Geographically distributed teams are the norm in most organizations, whether they reside in multiple corporate locations throughout the nation or internationally. In addition, an Agile team frequently includes members from external consulting firms/outsourcers, business partners, and even end-user customers. Instituting effective collaboration among these global teams is commonly viewed as a stumbling block for Agile teams. However, we've seen quite a number of organizations tackle communication and collaboration challenges worldwide.[iv]

Factors such as time zones, culture, specific development environments, and roles must all come into play. What is the appropriate interface to engage a customer participant on an Agile project? Does the offshore team's culture lend itself to online or verbal communication? Some offshore outsourcers maintain that direct phone conversations are the most critical link in their collaboration solutions.

How?
In past issues of the Agile Journal, we've discussed the need for tools on an Agile project. Even with the most informal of organizations, it is difficult for distributed teams to get by without technology. At a minimum, teams require tools for instant messaging, distributed access to and persistence of discussions and assets, and communication of project metrics. Teams must be able to articulate requirements and then drill down into discrete stories and tasks, regardless of location. Discussions and daily meetings must allow all team members to participate and contribute to problem-solving discussions. Open source tools for wikis, issue tracking, and instant messaging are often the first step for Agile teams. The commercial market today provides a wide range of collaboration environments and project management toolsets (too many to mention here) that support many of these requirements.

The next big leap will come when collaboration for distributed teams extends beyond discussions and shared codebases, and allows team members to collaborate in the context of a specific task or deliverable. For example, if a developer is working on resolving a defect and needs some clarification from the customer, not only can she chat with the customer online, but together they can review the story that defined the requirement and any other related artifacts. Another benefit will come in the form of an environment that integrates all of the components of an Agile project: development assets, project management information, best practices for all activities, and the core tools necessary to produce high quality products.

Sound familiar? It should. These ideas have been bandied about for years but have really just begun to come to fruition. The use of Agile methods highlights the need for more productive environments, since cycles are so short and customer involvement is so intrinsic. There are always new ideas to consider. Here are a few interesting initiatives to explore:

  • IBM's Jazz project, a framework for team collaboration and development, is taking the lead on this "collaboration in context" perspective. Both Agile and traditional development shops can leverage the Jazz environment to pull together project management and application lifecycle management (ALM) tools with whatever degree of process support they deem appropriate. (Existing assets in IBM Rational tools will be accessible via the Jazz architecture.) Agile developers can approach this new environment with existing assets or by starting fresh, and take advantage of an environment that supplies effective and intuitive collaboration capabilities.

  • Launchpad is an interesting approach to open source development and hosting. It specifically enhances the developers' world with a community support environment and flexible code, test, and release tools. This is not the portal to supply enterprise management and reporting requirements, but it could be an effective starting place for Agile teams, who can then integrate their Agile management tools of choice.

  • ThoughtWorks Mingle has evolved from years of its consultants' work on distributed Agile projects and an eye towards the leading-edge tools that have emerged from the open source community. Key to Mingle is its simple interface and its unobtrusive ability to link project artifacts in the shared repository (yes, it's OK to use the "r" word!). Mingle will interface to enterprise portfolio management tools in order to feed into governance initiatives.

  • CollabNet has successfully entered the ALM market from its roots in the collaboration space. CollabNet offers (at least for now) both the CollabNet and SourceForge collaboration environments, Subversion software configuration management, and essential task management and reporting capabilities. What's missing? An army of consultants, as is the case with IBM and ThoughtWorks, to implement the tool and collect a range of best practices. That would be the icing on this cake.

Why?
Of the many factors driving Agile collaboration, the need for transparency is paramount. The imperatives coming out of corporate governance initiatives - be they regulatory requirements or internal standards - demand a new level of rigor. This may seem to contradict the style of an Agile team, but teams have no choice. We cannot view governance initiatives as hurdles to Agile progress, but rather as core steps along the way to delivering business value.

We can consider transparency to be the intersection of culture and technology. By their very nature, Agile teams are positioned for transparency in support of governance requirements. Short iterations, daily meetings, and continuous feedback all provide the distributed community with the necessary information about a team's progress. A collaborative culture will lend itself to embracing transparency and seeking visibility throughout the organization. This is not the only driver for collaboration in today's Agile communities, but it is one that cannot be avoided.

Agile communities are growing. How will yours collaborate?


About the author
Liz Barnett is the Editor in Chief of the Agile Journal and Principal Analyst at EZ Insight Inc. Previously Liz spent 10 years as a Vice President and Research Analyst at Forrester Research, joining Forrester as a result of its acquisition of Giga Information Group. Liz held management positions at Accenture, PepsiCo, and Atelier Research. She also was the Research Director for the advanced software development and advanced network computing research services at New Science Associates, prior to its acquisition by Gartner Group. Liz holds a patent for developing a distributed application development/CASE tool. Liz earned her B.S. in operations research and industrial engineering at Cornell University.


[i] http://mw1.merriam-webster.com/dictionary/collaboration

[ii] See Collaboration Explained, Jean Tabaka, Addison-Wesley, 2006, p.11.

[iii] See Scaling Software Agility, Dean Leffingwell, Addison-Wesley, 2007, p. 112-13, which was also featured in the May 2007 issue of the Agile Journal.

[iv] The Agile Journal has published a range of case studies and best practices of global teams. In particular, see the February 2007, November 2006, and April 2006  issues.

Comments (0)add feed
Write comment


Write the displayed characters


busy
Tags: asdf,
Click to add your tags...,
 
< Prev   Next >






Lost Password?
No account yet? Register

Video News

 
Copyright © 2006 - 2008 CMC Media, Inc. All rights reserved. All marks are trademarks of CMC Media Reproduction in whole or in part in any form or medium without the express written permission of CMC Media, Inc. is prohibited  
 
 CM Yellow Pages | ALM Expo | CM Today | Configuration Management Journal | CM Crossroads