By not segregating customers and users from the designers and developers, but rather enabling them to work together in a single team, it is possible to use the agile approaches such as DSDM, Turboprototyping, SCRUM to achieve perceptible results. Multidisciplinary teamwork is based on being able to find suitable team members, doing work in workshops and visualising requirements, ideas and decisions with lo-tech tools. This formula has enabled successful teamwork in a number of IS projects in recent years.
During recent years, my colleagues and I have had to adopt new approaches in most of our IS projects. Two of the contributing factors have been the influence of dot.com boom and the increased focus on a well-designed user experience. Having alternated between traditional and agile methodological approaches, I have ensconced myself in the agile camp. So most of my recent experiences are from agile processes and projects using either the DSDM project framework or TurboPrototyping, a teamwork-based approach we pioneered (Ghosh 1999).
Author: Gautam Ghosh, Userminded, Oslo, Norway, www.userminded.no
The main adversaries of agile processes are established, rigid documentation regimen, lack of time and lack of stakeholder buy-in. I have experienced the following challenges when working in with teams in such projects:
* Being able to explore different solutions within the agreed time frame;
* Getting there without having covered all bases;
* Satisfying diverse (and often contradictory) client and user expectations;
* Having something up and running quickly;
* Ensuring team preparedness for an agile approach;
* Documenting enough, but not too much;
* Enabling a multidisciplinary group of people to work together as a team;
* Aiding team-members who don’t see themselves as being creative to participate creatively;
* Ensuring the team’s buy-in to the process and resulting products;
* Supporting a shared understanding of both needs, constraints and solutions;
* Making sure that decision-making is based on informed choices.
Multidisciplinary teamwork is one of the success criteria in both user-centred approaches and agile methods. It is considered to be essential for agile processes in order to meet project objectives and to ensure stakeholder buy-in to both process and results (Stapleton 1998). It must be stressed that though this article concentrates on the teamwork, other factors such as clear goals, planning, iterative delivery, etc. also play a vital role in the success of agile projects.
In my experience, multidisciplinary teamwork depends on
* Putting together, establishing and sustaining a team;
* Doing all important team-based work in facilitated workshops;
* Visualising and documenting the team’s efforts throughout the process.
Enabling a diverse team to function well
A multidisciplinary team needs to be made up of all the different stakeholders in the process. This includes project sponsors, domain experts, users, designers, developers and architects – just to mention a few. It is important that all the different interests are represented. This can be a difficult job because you can end up with a team that is too unwieldy to manage. So selecting team members can be a painful process.
When building a team, each participant’s potential contribution to the process has to be evaluated. Involving the right stakeholders in the process increases ownership from the users’ and customer side. The difficult part is excluding some of potential participants.
The ideal participant
* is a part of the team and identifies himself/herself with the team’s goals;
* is empowered and entrusted with the task;
* has the support of his/her manager;
* is experienced and knowledgeable in his/her field;
* represents colleagues;
* has the time to participate;
* wants to contribute to the success;
Real-life team participants obviously represent these attributes to a varying degree. The participants from the customer or user groups are often hard to get hold of because they have important responsibilities in the organisation. Quite often some of our team members are picked for us, so we have to work with people who in one way or another represent ‘less’ than the ideal participant.
Since teams don’t function well when decisions have to be made elsewhere, we try to avoid representation through proxy, e.g. the boss sending a secretary or the system architect sending a junior programmer to represent them.
An ideal team includes people from different disciplines with various skills. I don’t split the team into separate user/owner/domain expert teams or designer/developer teams because that often leads to an ‘us & them’ attitude and reduces ownership. In our teams it is always ‘us’. On a recent project, my team consisted of town planners, government and municipal bureaucrats, building contractors, a system architect, web designer and project manager.