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.