Collaborative personae

You’ve got to love the Internet. Find a challenge that you haven’t come across before? Tippetty-tap on Google and before you know it you’ve found someone who has already.

And so it has been with the issues of agile approaches to software delivery in the context of collaboration tools that I mentioned earlier this week.

My searching led me to some work by a group of IBM researchers who had identified the same challenge – that agile approaches (and particularly the technique of using user personae) failed to cope with the group dynamics inherent in collaborative software.

Their work led to them defining six types of teams, which we in turn are further developing. They look a little like this:

A project team is a group of people brought together to deliver a particular product or outcome. The team lifecycle has a beginning and eventual end. Members may be there for the whole duration of the project, or for just parts of it when their skills or time are required or can be afforded. For most people in the team, their personal work objectives are aligned to the objectives of the team.

(The IBM model split project teams into stable teams, where most members were there for the duration, and dynamic teams where most members were not. At the moment we didn’t think that distinction would be helpful in our context.)

A client/supplier relationship team is a group of people from both sides of a business relationship whose objective is to facilitate good communication between both sides. An account management team and client representatives would be a stereotypical example, but such teams can exist within an organisation between operational silos as well.

A service delivery team provides an ongoing service to a client or customer with no defined end point. Such teams might work under service level agreements to provide an indication of successfully achieving their goals. Team members are likely to be relatively stable, and the activities of project teams are likely to change the operational activities of such groups. This highlights that it is quite possible for an individual to be a member of many teams of different types at any given time.

(This team wasn’t included in the IBM model, which was derived from the study of software development teams where we are assuming there wasn’t much service delivery going on. The rise of DevOps working though sees much more software development move into this type of team structure.)

A committee is the first team type where the activities of the team are probably secondary to the activities of most of the individual members. A committee is a group that operates in a pretty structured manner to provide oversight or insight to a particular matter. A project governance board is a good example here (as separate from the actual delivery team).

A community is a (possibly leaderless) group of people who come together because of some sort of shared professional interest or cause. Secondary to day to day activity, a community is there primarily to share expertise and knowledge.

A networking relationship is a usually small (often just 2) group coming together to share knowledge on a particular topic or theme, or to seek assistance. Mentoring relationships would be a formalised example, hooking up for a coffee a less-so.

(In the IBM work this was referred to as a professional relationship).

From these groupings, or next stage is to develop out team stories that can start to articulate some of the things that they might do, to then in turn help provide examples of where collaborative technologies might help… For example, for a project team, to ensure that we successfully deliver our project we need to track the progress of tasks and activities might lead to looking at how co-authored documents within Google Drive or Office Web Apps might provide a platform.

The aim here is to both provide some frameworks for people to start to see how collaborative tools can improve a team’s working practises, and also to help identify which teams to work with in the first place.