Content uploaded by Marco Van Hout
Author content
All content in this area was uploaded by Marco Van Hout on Aug 12, 2015
Content may be subject to copyright.
SCREAM! - AN INTEGRATED APPROACH FOR
MULTIDISICIPLINARY DESIGN TEAMS IN HIGHER EDUCATION
Marco van Hout
1
, Gijs Gootjes
1
1
MediaLAB, Amsterdam University of Applied Sciences, The Netherlands
m.van.hout@hva.nl
g.gootjes@hva.nl
Abstract
This paper introduces an integrated approach for multidisciplinary design teams in educational
settings. The basis of this approach, called SCREAM!, is formed by the design process: Research,
Translate, Create. The agile work frame SCRUM is used to ensure effective work and increase
productivity. However, SCRUM proved not so effective in fostering creativity and applied research.
Three main interventions were introduced to improve this: 1) Ideation as part of the Sprint Planning, 2)
Design Method Toolkit (cards) to plan research and support ideation and 3) Translate sessions half
way each iteration to filter all results and translate. Evaluations of the approach and additional
interventions proved to increase ideation, structure research and improve the translation of research
results into insights for the end solution. Above all, the approach improved team collaboration and the
joy of working in a multidisciplinary team.
Keywords: 21
st
Century Skills, Multidisciplinary, Teams, SCRUM, Design, Applied Research, Design
Methods
1 INTRODUCTION
As a result of the rising complexity of societal problems, industry demands for highly specialized
professionals that have the ability to apply their knowledge in broader contexts and fields, also
referred to as ‘T’ shaped professionals. T-shape type skills [1] (in relation to 21st Century Skills [2])
include collaborative working, creativity, critical thinking and problem solving. These skills go beyond a
single discipline, and could be learned through multidisciplinary team- and project-based education.
Main advantages of multidisciplinary courses are: 1) they model authentic working environments more
closely, and 2) they introduce students to the capabilities and limitations of other disciplines. Main
challenges are: the communication and collaboration amongst team members and the complexity of
decision-making, which affect both team performance and output. Agile work methods such as
SCRUM [3] can be introduced to improve performance, collaboration and decision-making.
Nevertheless, using SCRUM creates tensions between the more rigid ‘getting things done’ mentality
that characterizes this work method and the creativity in the design process that complex challenges
demand.
This paper introduces an approach aiming to foster the main benefits of SCRUM to empower team
members and improve performance, warrant creativity, and highlight (and benefit from) the team's
multidisciplinary character. In this paper, this approach is introduced as the SCREAM! approach
(SCRUM, Creativity, Multidisciplinary) and is reflected on based on performed evaluations.
2 THE SCREAM! APPROACH
In the SCREAM! Approach, multidisciplinary teams follow a structured design process to come up with
a solution for a design challenge in the course of 20 weeks. This type of teams is referred to as
Multidisciplinary Design Teams (MDTs). When working with MDTs, several opportunities (e.g.
knowledge exchange, team learning) and challenges (e.g., improved motivation of team members and
knowledge transfer) arise that will have to be taken into account. Van Hout [4] described ‘ingredients’
of an improved design process that aims at improving motivation and enhances learning and transfer
between the different phases of the design process, for both individual members and the MDTs they
are part of. These ingredients mainly foster: an iterative approach, productivity, planning, decision-
making, creativity, applied research and the self-directing character of the MDT. The main ingredients
of this improved design process form the basis of the approach described in this paper. Below, the key
elements of the SCREAM! Approach are illustrated.
2.1 Multidisciplinary Design Teams
MDTs bring together people with a range of expertise to a (design) project [5]. Multidisciplinary
involves multiple sources of knowledge, skills, and attitudes towards learning and solving problems.
In design education, multidisciplinary team-based working has gained more recognition in recent
years, and so-called lab-based education has increased steadily in the course of the past years. In this
type of education, students are placed in MDTs and have an appointed space within a 'lab' where they
often follow a human-centered design process in order to develop a design solution for a given
problem.
Evers [5] identified various barriers that can prevent MDTs from learning from design, especially when
a specific design methodology such as human-centered design is being followed. Using a design
methodology (and its structure) can be a barrier in itself, but also the level to which an MDT is able to
develop common competencies. The success of the design project depends on the development of
collective design competencies, and therefore, the design methodology used must support teams to
develop these competencies and evolve [1:16]. A lab context seems particularly suitable to support
the development of these team competencies, as it has the space, facilities, and most often the
coaching and management that can relieve the team from a great deal of external 'worries'. This
leaves more room for both individual and team learning in order to optimize the design process for the
team.
Fay et al. [6] illustrate the benefits of multidisciplinarity of a team by stating that it increases the body
of knowledge, skills and opportunities, resulting in higher levels of performance and innovation by
cross-influences between ideas and practice. Individuals within a MDT mostly choose to take the role
that fits their own expertise and discipline. Therefore, if the team manages to foster a shared vision
and common goals, this will benefit the strength of the MDT [7].
Libermann et al. [7] list the key components of a well functioning MDT:
• Shared vision and goals: A unified, often trans disciplinary set of goals or outcomes.
• Integration: Sharing physical space. In a well-integrated MDT, individuals see themselves
primarily as members of this team.
• Frequent interaction: Regular team meetings and other opportunities to exchange information
to promote team building
• Trust & reflection: Good communication norms across disciplines, time and willingness to
reflect back on both success and failures in teams-based care.
• Appropriate structure: Similar reporting structures across disciplines, healthy boundaries
between team members, clear role definition.
• Competent leadership: A leader who can facilitate productive communication
Important challenges within MDTs are communication and collaboration between members of the
team and the complexity of decision-making.
2.1.1 Applied to the SCREAM! Approach
In the SCREAM! Approach, a special focus is on building the team and making sure each team
member has expertise and comes from a discipline that makes sense for the specific project. In the
program there are specific moments in which the team makes decisions together, as a team. In other
moments, team members are actually expected to work autonomous and self-directed. There is a
facilitating leader, making sure all members are able to work properly without problems. If problems do
arise the facilitating leader makes sure they are solved as a team.
To create shared vision and structure, specific sessions and artefacts have been introduced (also see
sections 2.3 - 2.6) to support the team in ideation, planning, and decision-making. The iterative design
process prescribes the most important building blocks and flow of the process to follow.
2.2 Iterative Design Process: Research, Create and Translate
The design process that is followed intends to evoke real curiosity in order to make students feel
highly motivated for finding answers and solutions. This involves many iterations, making, prototyping,
going out on field studies and test each idea, concept or prototype with actual users.
At the start of every design challenge, and after, at the start of each new stage in the design process,
research has a central role. Research provides insights, for example of how people act/think/feel and
who the intended users are, within the context of the challenge. Those insights are the key to a
solution, however they will have to be translated into actual requirements for the design: which
requirements are key for the optimal solution? That is something that can be decided based on
research and be implemented and tested by creating a prototype. A next step could be again to
(research and) test what was created with users.
During the project there is a constant flow, following both directions; from research, translation to
creation, and from creation, translation to research (see figure 1).
Figure 1: SCREAM! Design process with constant flow between Research and Creation
This simplified visualisation and structure of a design process makes it easier for students that do not
have a design background to grasp what they are doing: Do I have a question? (Research), Do I want
to know the impact of my idea? (Create), or What do these insights mean for my end solution?
(Translate). Furthermore, the simplicity enhances the collaboration within the multidisciplinary team
and makes it easier to divide tasks between team members.
Within the SCREAM! Approach this flow is iterated on by the MDTs at least six times, to ensure
optimal output at the end of the project. To structure these iterations and make sure the MDTs get the
most and best possible work done in each iteration, the SCREAM! Approach is supported by using
SCRUM.
2.3 Project Management: SCRUM
SCRUM is a popular approach to getting work done. SCRUM is an agile framework for completing
complex projects. It was originally developed for software development projects, but works well in any
complex problem-solving project [8]. SCRUM involves several rituals [3], such as working in sprints
within fixed iterative cycles (as illustrated in Figure 2). At the end of each sprint, the team discusses
the progress to date, receives feedback from stakeholders and external experts, and if necessary,
makes adjustments to reach their goals. They also reflect on the sprint as a team (team dynamics,
issues, etc., in retrospective). During these sprints, the team has daily 'stand up meetings' where in 15
minutes each team member mentions what they did, what to do and the challenges they encountered.
Each day the team works on getting the list of requirements to research/ design/ Implement/ test
shorter. Progress is measured by finished outcomes.
2.3.1 Basic structure of SCRUM
Sprint
A ‘sprint’ (or iteration) is the basic unit of development. The sprint is a ’timeboxed’ effort; that is, it is
restricted to a specific duration. The sprints can have a duration of one to four weeks.
Rituals
Within the sprints, several rituals make sure the team does not have unnecessary meetings and
moments of discussion. It is all about getting things done and working efficiently in between the rituals.
Daily stand-up meetings
The daily stand-up meeting takes place at the same time and place of every working day. The daily
scrum meeting is held in the morning, for 15 minutes, as it helps set the context for the coming day’s
work. During the daily scrum, each team member answers the following three questions:
a) - What did you do yesterday?
b) - What will you do today?
c) - Are there any impediments in your way?
Sprint planning
The work to be performed in the Sprint is planned at the Sprint Planning. This plan, including a clear
Sprint Goal is created by the collaborative work of the entire team. In the meeting, the team especially
asks the basic questions: 1) What can be delivered in the Increment resulting from the upcoming
Sprint? 2) How will the work needed to deliver the Increment be achieved?
Sprint review
During the Sprint Review, the team and stakeholders collaborate and discuss what was done in the
Sprint. Based on that and any changes to the Product Backlog (see below) during the Sprint,
attendees collaborate on the next things that could be done to optimize value.
Sprint retrospective
The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for
improvements to be enacted during the next Sprint.
Roles
The SCRUM Team consists of a Product Owner, the Team, and a SCRUM Master. SCRUM Teams
are self-organizing. Self-organizing teams choose how best to accomplish their work, rather than
being directed by others outside the team. The Product Owner is the final authority on the
requirements for the product and is responsible for the product vision and improving return on
investment. The SCRUM Master (one of the team members) is responsible for facilitating the team:
creating a trustful and inclusive environment, facilitating team meetings and negotiations with the
product owner, and removing team and organizational impediments.
Artifacts
Product Backlog
The requirements for the product are listed in the Product Backlog, an ever-changing, dynamically
prioritized list of requirements ordered by Business Value. Requirements are broken down into User
Stories.
User Stories
User Stories are short, simple descriptions of a feature told from the perspective of the person who
desires the new capability, usually a user or customer of the system. They typically follow a simple
template: As a <type of user> I want <some goal> so that <some reason>
Sprint Backlog
The Sprint Backlog contains all the committed User Stories for the current Sprint, broken down into
Tasks by the Team. All items on the Sprint Backlog should be developed, tested, documented and
integrated to fulfill the commitment.
Tasks
The goal is to have all tasks fixed for the current sprint without having to add new tasks.
SCRUM Board
The SCRUM Board gives you a quick way of visually seeing the status of your iteration. Add and move
stories into different columns to change their statuses, such as To-do, In progress, Pending approval,
and Done. Every Team member works on tasks and the PO decides when the tasks are moved from
Pending to Done.
2.3.2 Applied to the SCREAM! Approach
SCRUM works very well to tackle the challenges that MDTs face and are mentioned in 2.2; it
structures communication, enforces quick decision-making and gives a visual and detailed overview of
the process and output. One thing that SCRUM is not very suitable for is fostering creativity, which is
one of the 21
st
century skills and part of the T-shaped professional’s skill set. SCRUM can be quite
rigid at times and the ‘getting things done’ mentality may conflict with ideation, reframing insights/
research questions and creative problem solving.
Different approaches to improve both the team’s performance and the output's quality have been
tested in the past 1,5 years. In the improvements of the program, SCRUM promised to provide
structure and the freedom for a multidisciplinary team and its members to direct their own path [4].
sprint
DESIGN METHODS
TOOLKIT
DAILY STAND -UP
MEETINGS
SPRINT
PLANNING
SPRINT
RETROSPECTIVE
IDEATION
RESEARCH
-
CREATE
RESEARCH
-
CREATE
SPRINT
REVIEW
IDEATION
AND
PLANNING
translate
1
2
3
45
Additionally, the sprints and SCRUM rituals can engage members to work more effectively and
transfer knowledge easily between phases.
In response to these performed evaluations, SCRUM was added to improve motivation, learning,
transfer and increase (team and individual) control. An additional evaluation showed that the rigid
structure of SCRUM was affecting the parts of the project that demanded creativity and openness.
Students also found it hard to plan research and translate results into valuable insights (and
requirements) for the solution. In order to resolve these issues, additional, tailored rituals and artifacts
were added to the existing ones in SCRUM, illustrated in Figure 2 and explained in the next
paragraphs. In table 1, instructions for the teams for each event and artifact mentioned in Figure 2 are
illustrated.
Figure 2: SCRUM process adapted for the SCREAM! Approach
Table 1: SCREAM! Sessions and events
1 & 2. Ideation, Sprint Planning, Methods
3. Translate Session
Who: (team + coach)
When: Day 1 - Monday morning (2-4h session)
Prepare session with input from partners
• Ideate on concepts based on previous findings
• Define new sprint goal
• Break down Sprint goal to User Stories (Research
Questions & Design Goals to create)
• Select Research & Design Methods to execute the
User Stories
• Break down user stories to tasks
• Structure & Prioritize tasks on Plan Board
• Confirmation by Coach
Who: (team + coach) + expert
When: Day 8 Wednesday morning (2-4h session)
Prepare session with overview Sprint goal, User Stories
(Research Questions), the used research & design methods
and an overview of the output of the method related tasks.
Share this on the blog
• Share the output of the tasks and the results of the
methods with the experts
• Describe the execution of the methods and write
down/ illustrate output (results)
• The Coach & Expert help the team to translate the
results into insights.
• Use the insights to define as a team new Design
Criteria and Research Questions for the next sprint
4. Sprint Review
5. Sprint Retrospective
Who: (team + coach + partner)
When: Day 15 Friday morning (2h – 4h session)
Prepare Sprint demonstration (2h session)
• Demonstrate the team deliverable
• Gather feedback on the deliverable
• Use the feedback to define as a team new Design
Criteria and Research Questions for the next sprint
Who: (team + coach)
When: Day 15 Friday Afternoon (2h session)
• Evaluate the process, collaboration
• Describe what went good, and what could get
better
• Make a list of things to change
• Decide together how to execute the changed
behavior and process
2.4 Planning and ideation sessions
From the moment the Sprint is being planned, every story, requirement and task is visualised on the
SCRUM-board (see figure 3), which is dynamically managed by the team. The SCRUM part of the
board is similar to that used in the official SCRUM boards, moving stories from To do, In Pogress,
Pending, to Done.
Figure 3: SCRUM board with labels for tasks
In the SCREAM! Approach, every sprint has an ‘ideation and planning’ session. In this session the
creative process is especially triggered by the facilitation of a brainstorm and ideation part in which
ideas are identified and quickly sketched. The most promising ideas are placed in a hierarchy and it is
decided which have potential to be taken along in the sprint. After this, tasks are identified, but more
importantly the exact sprint goal is defined. It is important to have a very clear goal, so that the team
can break the effort down into smaller-sized pieces that contribute to achieving that goal more
effectively, using the SCRUM board.
In this session the Design Method Toolkit (see Figure 4) has a prominent role, as the ideas are being
translated to research questions and in turn translated to possible methods that can be used to
answer them.
2.5 Design Method Toolkit and Plan board
A tailored design method toolkit in combination with a plan board is used to support creative ideation,
research, and testing. The toolkit consists of 60 of the most suitable design and research methods.
With the plan board students are able to plan and break down research (applying the methods) into
specific tasks (see Figure 4).
By introducing both the cards from the toolkit and the plan board, MDTs are more able to plan their
research and be more realistic about them. Perhaps even more importantly, MDTs are triggered and
inspired to apply a larger variety of methods, other than the usual suspects such as an interview,
survey or focus group, enforcing more creativity and richer results from their research.
Figure 4: Design Method Toolkit (cards) and process as depicted on the Plan Board
2.6 Translate sessions
In specific moments in the SCREAM! process, so called translate sessions are introduced (based on
peer-based or researcher/ expert feedback), in which collected research data is presented and
translated into valuable insights to make design decisions. A template is used in this session, asking
the team to write down the user stories, methods and results. This way an overview is made that can
be used to discuss relevance and impact on the end-solution. The translate sessions are one of the
most vital parts of the process, and are organized by the MDT, but attended by external (researchers)
experts to provide a more objective outlook on the results.
2.7 Implementation of the approach
In September 2014, the SCREAM! Approach was first introduced to 4 MDTs. All the abovementioned
elements, events and artifacts were added to the program of 20 weeks. It was the first time that the
educating staff worked with SCRUM and the method toolkit was available in its first beta version.
Based on the positive experience with that edition, in February 2015, the program started again. With
5 different teams using the same elements, events and artifacts. However, this time, the educating
staff (team coaches) had more experience and noticed some parts needed more or less guidance. As
a result, for example, more emphasis was put on the Design Method Toolkit, the Translate Sessions
were better structured and the coaches made sure that the teams did not skip events or sessions that
were vital to the process.
In order to get a better view on the real impact of the approach among the students, an evaluation was
carried out both in 2014 and 2015. This evaluation and its results are explained and compared in the
following sections.
3 EVALUATION
3.1 Method
3.1.1 Participants
46 students were asked to participate in the evaluation of the 20-week program that they were
following in the lab; one group that participated in 2014 (25 students, in 4 different MDTs) and one
group that participated in 2015 (21 students in 5 different MDTs). In the end 14 students participated
from Group 2014 and 18 from Group 2015. The participants had various disciplinary backgrounds,
ranging from research, to design, to engineering, and cultural backgrounds, ranging from The
Netherlands, to Brazil, Italy, India and Japan. Cultural differences were not taken into account in this
particular study.
3.1.2 Apparatus and Procedure
Participants were invited at the end of their projects by email to participate and follow a link to an
online evaluation form, consisting of 50 questions (both open and in 5-point likert-scale form with
answers ranging from 1 totally disagree, to 5 totally agree)), about: general evaluation of the program,
the research in their project, the translation of insights into requirements for their project, their
perception of the quality of output and deliverables, the use of design methods, their experience of
working in a multidisciplinary team, motivation and suggestions for improvement. Students had two
weeks to fill in the questionnaire.
3.2 Results
3.2.1 Multidisciplinary teamwork
Students were asked about how much they enjoyed working in a team (see table 2). Both Group 2014
as Group 2015 highly rated the enjoyment of the teamwork, with a tendency for Group 2015 (M = 4.71,
SD = .469) to enjoy it even more than Group 2014 (M = 4.33, SD = .686), t(30) = 1.77, p = .086.
Table 2: Evaluation of Multidisciplinary Team Working (highest scores)
Variable
Group 2014
Group 2015
M
SD
M
SD
The multidisciplinary background was relevant for our research
3.71
.825
3.78
1.215
The multidisciplinary background was relevant in applying the methods
3.71
.994
3.67
.767
I really enjoyed working in a team
4.33
.686
4.71
.469
The multidisciplinary background was relevant for the success of the team
4.21
.893
3.89
.900
As can be seen in table 1, when asked about the multidisciplinary character of the teams, students
from both groups agreed with the relevance of multidisciplinary work for their research, applying the
various methods and the overall success of the team.
3.2.2 Research and translation
Table 3 shows the highest scoring results for questions concerning research and translation.
When asked about the translate sessions and the process of translating insights, both groups scored
high on the importance and learning of the translate sessions and the application of insights in the
process. Both groups highly rated the importance of the translate sessions (Group 2014, M = 4.57;
Group 2015, M = 4.50) and thought they learned from them (Group 2014, M = 4.21; Group 2015, M =
4.22). There was no significant difference between group scores.
Importantly, students indicated that the research they performed was indeed (translated into
requirements and) used in the design of the solution and the final prototype. Furthermore, they
stressed the relevance and importance of the insights for the design(s).
On the question whether the pace in which they went through their research was too fast, Group 2015
(M = 2.83, SD = .768) reported a higher agreement than Group 2014 (M = 1.86, SD = .864), t(27) =
3.30, p = .003. This could indicate that Group 2015 felt that they went quite fast through the process of
doing their research. However, the score itself still shows a number below the neutral score (3),
indicating that in Group 2015 the general feeling was that they did not go (much) too fast but did so
compared to Group 2014.
What was surprising was the fact that Group 2015 (M = 3.56, SD = .784) showed the tendency to rate
the quality of their research output lower than Group 2014 (M = 4.07, SD = .829), t(30) = 1.80, p =
.082. However, it needs to be mentioned that Group 2015 does not really consider the quality to be
very low, since the mean score falls above the neutral score 3.
In terms of improvements, students indicated (in an open question) that it would be very useful to have
more pre-defined templates to help structure the output and results. This would in turn also improve
the translation part of the research.
Table 3: Evaluation of Research and Translation (highest scores)
Variable
Group 2014
Group 2015
M
SD
M
SD
I found the translation sessions interesting
3.86
1.167
3.94
.539
I think it was important to do the translate sessions as a team
4.57
.646
4.50
.514
I have learned from the translate session
4.21
.699
4.22
.548
I have learned a lot about translating insights into design requirements
3.79
.802
3.78
.732
Insights coming from the research were relevant for the design(s)
4.21
.975
4.06
1.056
I used insights coming from research in the final prototype
4.21
1.188
3.94
1.110
The quality of the deliverables in relation to research was high
4.07
.829
3.56
.784
The pace in which we went through the research was too fast
1.86
.864
2.83
.786
3.2.3 Methods and toolkit
Table 4 shows the highest scoring results for questions concerning the application and evaluation of
methods from the Design Method Toolkit.
Students indicated to have used the methods from the Design Method Toolkit in research and design.
Though not significantly, there was a tendency in the teams in Group 2015 to be more willing to use
the methods from the toolkit than the teams in Group 2014.
Apart from the increase in willingness to use the methods, Group 2015 (M = 3.72, SD = .669)
significantly agreed more with the statement that they learned a lot about applying design methods
compared to Group 2014 (M = 3.00, SD = 1.240), t(30) = 2.11, p = .043.
Also, Group 2015 (M = 3.56, SD = .705) believed to have learned significantly better how to decide
between specific methods for different goals than Group 2014 (M = 2.86, SD = 1.027), t(30) = 2.28, p
= .030.
Almost all students confirmed that methods were used to gain insights on the user, the context and
especially to support ideation.
In response to what could be improved, most important issues that were raised by students included:
1) the amount of cards of the toolkit (60), which was found to be difficult to choose from, 2) the
motivation to use them often had to come from outside instead of it being part of the team culture, and
3) the lack of examples on how to implement methods properly and what the output will look like.
Table 4: Evaluation of Design Methods and Design Method Toolkit (highest scores)
Variable
Group 2014
Group 2015
N
SD
N
SD
I found the available methods interesting
3.64
1.008
4.00
.686
The team was willing to use methods from the toolkit
2.93
.997
3.44
1.097
I have learned a lot about applying design methods
3.00
1.240
3.72
.669
I have learned a lot about how to decide between specific methods for different
goals
2.86
1.027
3.56
.705
Working together with the methods was helpful
3.43
.938
3.78
.808
We have used methods to support ideation
3.93
.917
4.00
.686
We have used methods to gain user insights
3.71
.825
3.83
.985
We have used methods to gain insights on context
3.57
1.089
3.83
.985
3.2.4 Process and support
Table 5 shows the highest scoring items that relate to process and support, mainly about the
application of SCRUM and how the design process was followed.
Both groups indicated that they learned a lot about production and planning in the process, which is an
important factor in properly applying SCRUM. This item was among the highest scoring items,
illustrating that the structured program with an emphasis on tasks, team member responsibilities and
productivity did provide students with concrete tools to plan and perform better. The Design Method
Toolkit was also rated as easy to use in combination with the provided plan board.
Other high scoring items related to the design process of Research, Translate and Create. First of all,
both groups indicated to have learned from applying several design iterations.
To get from Research to specific requirements to Create, both groups indicated to have learned how
to translate the specific insights into design requirements.
To get from Creating a prototype to new research insights, both groups indicated to have learned a lot
about testing actual working prototypes with users.
On top of this, both groups confirmed to have learned a lot about designing and making working
prototypes. This item was among the highest rated items.
Table 5: Evaluation of SCRUM and Design Process
Variable
Group 2014
Group 2015
M
SD
M
SD
It was easy to plan the necessary research by using the method toolkit together
with the plan board
3.29
1.139
3.33
.767
I have learned a lot about planning and production
4.57
.646
4.56
.616
Working with my team was efficient
3.86
1.099
3.67
.907
I have learned a lot about making and designing working prototypes
4.29
.994
4.56
.511
I have learned a lot about (user) testing working prototypes
3.79
1.122
4.28
.669
I have learned a lot about translating insights into design requirements
3.79
.802
3.78
.732
I have learned a lot about design iterations
3.86
.949
4.22
.878
4 CONCLUSIONS & DISCUSSION
In this paper, a new approach and its evaluation were introduced to enhance the work of
multidisciplinary design teams working on projects for a period of 20 weeks. Based on earlier
evaluations, SCRUM was chosen because of its effective work flow and project management
opportunities, together with the positive effects on collaboration, communication and decision-making.
However it was found that SCRUM was not very suitable to ensure a certain degree of creativity in the
project, even though this was one of the main elements that 21
st
century learning would demand.
Therefore three main interventions were introduced to foster the creativity and to improve the level of
applied research: 1) Ideation as part of the Sprint Planning, 2) Design Method Toolkit (cards) to plan
research and support ideation and 3) Translate sessions half way each iteration to filter all results and
translate them into insights for new reframed research questions or new design requirements.
Results of an evaluation with two groups of students (of in total 9 MDTs) showed positive results. First
of all, students enjoyed working in teams, and even more so in the second edition of the program. This
might be a result of increased involvement by coaches and a smoother operation the second time
around. SCRUM proved to increase production and improve planning. Students confirmed they
learned to work more efficient and become more realistic about time and goals. It also made sure
there was less time lost in meetings and decision-making was indeed easier and more efficient.
Ideation during planning was found to be effective and methods were frequently used to support it.
The Design Method Toolkit was highly appreciated, frequently used and both groups indicated to learn
a lot from applying them and seeing the direct impact on the end solution. However, students did find it
hard to choose between methods because of the quantity of methods. Additionally, it was not always
clear how to execute methods and integrate them within SCRUM. This could be solved by improving
the way tasks are described on the cards and adapt it to fit SCRUM better. Also, examples and cases
could be published on a digital version of the Design Method Toolkit to inspire the teams.
The Translate Sessions were evaluated as highly important, useful and valuable for learning how to
get from research output to specific design choices and vice versa. There was indeed a constant flow
between Research and Create and the Translate Sessions did help to remind the MDTs to spend time
on translating their insights into new questions or design requirements. In Group 2015, the research
quality was rated lower in combination with its use for the final prototype. However, this could be a
result of the fact that when they filled in the survey, they still had one full sprint and iteration left.
Overall, the SCREAM! Approach proved to indeed foster creativity better and in combination with the
effectiveness of working with SCRUM increased productivity and improved team collaboration. Applied
research was given a more prominent role in the process with the Design Method Toolkit and both
insights from researching and design/ creation were integrated much better in the final solution. Last,
all students indicated to have enjoyed working in teams and learned a lot from the most important
parts of the program, including Ideation, SCRUM, Design Methods, Research, Translate and Create.
REFERENCES
[1] Barile, S., Franco, G., Nota, G., & Saviano, M. (2012b). Structure and dynamics of a “T-Shaped”
knowledge: From individuals to cooperating communities of practice. Service Science, 4(2),
451-465.
[2] Voogt, J., & Roblin, N. P. (2010). 21st century skills. Discussienota. Zoetermeer: The
Netherlands: Kennisnet.
[3] Schwaber, K. & Beedle, M. (2002). Agile software development with Scrum. Upper Saddle
River, NJ: Prentice Hall.
[4] Van Hout, M. (2014). From Clutter to Butter: Ingredients for Improving Multidisciplinary Team-
Based Design Education in a Lab Context. INTED2014 Proceedings, pp. 4358-4366.
[5] Evers, M. (2004). Learning from Design: facilitating multidisciplinary design teams. Delft:
Eburon.
[6] Fay, D., Borrill, C., Amir, Z., Haward, R., & West, M. A. (2006). Getting the most out of
multidisciplinary teams: A multi-sample study of team innovation in health care. Journal of
Occupational and Organizational Psychology, 79, 553-567.
[7] Liberman, R.P., Hilty, D.M., Drake, R.E., & Tsang, H.W. (2001). Requirements for
multidisciplinary team work in psychiatric rehabilitation. Psychiatric Services, 52, 1331–1342.
[8] Lee, R. C. (2012). The Success Factors of Running Scrum: A Qualitative Perspective, Journal
of Software Engineering and Applications, 5(6), 2012, pp. 367-374.
