Agile, Multidisciplinary Teamwork

Gautam Ghosh, Userminded, Oslo, Norway

Abstract

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).

The challenge

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.

The process

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.

Keeping the team energised and productive

Teamwork can only be productive if the team members appreciate the goals and strive towards reaching them. So it is important that they actually represent the different aspects of the problem or solution space and are aware of their own role in the team.

• Sponsors are key stakeholders because they represent the visions and can make necessary high level decisions;
• Domain specialists contribute towards the content and process;
• Users can enhance the usability;
• Designers/developers have the needed competence in creating the solution;
• The facilitator is the team's catalyst.

The team must treat people's ideas and concerns as equally important, irrespective of each team member's position or power, or they won't feel motivated to contribute. The team must also have the flexibility to change its course - we easily abandon one idea for another. This enables experimental thinking, but can lead to lower levels of buy-in and commitment.

Facilitated workshops as a teamwork arena

The use of facilitated workshop as an arena to bring together people to work is hardly a secret, but I consider them particularly important in getting a team of people with different skills, experience and aspirations to work together. It is possible to instill a common purpose in the team by keeping all activities related to exploration, creativity and decision making in the workshops.

In a recent project, the teamwork was initiated by facilitating stakeholders to find their way through a maze of requirements, user needs and ideas. Later on, after a short brainstorming session, we used one of the participant's ideas to mould a part of the solution we were working on. This enabled the team to trigger off each other's ideas. But as important it is to generate ideas, it is equally important to enable the team with decision-making (Cohn 2004).

In order to stay agile, the facilitator's task in the workshops is to enable the team to deliver results quickly without rushing. Ensuring that all issues are addressed and that the entire team understands them is important. However everybody doesn't need to understand everything all the time. Very often we can move on when the team feels that some of team members have understood the issue and have taken ownership of it.

One of the ways teams can achieve a shared understanding, come to an agreement and commit to group decisions is by visualising requirements, ideas and decisions in the workshops. This obviously requires focussed management so that the workshops are productive. So we go in for thorough planning and preparation in preshops (pre-workshop meetings) to reduce the risk of failure. In design workshops I make sure that the solution designers have considered several alternatives to the requirements before the workshops, enabling a flexibility and agility in the teamwork.

The success of multidisciplinary teamwork partially depends upon no single team member feeling substantially inferior to any of the others. In my experience, abstract and complex modelling leaves some of the team members out of the picture, so we skip heavy analysis and modelling in workshops. We do use some models sparingly - navigation models and information architecture, sometimes system architecture (occasionally Use Case models). Technical models like class diagrams; ERM models, event handling queues, etc. are never a part of the teamwork - despite the fact that the developers and architects in their own work use them.

Achieving something is important to successful teamwork, so I try to make sure that each workshop has achievable goals. The team has to decide towards the end of each workshop whether we have actually fulfilled the goals we set. This confirmation helps the team evaluate its own progress. Post-workshop documentation of the team's results ensures completeness.

The walls are our tools

Visualising all requirements, ideas and decisions in the workshops is the most important means of creating a shared understanding and commitment.

We 'paint' the walls with ideas and decisions, using a set of lo-tech visualisation tools. All the documentation in our workshops is wall based, so we avoid using a scribe or secretary to take minutes. By visualising requirements on the fly we level the playing field and enable changes as we move on. By writing things up, team members can share their ideas with every other participant. So the wall serves as an archive of ideas and decisions for the team - visible for all.

We keep track of the changes and document results by photographing the walls frequently. The photographs are later used in written documentation.

Our lo-tech visualisation tools include

• Wallware - coloured card in different shapes and colours;
• Flipcharts - for lists and sketches;
• Whiteboards - visualising concepts;
• MUI - Magnetic User Interface;
• Personas - illustrating user characteristics.

We do use some hi-tech tools, namely

• Projection screens - visualising design;
• Cameras - to document everything.

Capturing ideas with Wallware

Wallware comprises of cards in different shapes and colours that are fastened to the wall with blue-tack. In workshops, we use Wallware by noting each idea in large letters on a card using wide-tip pens. These cards are hung up on a wall under appropriate headings (goals, users, benefits, requirements, etc.). At regular intervals, the ideas are sorted and grouped, structuring them as much as possible. When the session is over, the end-result is documented using a digital camera. The content of photographs is used to document the proceedings, decisions and results from workshop.

Figure 1 Wallware

The wall serves as a workspace, thereby ensuring that the ideas are visible to all the participants in the workshop. One portion of the workspace is assigned as a "parking-lot" so that ideas outside of the scope of the process can be effectively parked.

UI - Magnetic User Interface

Instead of using abstract models, our approach has been to visualise solutions using web pages as a metaphor - the solution to every problem is a web page! This visualisation technique is described in detail earlier (Ghosh 1999)

Design-suggestions for each web page are drawn in workshops using MUI elements on the whiteboard. The team modifies each web page making sure that there is agreement about the contents and navigation scheme for each page. Navigational details are noted in the margins outside the MUI page. Finally each page is documented by photographing it with the digital camera.

 

Figure 2 - A typical MUI prototype

The Magnetic User Interface (MUI) toolkit is made up of components that are printed onto a magnetic metal sheet. The toolkit contains a web browser, buttons with predefined texts (OK, Cancel, Print, Save, etc) and screen components like drop-down lists, check boxes and radio-buttons.

The components are to scale and can be used on a 120cmx90cm whiteboard (most whiteboards are larger - thus letting us use superfluous area on the board for comments). By visualising screen components, workshop participants can make realistic decisions about the solution. It is important to encourage and permit the team-members to participate in the design process by letting them move things around if they want to, since this often leads to the revelation of details that might have been otherwise overlooked.

Representing users as personas

Many projects conduct a user analysis resulting in a large set of users and their characteristics. This information is grouped in user profiles and is used to evaluate the validity and need for diverse aspects of the project. Unfortunately many of the user profiles I have seen are often vague, contradictory and very often of little use to the project team.

Alan Cooper (1999) has introduced personas into the design work. Personas are descriptions of imaginary persons that include information about goals, personal relationships, background, work and system related expectations.

Figure 3 - Full-scale personas

Usually we construct 2-3 personas based on a high-level user analysis, using full size laminated photographs of people and writing the persona characteristics on the photographs. This approach lets us add and remove detail as time goes by - the lamination allowing us to wipe away characteristics that need to be amended. The persona photographs are hung on the wall in our project environment and in workshops. This leads the team to believe that they know the personas and as the project progresses, our team members refer to what the personas would say or do in given situations, e.g. "Simon would never bother to fill out any of the optional fields". Above all, the use of personas has helped our teams to focus, eliminating many of the endless discussions of what the "user" would want, expect or need. Our users are few and have names.

Lessons learned

My experience with the agile teamwork approach is that it enhances communication and collaboration between designers, programmers, stakeholders and users. Some of the other observations are:

• Visualisation speeds up the decision making process;
• Wall documentation levels the field;
• It is not always easy to get hold of representative participants;
• The approach ties up team members for days at a time;
• Democratic solutions can be mediocre and contain compromises;
• Using MUI enables team to create realistic interactive solutions;
• Team members become more demanding in the course of the process;
• Clear rules of the game facilitate creativity and decision making;
• The process empowers the participants
• The process results in a shared understanding of problems and solutions.

Some traps and dangers I have experienced using this approach is

• You have to watch out for scope creep, creativity can take off;
• Wallware notations can obscure details, since everything is noted in short sentences;
• It is easy to be sidetracked by unimportant details;
• Strong personalities can side-track the process;
• The team loses faith if the process doesn't lead to results;
• Challenging participants' statements can lead to unwanted uncertainty.

Conclusion

Bringing together people from different environments with diverse goals requires planned facilitation to enable proper teamwork, but the team can work to produce results in an agile manner under the right working conditions. The main components of their success are having the right team members, working in a transparent way in workshops and using lo-tech tools to visualise all ideas and decisions.

References

1. Ghosh, G (1999) Turbo-prototyping: Ultra rapid user centered web development in S. Brewster, A. Cawsey & G. Cockton (Editors): Human-Computer Interaction - INTERACT'99 (Volume II), IFIP press
2. Stapleton, J. (1998) DSDM - Dynamic systems development method - The method in practice. Addison Wesley Longman Limited, Harlow, England
3. Cohn, M (2004) User Stories Applied - For Agile Software Development. Addison Wesley Pearson Education.
4. Cooper, Alan. (1999) The inmates are running the Asylum. SAMS, Indianapolis.

Note

This paper is based on a presentation with the same name - 'Agile Multidisciplinary Teamwork' - presented by the author and Oystein Gutu at the Agile Business Conference 2004 in London on 22.11.04.

© Gautam Gosh 2004

---

More Agile Project Management Articles

User-Centric Design and the Power of Personas

Distributed Teams and Agile

More Agile and Project Management Knowledge

Scrum Expert

---

Back to the archive list

This article was originally published in the Winter 2004 issue of Methods & Tools