Conference PaperPDF Available

Dual-Track Agile in Software Engineering Education

Authors:
  • Carnegie Mellon University, Silicon Valley

Abstract and Figures

The fields of Software Engineering and Human-Computer Interaction have traditionally evolved in parallel, with little cross-pollination, both in industry and academia. However, effectively delivering software products offering superior user experiences requires a tight collaboration between professionals from both fields. In recent years, some approaches combining the two perspectives have been proposed in industry, including dual-track agile software development. Yet, very few courses cover those integrated approaches in academia, and it appears that no publication so far has reported the existence of a scholarly course covering dual-track agile. This paper introduces a course that addresses the divide between Software Engineering and Human-Computer Interaction through an integrated approach to requirements engineering and interaction design, in the context of dual-track agile. The course design combines traditional and flipped-classroom delivery, together with project-based learning. During the course project, students learn to design and implement software systems that address real problems and satisfy real stakeholders' needs by being useful, usable, and enjoyable to use. This paper documents the author's experience designing and teaching the course over the past four years. It aims to convince, inspire, and enable others to teach similar courses, bringing interaction design to the forefront of agile software development.
Content may be subject to copyright.
Dual-Track Agile
in Software Engineering Education
C´
ecile P´
eraire
Carnegie Mellon University (Silicon Valley Campus)
Electrical and Computer Engineering
Moffett Field, CA 94035, USA
Email: cecile.peraire@sv.cmu.edu
Abstract—The fields of Software Engineering and Human-
Computer Interaction have traditionally evolved in parallel, with
little cross-pollination, both in industry and academia. However,
effectively delivering software products offering superior user
experiences requires a tight collaboration between professionals
from both fields. In recent years, some approaches combining the
two perspectives have been proposed in industry, including dual-
track agile software development. Yet, very few courses cover
those integrated approaches in academia, and it appears that
no publication so far has reported the existence of a scholarly
course covering dual-track agile. This paper introduces a course
that addresses the divide between Software Engineering and
Human-Computer Interaction through an integrated approach to
requirements engineering and interaction design, in the context
of dual-track agile. The course design combines traditional and
flipped-classroom delivery, together with project-based learning.
During the course project, students learn to design and imple-
ment software systems that address real problems and satisfy
real stakeholders’ needs by being useful, usable, and enjoyable
to use. This paper documents the author’s experience designing
and teaching the course over the past four years. It aims to
convince, inspire, and enable others to teach similar courses,
bringing interaction design to the forefront of agile software
development.
Index Terms—dual-track agile, continuous product discovery
and delivery, user-centered design, design thinking, requirements
engineering, course design, software engineering education
I. INTRODUCTION
The fields of Software Engineering (SE) and Human-
Computer Interaction (HCI) have traditionally evolved in
parallel, with little cross-pollination, both in industry and
academia [1]. On the one hand, SE is primarily concerned
with building software products effectively, in order to enable
the continuous delivery of useful features to customers. On
the other hand, HCI focuses on designing products offering
quality user experiences, encompassing usefulness,usability,
and emotional impact, in order to fully satisfy the users’ needs
[2]. Therefore, without a tight collaboration between profes-
sionals from both fields, software engineers might deliver
feature-rich products that do not satisfy the needs of the users,
while interaction designers might create excellent designs not
reflected in the actual software product.
As a result, and for decades, users have endured painful
hours behind their personal computers, somehow convinced
that the struggle was a normal part of the user experience
[3]. This perception has started to change, however, through a
series of design innovations that have introduced many users
to superior experiences for the first time, including Apple’s
release of the iPod and iTunes in 2001, and the iPhone in
2007 [4]. Since then, users’ expectations have increased, and
user experience has become a key competitive factor in the
industry.
Responding to market demand, some companies have
started to combine the perspectives of both SE and HCI
communities into integrated software development approaches
[5]. Most of these approaches share similar underlying princi-
ples, including parallel interwoven tracks of interaction design
and software development, as best exemplified by dual-track
agile software development [6]. Unfortunately, the disconnect
between SE and HCI remains prevalent in academia, where
very few courses cover both disciplines in an integrated
fashion. To the best of the author’s knowledge, no publication
has reported the existence of a scholarly course covering dual-
track agile. Furthermore, the way most software engineering
programs teach design may be inadequate [7] because core
design topics are omitted.
This paper introduces a course, called Software Require-
ments and Interaction Design (SRID), that addresses the divide
between SE and HCI by exposing students to an integrated
approach to Requirements Engineering (RE) and Interaction
Design (IxD), in the context of dual-track agile. The dual-track
agile process model proposed in the course is consistent with
the dual-track agile process observed by the author and her
colleagues at Pivotal Software in the context of an extensive
participant-observation study [8]. The course adopts an agile
approach to RE, which embraces changes, and where the term
requirement denotes a property of the solution that is desired
by one or more stakeholders and might end-up being reflected
in the implementation (versus a property that must be reflected
in the implementation).
SRID is a graduate-level course in Carnegie Mellon Uni-
versity’s Master of Science in Software Engineering program
offered on the Silicon Valley campus. Students enter the
course with no experience in interaction design, but have taken
another course of the program [9][10] where they experienced
‘traditional’ agile development.
The course delivery format is based on a mixed approach
combining flipped-classroom delivery [11] and traditional de-
livery in the context of project-based learning [12]. During
the course project, students learn to design and implement
software systems addressing real problems, satisfying real
stakeholders’ needs, and offering superior user experiences.
Students also get a taste of the continuous and concurrent
nature of product discovery and delivery.
This paper documents the author’s experience designing
and teaching the course over the past four years. Section II
documents the state of the art, as it relates to the connection
between SE and HCI, in both industry and academia. Section
III introduces the course’s core process, dual-track agile.
Sections IV and V describe the course design, together with
the challenges involved in teaching such a course. Finally,
Section VI concludes with the paper’s key contributions.
II. STATE OF THE ART
While the SE community has a lot to say about how to build
software products, it generally does not offer much guidance
about determining what to build. The Scrum Guide [13], for
instance, remains silent on the topic. While the Scrum Product
Owner is in charge of deciding what product or feature to
build, there are no Scrum activities to support that decision.
How does the Product Owner go about deciding that a specific
feature needs to be built? “How it is done may vary widely
across organizations, Scrum Teams, and individuals.”[13]. It
is left to each to figure it out.
Similar to Scrum, Extreme Programming [14] does not offer
practices to help the team determine what to build, except
for one advanced practice called Real Customer Involvement
(formally On-Site Customer) where an on-site customer writes
and prioritizes user stories [15]. The goal of this practice is “to
reduce wasted effort by putting people with the needs in direct
contact with the people who can fill these needs”[14]. This
practice effectively supports the goal of building a product
satisfying the real customer needs. However, it falls short of
guiding the customer and team in figuring out what to build.
The same applies to Large-Scale Scrum (LeSS) [16] which
includes Customer-Centric as one of its core principles, with
a goal of ensuring that everyone is connected to and cares
about real customers. This is done by defining the Product
Owner as a connector of customers/users and teams, rather
than an intermediary, and by focusing on feature teams that
are aligned with creating end-to-end customer-centric features.
Feature teams, together with customers and users, refine items
to be ready for future Sprints during the Product Backlog
Refinement, hence freeing time for the Product Owner to focus
on customers. Here as well, the approach falls short of guiding
the Product Owner, feature teams, customers, and users in
determining what to build.
Meanwhile, software requirements engineering tends to
primarily present the definition of a solution as a sequence of
requirements refinement steps. For instance, the requirements
process presented in [17] starts with stakeholders’ needs, from
which to-be features are derived, then high-level requirements,
then detailed requirements elaborated just-in-time (typically
just before implementation). Similarly, in [15], large stories
(or epics) are broken down into smaller stories, which are
then further refined using acceptance tests (typically written
just before implementation based on conversations between
developers and stakeholders). In [18], the author defines a
requirements chain going from business requirements, to user
requirements, to functional requirements. These approaches
mostly ignore, or present as secondary, the creative dimension
of defining what to build.
The HCI community, unlike the traditional SE community,
is fundamentally concerned about the design of user expe-
riences for interactive products, and has proposed various
models aimed at explaining the creative process of determining
what product or feature to build. Examples include the Goal-
Directed Design process [19], the Design Thinking Process
[20], the Double-Diamond Design Process Model [21], and
the Wheel Lifecycle Template [2]. These models are supported
by a rich set of generally accepted user-centered practices
that guide the creative process [22]. Unfortunately, these user-
centered processes and practices have been developed outside
of the SE community, and only few have been incorporated
into popular SE methods. As a result, they are regarded as
unimportant by some in the SE community [1].
The challenges involved in bridging the gap between the SE
community’s focus on how to build and the HCI community’s
focus on what to build are described in [23] together with
some early solutions. In recent years, and as illustrated by a
number of systematic literature reviews [5][24][25], we have
witnessed the emergence of strategies aiming at integrating the
perspectives of the two communities. Out of these strategies,
[5] identifies five fundamental principles underlying a user-
centered agile software development approach: continuous
stakeholder involvement, artifact-mediated communication, it-
erative and incremental design and development, separate
product discovery and product creation, and parallel interwo-
ven tracks of design and development.
The idea of parallel interwoven tracks of design and de-
velopment is what some call dual-track agile [6][26][27].
The term dual-track agile originates from a 2005 paper [28]
presenting an effort to merge agile development and user-
centered design at Alias. This effort is also presented in a
2007 paper [29] describing software development at Autodesk
(formerly Alias). Both papers introduce a software process
based on two tracks: An interaction designer track aiming at
discovering what to build, and a developer track aiming at
building software, with interaction designers staying at least
one cycle ahead of developers.
A similar and recent application of dual-track agile in indus-
try is reported in [8], which presents the results of a grounded
theory study conducted at Pivotal Software. In this context, the
first track typically includes user research, negotiating with
stakeholders, drawing user interface mockups, and writing
user stories. The second track typically involves building,
testing, architecting, refactoring, deploying and maintaining
the product. The two tracks run continuously and in parallel,
and the whole team is involved in both tracks. However,
product designers lead the first track, while engineers lead
the second track. The product backlog, owned by product
managers, serves as a boundary object between the two tracks.
The gap between SE and HCI remains important in
academia, where very few courses cover both disciplines in
an integrated manner. A few notable exceptions are presented
later in this section. Furthermore, the way most software
engineering programs teach design might be inadequate. A
study [7] of the ACM/AIS Model Curricula for Software
Engineering and Information Systems [30][31] reveals that
these model curricula omit core design topics and insuffi-
ciently cover how to generate design candidates. The study
explains that while we teach agile methods, we teach software
evolution (the gradual evolution of a software object through
iterations) but miss the fundamental concept of coevolution.
Coevolution refers to “developing and refining together both
the formulation of a problem and ideas for a solution, with
constant iteration of analysis, synthesis and evaluation pro-
cesses between the two notional design ‘spaces’—problem
space and solution space” [32]. An example of a course
explicitly introducing students to coevolution can be found
in [33]. Finally, while designers embrace divergent thinking in
order to explore alternatives, agile methods follow a path along
a single trajectory. Hence, while “you might get a sub-optimal
design right, you will almost never get the right design” [34].
Divergent thinking and coevolution are the cognitive phe-
nomena underlying design thinking. A few recent attempts at
integrating design thinking in SE education have been reported
in the literature. For instance, in [35], the authors describe their
first experience conducting a design thinking workshop to help
students generate product ideas at the beginning of a course
project, and their decision to incorporate the workshop in
future offerings of the course. A similar experiment is reported
in [36], where graduate students applied the design thinking
process over a two-week period. One of the lessons learned
is that, even though design thinking seems simple at first,
students need more time to assimilate the various techniques
and successfully put them into practice.
A more ambitious experiment is reported in [37], which
describes the authors’ first experience introducing design
thinking in the context of a software engineering capstone
project course. Throughout the semester, students apply var-
ious interaction design practices in the context of a staged
development process (planning, requirements, analysis and
design, testing, maintenance, and deployment). The capstone
course described in [37] shares many similarities with the
course presented in this paper. A key difference, however, is
that our interaction design practices are integrated within an
agile software development process (versus a staged process)
called dual-track agile.
III. A ROAD TO DUAL-TRACK AG IL E
The course presented in this paper starts by introducing
two main characters, Remi, the Requirements Engineer (often
called Product Manager), and Iris, the Interaction Designer, as
well as their backgrounds and traditional ways of working.
Remi, our Requirements Engineer (or Product Manager),
belongs to a software development team and is in charge
of defining and managing software requirements. Iris, our
Interaction Designer, belongs to a user experience team and
is in charge of designing software behavior. While both Remi
and Iris share the same mission, namely, conceiving software
systems addressing real problems and satisfying real user’s
needs, they each have a very different way of fulfilling their
mission.
Indeed, Remi and Iris have very different backgrounds and
perspectives. Remi holds a degree in software engineering,
where the main concern is the development of software
systems. He perceives his domain as a set of complementary
disciplines, including project management, requirements engi-
neering, architecture and (technical) design, implementation,
testing, and quality assurance. Iris holds a degree in Human
Computer Interaction (HCI), where the main concern is the
design of user experiences for interactive computing systems.
She perceives her domain as a combination of form (industrial
and graphic design), content (information architecture), and
behavior (interaction design) [19].
A. A Requirements Engineer’s Perspective
This section describes a hypothetical process that Remi,
our Requirements Engineer (or Product Manager), and his
software development team might follow in order to deliver a
new feature or product. The process is presented from Remi’s
perspective, and illustrated on the left-hand side of Figure 1. It
is inspired by the requirements process presented in [17] and
the agile literature listed in Section II. Despite oversimplifying
reality, the process aims at being reasonably representative of
the way agile teams traditionally go about developing software.
The process activities can be summarized as follows:
Elicit Requirements. Remi starts by assembling the
key stakeholders in a conference room to conduct a
requirements workshop. His goal is to understand their
needs and requests, and to come up with an initial list
of product features and requirements. The marketing
manager might be present and propose some features
based on competitive products. The list is refined through
discussions involving domain experts and potential users.
Envision Requirements. Based on the information pre-
viously gathered, Remi creates or updates, in an ad hoc
manner, a long-term vision for the product to be built, and
a set of features to be potentially implemented during
the next release(s). The features are broken down into
a list of prioritized high-level requirements (e.g., epics).
As needed, Remi researches the competitiveness of the
new product ideas by conducting a competitive analysis,
and a software developer demonstrates their technical
feasibility with a proof of concept.
Elaborate Requirements. Remi starts to elaborate the
epics in priority order. Each epic is broken down into
smaller user stories with acceptance criteria. Remi adds
and prioritizes the user stories into the product backlog.
Since the epics are elaborated just-in-time, Elaborate
Fig. 1: Two distinct perspectives on software product development
Requirements might continue while Build Software is
underway.
Build Software. Remi presents the high-priority stories to
be developed during the coming iteration to the software
developers. Each developer selects one or more stories
at the top of the backlog, and gets to work. Once these
stories are implemented, they are reviewed by Remi and
the rest of the team to verify that the working software
satisfies the acceptance criteria. Potential users and other
stakeholders might be invited to the review, in order to
validate that the team is building the right features or
product, and to discuss the direction of the product.
The product development might continue with one or more
iterations until a set release date. The product development
might end at that point, or move on to the next release cycle.
The scenario above illustrates a tight and effective collab-
oration between Remi and the developers on his team. Remi
is capable of decomposing the envisioned solution into small
cohesive pieces that could be built individually, one after the
other, to implement the solution incrementally. Remi organizes
the work for the developers ahead of time (via the product
backlog), and verifies the work after the fact. This happens
with little documentation and communication overhead.
Because the development process is mostly feature-driven,
the resulting product is likely to be feature-rich. Would these
features satisfy the user needs? Would the product be useful,
usable, and enjoyable to use? Given the potential lack of
user involvement, the answer may be no. Furthermore, Remi
assumes that the stakeholders know, and are able to articulate,
what they want (e.g., features), and that what they want is
indeed what they need. Again, this might not be the case.
Finally, in the scenario above, only one possible solution is
considered, as there are no opportunities to consider alternative
ideas for the solution using divergent thinking. Furthermore,
because the definition of the solution is based mostly on
a sequence of requirements refinement steps, Remi and his
team do not have the opportunity to imagine a solution
through coevolution—the rapid cognitive oscillation between
our understanding of the problem and ideas for the software
product [7].
B. An Interaction Designer’s Perspective
This section describes a hypothetical process that Iris, our
Interaction Designer, and her user experience team might
follow in order to design a new functionality or product. The
process is presented from Iris’ perspective, and illustrated
on the right-hand side of Figure 1. It is inspired by the
Wheel Lifecycle Template [2] and other interaction design
models listed in Section II. Despite oversimplifying reality,
the process aims at being reasonably representative of the
way user experience teams traditionally go about supporting
software product development. The process activities can be
summarized as follows:
Elicit Needs. Iris, with help from other members of her
team, starts by researching the domain within which an
opportunity has been identified. Once they know enough
about the domain, they conduct in-person interviews of
key stakeholders, including contextual inquiries [38] with
potential users. Because their objective is to understand
the stakeholders’ goals and related needs, they purposely
stay away from discussing future features or product.
The team makes sense of the data gathered during the
interviews by performing a contextual analysis (e.g.,
using affinity mapping [39]) leading to an empirical
identification of the stakeholders’ needs.
Generate Design Concepts. Once Iris and her team have
a reasonable understanding of the needs, their objective is
to generate, and experiment with, alternative interaction
design concepts that could satisfy these needs. To do so,
they first brainstorm design ideas, often using sketches to
boost creativity [40]. The team combines and synthesizes
these ideas, and then showcases the best resulting con-
cepts using storyboards [41]. These storyboards illustrate
how personas [42] interact with the software solution to
achieve their goal within the context of use. Finally the
team conducts a few design walkthrough sessions [43]
with potential users. By walking the users through the
frames of the storyboards, they validate and refine their
understanding of both the domain and interaction design
concepts. With these storyboards, Iris and her team “plant
and first nurture the user experience seed” [2].
Prototype Interaction. Iris illustrates the interaction
design concept that resonated the most with users during
the design walkthrough sessions, by creating a low-cost
medium-fidelity prototype simulating the final product.
She then conducts usability testing sessions with a few
users for validation purposes. Cycles of refinement and
validation follow until the feedback becomes inconse-
quential. The validated prototype is then sent to the
software developers.
Software Development Cycle. The software develop-
ment team is now in charge of developing and delivering
a software product based on the prototype. Except for
potential clarification questions from developers on the
prototype, Iris and her team have completed their mission
for this interaction design cycle.
The product development might end at that point, or move on
to the next interaction design cycle.
The scenario above illustrates how Iris and her team are
capable of identifying stakeholder’s needs based on data, and
how they effectively involve the users throughout the design
process to make sure that the solution satisfies their needs.
Iris and her team apply design thinking to generate and
validate alternative design candidates. Using divergent think-
ing during brainstorming sessions, they generate alternative
viable interaction design concepts. Through multiple rounds of
coevolution (e.g., sketching, storyboarding and design walk-
through, prototyping and usability testing), they simultane-
ously refine their understanding of both the problem and the
solution. As a result, their interaction design is likely to be
innovative while satisfying the users needs.
Unfortunately, the scenario also highlights a lack of com-
munication and collaboration between the user experience and
software development teams, and a lack of actionable work
items (e.g., user stories) necessary to guide the software engi-
neers during their implementation of the proposed interaction
design. As a result, it is quite possible that the proposed
interaction design will never be fully (if at all) reflected in
the final product.
C. An Integrated Approach: Dual-Track Agile
This section presents yet another hypothetical scenario
aiming at delivering a new functionality or product. This
time however, Remi, our Requirements Engineer (or Product
Manager), and Iris, our Interaction Designer, are working
together on the same cross-functional team, along with a few
software engineers. The proposed process, illustrated in Figure
2, is not meant to represent any given company’s process.
However, it is consistent with the dual-track agile process
that the author and her colleagues have observed at Pivotal
Software in the context of an extensive participant-observation
Fig. 2: Dual-track agile software development
study [8][44][45][46], and other instances of dual-track agile
presented in the literature, as described in Section II.
The process involves two tracks: Discovery, aiming at
discovering what to build, and Delivery, aiming at delivering
working software. The two tracks run continuously and in
parallel. For instance, at a given time, functionality f1 could
be implemented under Build Software, while the requirements
for functionality f2 are being detailed under Prepare Backlog,
a functionality f3 is being prototyped under Prototype Inter-
action, and the concept for a functionality f4 is being designed
under Generate Conceptual Design. Also, as illustrated in
Figure 2, Delivery is part of Discovery, as one has not
fully discovered what to deliver until the working system is
validated by users.
Despite the fact that each activity has a leader, the whole
team might be involved in all activities to avoid software
development waste [46], including knowledge loss due to
knowledge silos and handoffs.
The process activities can be summarized as follows:
Elicit Needs Led by Iris. Similar to what was described
in Section III-B, through research and analysis, the team
gains an empirical understanding of the stakeholders’
needs.
Generate Design Concepts Led by Iris. Similar to what
was described in Section III-B, through ideation and ex-
perimentation with storyboards and design walkthroughs,
the team generates alternative viable interaction design
concepts that could satisfy the stakeholders’ needs.
Envision Solution Led by Remi. Based on the in-
teraction design concepts that resonated the most with
stakeholders during design walkthroughs, the team cre-
ates or updates a long-term product vision, and a list
of prioritized high-level requirements (e.g., epics). As
needed, Remi demonstrates the competitiveness of the
new product ideas, and a software developer demonstrates
their technical feasibility.
Prototype Interaction Led by Iris. Considering the
highest-priority epic(s), the team continues experiment-
ing by creating and refining a low-cost medium-fidelity
prototype and conducting usability testing sessions until
obtaining a fully validated prototype.
Prepare Backlog Led by Remi. By taking the validated
prototype as a guide, the team breaks down a few high-
priority epics into smaller user stories with acceptance
criteria. Remi adds and prioritizes the user stories into
the product backlog.
Build Software Led by Software Developers. Iris and
Remi present the validated prototype and high-priority
stories to the software developers. Each developer selects
and implements one or more stories located at the top of
the backlog. Iris and Remi are available for clarification
questions, pairing with developers as needed. The team is
experimenting with code. For verification and validation
purposes, and to discuss the direction of the product, the
implemented stories are reviewed by the team, potential
users, and other stakeholders.
While the Delivery track remains fairly constant, the focus
of the Discovery track varies over the life of the product. As
the product matures, the focus shifts away from exploratory
activities, including interviewing and conceptual design, to-
wards prototyping and usability testing. The team also relies
more on analytics from working software. However, when
new opportunities or questions arise, the team might revert
to exploratory activities.
The scenario above illustrates a tight and effective collab-
oration among Iris, Remi, and the developers. By working
together, Iris and Remi are able to combine their respective
strengths and overcome the shortcomings of their traditional
approaches. Each user story presented to the developers sup-
ports an idea for a functionality that is feasible, competitive,
and validated by users. Many broken or less-compelling ideas
have been eliminated along the way. As a result, the team is
capable of delivering innovative products satisfying the users
needs by being useful, usable, and delightful.
Finally, let us note that the above presentation of dual-
track agile is oversimplified and does not do justice to the
messy reality of software product design and development.
An attempt to more effectively convey the disorderliness of
dual-track agile is presented in [8]. However, simplicity comes
handy when it comes to teaching and learning. In the next
section, we show how this simple process has been used to
guide the design of a new course integrating interaction design
into software development.
IV. COURSE DESIGN
The Software Requirements and Interaction Design (SRID)
course was first designed and taught in 2015. It builds on
two different courses previously taught by the author: one
in industry and one in academia. The course is now in its
fourth offering. Its design has evolved over the semesters. This
section presents the course design of the last offering.
A. Learning Objectives
The learning objectives are as follows:
Innovate with a design thinking mindset.
Design software systems addressing real problems, sat-
isfying real stakeholders’ needs, and providing superior
user experiences.
In the context of dual-track agile software development,
apply an integrated approach to RE and IxD.
Understand the continuous and concurrent nature of prod-
uct discovery and delivery.
Plan and conduct effective user research.
Perform competitive analysis.
Apply design-based ideation and validation, including
storyboarding, prototyping, and usability testing.
Communicate the intent and scope of a software system
to all concerned stakeholders.
Collect customers’ information using data analytics.
Define actionable systems’ software requirements so they
could be easily implemented.
Master a requirements management tool.
B. Overall Structure
The course is spread over 15 weeks, with 100-minute class
sessions twice a week. It is designed to require on average
12 weekly hours of student effort, including participation in
class sessions, class preparation, individual assignments, and
team project components. The course outline is summarized in
Table I. Class topics and activities are aligned with the tasks of
a semester-long Innovation project. Each task focuses on one
or more activities of the dual-track agile process presented in
Section III-C. The continuous and concurrent nature of dual-
track agile is illustrated throughout the semester using various
scenarios, and experienced by students in Task 5. In addition,
a guest lecture and a field project are added to bring the real-
world to the classroom and provide an outside perspective.
TABLE I: Course Outline
Weeks Innovation Project Tasks, Class Topics, Activities
1-2 Introduction to RE, IxD, Dual-track Agile;
Dual-track Agile
Activity: Defining innovation projects and teams
3-5 Task 1: Needs Elicitation;
Activity: Conducting interviews;
Activity: Synthesizing research data;
Activity: Modeling personas and domain;
Lab: Requirements management tool
6-7 Task 2: Conceptual Design;
Guest lecture on interaction design in industry;
Design Thinking; Activity: Ideation;
Activity: Storyboarding; Design walkthrough
8-9 Task 3: Solution Envisioning;
Product vision; Lean Startup;
Landing page, concept video, data analytics;
Activity: Conducting use case workshop;
Activity: Conducting competitive analysis
10-11 Task 4: Prototyping & Backlog Preparation;
Rapid Prototyping; Usability testing;
Activity: Medium-fidelity prototyping and user stories
Activity: Planguage; Product backlog
12-15 Task 5: Continuous Product Discovery and Delivery;
Continuous discovery and delivery; Style guide;
Usability evaluation; Lab: Heuristic evaluation;
Final Innovation project presentations;
Field project presentations; Exam
C. Delivery Format
The delivery format is based on a mixed approach that
combines traditional and flipped-classroom delivery in the
context of project-based learning. Project-based learning [12]
organizes learning activities around a project of realistic com-
plexity. While working in teams on project tasks, students
experiment with and reason about the underlying concepts of a
discipline. Potential benefits include active participation in the
learning process, promotion of critical thinking, development
of soft skills, and a taste of real-world projects.
Flipped classroom [11] consists of individual instruction
(typically video lectures) outside the classroom, and inter-
active group learning activities inside the classroom under
the guidance of a faculty mentor. Flipping a project-based
course could amplify its benefits by freeing-up time inside the
classroom to better prepare students for the demands of the
course project. However, because video lectures are initially
long to create, and later on difficult to maintain, they have the
propensity of freezing the course content. Consequently they
tend to be incompatible with fast-evolving course subjects, like
integrating interaction design into agile software development.
To overcome this problem in SRID, video lectures are
replaced with selected readings and other relevant materials. In
addition, a mini-lecture of about 15 to 30 minutes is added at
the beginning of each class. The goal of the mini-lecture is to
assess the students’ understanding of the concepts introduced
in the preassigned readings, by engaging them via questions
and answers, and to clarify, deepen, and complement those
concepts. The remaining of the class session is dedicated to
an in-class activity where students apply the concepts to a toy
example. That way, the course retains the benefits of flipped
classroom without the drawbacks of video lectures. When
time permits, students are encouraged to stay after the in-class
activity to work on their task project under the guidance of
the instructor.
Each project task is designed based on the principle that ef-
fective teaching involves aligning the three major components
of instruction: learning objectives,instructional activities, and
assessments [47]. Learning objectives are shared with students
at the beginning of each task. Assessments are done in-class
and/or via written feedback at the end of each task. As a result,
and as illustrated in Figure 3, students are exposed to concepts
from five different perspectives: (1) readings and other relevant
materials, (2) mini-lecture with discussion, (3) application to
toy example during in-class activity, (4) application to project
task, and (5) task assessment. Each perspective builds on the
previous ones to reinforce the students’ understanding of the
concepts. This reinforcement, without repetition, coupled with
teamwork and targeted feedback, aims at enhancing learning
and preparing students for real-world projects.
D. Innovation Project
During the semester-long Innovation project, the students
envision, prototype, and start implementing an innovative
software system that could make a unique contribution to
society. The system should address a real problem, satisfy real
Fig. 3: Concept reinforcement, without repetition
stakeholders’ needs, and provide a superior user experience.
Stakeholders should remain involved throughout the project.
1) Projects Definition and Team Formation: Students define
and select their own projects. To prepare, each student is asked
to contribute one social challenge that could potentially be
addressed with a software system having a strong user focus,
that students are capable of implementing, and for which they
have access to potential users (ideally in professional settings).
During a class activity, starting with the most interesting
challenges (e.g., about six challenges for a class of 30 stu-
dents), and following the Charette Procedure brainstorming
technique [48], students build on each other’s ideas until they
articulate a set of compelling product opportunities. Here is an
example of opportunity identified by students during the class
activity last semester: “Modern society generates a lot of waste
with a negative impact on our environment. We might be able
to leverage software technology to decrease waste footprint
through increased recycling.Students artifacts presented in
figures 5 and 6 relate to this opportunity.
A project team of four or five students is formed around
each opportunity. Because motivation is a key factor of success
in the course, students are asked to auto-form their team
primarily based on project interest. Interpersonal relationship
certainly plays a role as well for students who already know
each other.
2) Project Tasks: The project tasks are designed based on
the dual-track agile process presented in Section III-C. The
project starts with the Discovery track.
Task 1, Needs Elicitation, is organized around the Elicit
Needs activity presented in Section III-C. Based on their
unique opportunity, each student team researches the
domain, identifies and interviews key stakeholders, and
analyzes the data gathered during the interviews using
affinity mapping, as illustrated in Figure 4, to empirically
identify their own stakeholders’ needs.
Task 2, Conceptual Design, follows the Generate De-
sign Concepts activity presented in Section III-C. Each
student team applies design thinking to generate and
validate alternative interaction design concepts that could
Fig. 4: SRID students performing affinity mapping
satisfy their stakeholders’ unique needs. During ideation
sessions, students are encouraged to think laterally and
outside the box to come-up with a set of creative and
original concepts. Each student individually illustrates
a unique concept using a storyboard, as exemplified in
Figure 5 with an original gamification concept to increase
recycling. The students go back to their stakeholders in
the context of design walkthrough sessions.
Task 3, Solution Envisioning, follows the Envision
Solution activity presented in Section III-C. Based on the
interaction design concepts that resonated the most with
stakeholders during design walkthroughs, each student
team defines a product vision and a set of epics, among
which they identify a Minimum Viable Product (MVP
[49]) to be implemented first. In addition, each team
conducts a competitive analysis to articulate how their
product differentiates itself from the competition. Finally,
each team starts collecting information about prospective
customers using data analytics on a landing page show-
casing their product vision and including a concept video.
Task 4, Prototyping and Backlog Preparation, fol-
lows the Prototype Interaction and Prepare Backlog
activities presented in Section III-C. Each team creates a
wireframe-based click-through prototype for their MVP.
The left-hand side of Figure 6 shows a wireframe of the
prototype produced by the recycling team. The students
go back to their stakeholders in the context of usability
testing sessions until obtaining a validated prototype. Fi-
nally, taking the validated prototype as a guide, the team
breaks down the corresponding epics into smaller user
stories with acceptance criteria, prioritizes the stories, and
adds them to the product backlog.
Task 5, Continuous Product Discovery and Delivery,
allows students to experience the continuous and concur-
rent nature of dual-track agile. They start the Delivery
track by implementing a working web application for
their team’s MVP, while continuing the Discovery track
to discover what to build next and update the product
backlog accordingly. In order to deliver a first valuable
Fig. 5: Storyboard illustrating a recycling gamification concept
product increment, each student selects and implements a
few stories located at the top of the backlog. The applica-
tion should include a fully functional, useful, usable, and
delightful front-end implemented with HTML/CSS/JS.
However, because of time constraints, the back-end might
include hard-coded functionality and data. The right-
hand side of Figure 6 shows a screen of the mobile
application developed by the recycling team. Each team
then checks that the application of another team com-
plies with recognized usability principles via heuristic
evaluation [50]. Students contact their stakeholders for
the last time, sending the link to their application and
asking for feedback. Concurrently, they revisit some
Fig. 6: From prototype to working recycling application
activities performed in previous tasks in order to continue
discovering what to build next and to contribute new user
stories to the product backlog. Finally, each team pitches
and demonstrates its product during a final presentation
to the class.
One notable aspect of the project is the high level of stake-
holder involvement. Each interaction with stakeholders is an
opportunity to pivot the product direction to better satisfy their
needs. Also notable, is the fact that each team goes beyond
creating an interaction design addressing their opportunity by
preparing a backlog for implementation. Furthermore, the team
delivers the first valuable increment of a working application
while getting a taste of the continuous and concurrent nature
of product discovery and delivery.
E. Field Project
The field project aims at bringing the real-world to the
classroom by reporting on the state of RE and IxD at selected
Silicon Valley companies. To that end, each student team is
asked to interview two practitioners working at a same com-
pany and on the same product: one practitioner in charge of
requirements (e.g., Requirements Engineer, Product Manager,
Product Owner, Analyst) and one practitioner in charge of user
experience (e.g., Interaction Designer, Product Designer, User
Experience Designer). Following the interviews, student teams
share their findings with the class, including a comparison of
what they learn in class with what they observed in the field.
Companies that have been investigated during past semesters
include, among others: Amazon, Facebook, Google, Linkedin,
Microsoft, Netflix, Quantcast, and SAP. These investigations
highlight a wide diversity of software development approaches
and maturity. Only a minority of these companies so far have
specifically mentioned dual-track agile as their core software
development process. Overall, the field project provides stu-
dents with a first-hand exposure to practitioners dealing with
RE and IxD, and their perspectives on these domains. It is an
opportunity to improve the students’ interview and communi-
cation skills while enlarging their professional network.
V. CHALLENGES
Overall, the course is well received by students, as illus-
trated by the following quotes taken from the online course
evaluation: “Excellent course with great teaching style com-
bining industry practice with classroom theory.;“The course
is deeply connected with the project, so we can ‘learn by
doing’. Really enjoy it, thank you!”;“Great Course, adds a lot
of value to me as a software engineer.; and “Great course
that demonstrates the importance of working hand in hand
with users to understand their needs. I would recommend this
course to everyone!” However, the course also comes with its
challenges. This section covers past and current challenges,
together with attempts to overcome them.
A. Project Selection
In the context of project-based learning, the success of the
course relies on finding motivating projects that effectively
support the course learning objectives. To reach the SRID
course objectives, students must work on a software system
that has a strong user focus, that they are capable of imple-
menting, and for which they have access to potential users
(ideally in professional settings).
To make sure that these requirements were satisfied, during
the first two offerings of the course, projects were imposed on
students. The theme was emergency response, and each team
had to define a software system for a different type of response
team (e.g., fire, police, dispatch, emergency medical services).
Contact information of stakeholders to interview was provided.
While most students enjoyed working on these projects, some
complained about the lack of flexibility.
Therefore, in subsequent and current semesters, students
are encouraged to define their own projects (see Section
IV-D1). The only recommendation is to identify opportunities
related to problems with important societal impact, with the
hope of raising students’ social and civil awareness. Students
are responsible for identifying and contacting stakeholders to
interview. This approach generates a higher level of student
engagement and motivation. Working on one’s own idea is
exciting. Even though some students are nervous about finding
and contacting stakeholders on their own (with only the help
of a provided recruitment email template), all teams have
managed to do so fairly successfully.
Finally, most teams have proposed project ideas with a goal
of making a unique contribution to society. The domains of
these projects have included education, food waste, home-
lessness, medicine, natural disaster relief, recycling, traffic
congestion, and the elderly.
B. Project Documentation
A course like SRID involves many different interrelated
artifacts, including research artifacts, interaction design arti-
facts, requirements artifacts, and software system artifacts. For
instructors who need to explain what needs to be produced, and
later evaluate these artifacts, the overhead could be significant.
The same goes for students, who need to understand what to
produce, and create and organize these artifacts effectively so
they can be shared across the team and with instructors.
In SRID, the problem was eventually solved by introducing
a requirements management tool called Jama [51]. The tool
serves as a hub for all project artifacts. Its content structure
has been fully customized to perfectly match the structure of
the course project, helping students understand how various
elements fit together. For each project artifact, the tool provides
guidance, examples, and potentially templates to jump-start
its creation. Project artifacts can be accessed from different
perspectives to achieve different goals, including creating,
evolving, versioning, prioritizing, filtering, and sorting projects
artifacts. Discussion threads could be created around individ-
ual artifacts for enhanced collaboration.
Overall, the tool reduces the overhead of structuring the
information, at both project and artifact levels, as well as
the overhead of understanding what content to produce. As
a result, students can focus on content creation instead.
C. Effective Feedback
In the context of project-based learning, the quality of the
work done on one artifact, or during one task, might impact
subsequent artifacts or tasks. Consequently, feedback must be
timely and targeted in order to be effective and guide further
learning. Failing to so do might compromise students’ ability
to succeed.
Here as well, the requirements management tool has helped.
The tool provides instructors with an improved visibility
of the students’ work throughout the project. At any time,
the instructor can assess students’ progress by looking at
deliverables completed or still under construction, including
revision history and attribution to get a sense of who is doing
the work. Instructors can have offline discussions with students
related to any specific section of a deliverable.
At the end of a task, each team packages the task’s
deliverables using the tool’s review mechanism. This allows
instructors to formally evaluate the entire work done during
the task while easily providing targeted feedback. The process
in itself is a learning experience for students, as it mimics
real-world industry reviews.
Overall, the tool improves the instructor’s ability to ef-
fectively collaborate with students outside the classroom, for
both mentoring and evaluation purposes. It also supports the
evaluation of individual contributions in the context of team
projects. A summary of how the tool is leveraged in the context
of SRID is available on the Jama website [52].
As a result of offline feedback via the tool along with
mentoring in the classroom, feedback has always scored high
in the online course evaluation, even with a class of 33
students. Still, providing effective feedback becomes chal-
lenging as class size grows. Evaluating creative and novel
work that is tackling open-ended problems is time consuming.
Furthermore, when left on their own devices, students tend
to revert to old habits, happily preconceiving problems and
solutions, building a product for the first solution that comes to
mind, and avoiding talking to users until the first version of the
product is fully implemented. Preventing that from happening
requires constant attention and guidance. With one instructor
and one teaching assistant, a class size of up to about 20
student is ideal. Above that number, the quality of teaching
and learning might be compromised.
D. Continuous Product Discovery and Delivery
Many RE and IxD practices introduced in the course are
challenging for students, especially when these practices in-
volve collaborating with stakeholders. Learning to apply RE
and IxD practices effectively is time-consuming. As a result,
each practice might be applied only once during the semester,
with little or no time left for implementation. Consequently,
students might be under the impression that the project follows
the waterfall approach.
In SRID this challenge was eventually addressed by framing
the RE and IxD practices within dual-track agile. The introduc-
tion of each task of the Innovation project (see Section IV-D2)
is an opportunity to remind students about the continuous and
concurrent nature of the approach. In Task 5, Continuous
Product Discovery and Delivery, students deliver the first
valuable increment of a working software. To minimize ramp-
up, they leverage the technology and development practices
learned during a previous course of the program (Foundations
of Software Engineering [9], which focuses on ‘traditional’
agile development and continuous delivery). Concurrently,
they briefly reapply some RE and IxD practices to continue
discovering what to build.
This strategy provides students with a taste of dual-track
agile and helps them understand the continuous and concurrent
nature of product discovery and delivery, while still allocating
enough time to properly learn the challenging RE and IxD
practices. Ideally, however, a course like SRID should be
followed by another course (e.g., practicum, capstone) where
students can apply their newly acquired knowledge to drive the
continuous and concurrent discovery and delivery of a series
of valuable product increments throughout the semester, and
hence fully experience dual-track agile.
VI. CONCLUSION
This paper presents a novel course integrating interaction
design into software development. It documents the author’s
experience designing and teaching the course over the past
four years. The paper makes the following contributions:
It documents the disconnect between the SE community’s
focus on how to build and the HCI community’s focus
on what to build, in both industry and academia.
It analyzes the strengths and weaknesses of ‘traditional’
agile software development.
It describes how user experience teams traditionally go
about supporting software development, together with the
strengths and weaknesses of their approach. Among the
strengths, it emphasizes divergent thinking and coevolu-
tion, and their fundamental role in the design process.
It describes dual-track agile using a novel process model,
and shows how dual-track agile combines the respec-
tive strengths of traditional agile and user experience
approaches while overcoming their shortcomings.
It reveals the design of a course that uniquely integrates
interaction design and requirements engineering in the
context of dual-track agile, and teaches students to design
and implement software systems addressing real prob-
lems, satisfying real stakeholders’ needs, and offering
superior user experiences.
It presents a rarely documented delivery format based on
a mixed approach combining flipped-classroom and tra-
ditional delivery in the context of project-based learning.
It shares the challenges involved in teaching the course.
These contributions are important for software engineering
educators in higher-education settings because, despite the
emergence of dual-track agile in industry, it appears that no
publication so far has reported the existence of such a course
in academia. We hope that the paper will convince, inspire,
and enable others to teach similar courses, hence bringing user
experience to the forefront of agile software development.
REFERENCES
[1] A. Seffah and E. Metzker, “The obstacles and myths of usability and
software engineering,” Communications of the ACM, vol. 47, no. 12, pp.
71–76, Dec. 2004.
[2] R. Hartson and P. Pyla, The UX Book: Process and Guidelines for
Ensuring a Quality User Experience, 1st ed. San Francisco, CA, USA:
Morgan Kaufmann Publishers Inc., 2012.
[3] A. Cooper et al.,The inmates are running the asylum: Why high-
tech products drive us crazy and how to restore the sanity. Sams
Indianapolis, 2004.
[4] R. Hinman, The mobile frontier: a guide for designing mobile experi-
ences. Rosenfeld Media, 2012.
[5] M. Brhel, H. Meth, A. Maedche, and K. Werder, “Exploring principles of
user-centered agile software development: A literature review, systematic
review paper,Information and Software Technology, vol. 61, no. C, pp.
163–181, May 2015.
[6] K. Albrecht. (2015) Dual track agile: Focusing on cus-
tomer value. [Online]. Available: https://medium.com/kevin-on-code/
dual-track- agile-focusing- on-customer-value-a2e39312585b
[7] P. Ralph, “Improving coverage of design in information systems ed-
ucation,” in Proceedings of the 2012 International Conference on
Information Systems, 2012.
[8] T. Sedano, P. Ralph, and C. P´
eraire, “The product backlog,” Accepted at
the 41th International Conference on Software Engineering, ICSE’19,
2019.
[9] H. Erdogmus and C. P´
eraire, “Flipping a graduate-level software engi-
neering foundations course,” in Proceedings of the 39th International
Conference on Software Engineering: Software Engineering and Edu-
cation Track, ser. ICSE-SEET ’17. Piscataway, NJ, USA: IEEE Press,
2017, pp. 23–32.
[10] H. Erdogmus, S. Gadgil, and C. P´
eraire, “Introducing low-stakes just-in-
time assessments to a flipped software engineering course,” in Proceed-
ings of the 52nd Hawaii International Conference on System Sciences,
2019.
[11] M. J. Lage, G. J. Platt, and M. Treglia, “Inverting the classroom: A
gateway to creating an inclusive learning environment,” The Journal of
Economic Education, vol. 31, no. 1, pp. 30–43, 2000.
[12] H. A. Hadim and S. K. Esche, “Enhancing the engineering curriculum
through project-based learning,” in Frontiers in education, 2002. FIE
2002. 32nd Annual, vol. 2. IEEE, 2002, pp. F3F–F3F.
[13] K. Schwaber and J. Sutherland. (2015) Scrum guide. [Online].
Available: http://www.scrumguides.org/
[14] K. Beck and C. Andres, Extreme Programming Explained: Embrace
Change (2nd Edition). Addison-Wesley Professional, 2004.
[15] M. Cohn, User stories applied: For agile software development.
Addison-Wesley Professional, 2004.
[16] C. Larman and B. Vodde, Large-scale scrum: More with LeSS. Addison-
Wesley Professional, 2016.
[17] D. Leffingwell, Scaling software agility: best practices for large enter-
prises, Chapter 17: Lean Requirements at Scale: Vision, Roadmap, and
Just-in-Tine Elaboration. Pearson Education, 2007.
[18] K. Wiegers and J. Beatty, Software requirements, Third Edition. Pearson
Education, 2013.
[19] A. Cooper, R. Reimann, D. Cronin, and C. Noessel, About Face : The
Essentials of Interaction Design. Somerset: John Wiley amp; Sons,
Incorporated, 2014.
[20] H. Plattner, “An introduction to design thinking, process
guide,” Institute of design at Stanford. [Online]. Avail-
able: https://dschool-old.stanford.edu/sandbox/groups/designresources/
wiki/36873/attachments/74b3d/ModeGuideBOOTCAMP2010L.pdf
[21] D. Council, “The design process: What is the double diamond?”
[Online]. Available: https://www.designcouncil.org.uk/news-opinion/
design-process- what-double- diamond
[22] B. Martin and B. Hanington, Universal Methods of Design: 100 Ways
to Research Complex Problems, Develop Innovative Ideas, and Design
Effective Solutions. Rockport Publishers, 2012.
[23] A. Seffah, J. Gulliksen, and M. C. Desmarais, Human-centered software
engineering-integrating usability in the software development lifecycle.
Springer Science & Business Media, 2005, vol. 8.
[24] D. Salah, R. F. Paige, and P. Cairns, “A systematic literature review
for agile development processes and user centred design integration,
in Proceedings of the 18th International Conference on Evaluation and
Assessment in Software Engineering, ser. EASE ’14. New York, NY,
USA: ACM, 2014, pp. 5:1–5:10.
[25] C. Salvador, A. Nakasone, and J. A. Pow-Sang, “A systematic review
of usability techniques in agile methodologies,” in Proceedings of the
7th Euro American Conference on Telematics and Information Systems,
ser. EATIS ’14. New York, NY, USA: ACM, 2014, pp. 17:1–17:6.
[26] J. De Litchenberg. (2017) Dual-track agile: Why messy leads to
innovation. [Online]. Available: https://www.mindtheproduct.com/2017/
04/dual-track- agile-messy- leads-innovation/
[27] J. Patton. (2017) Dual track development is not duel track. [Online].
Available: https://jpattonassociates.com/dual-track- development/
[28] L. Miller, “Case study of customer input for a successful product,” in
Proceedings of Agile 2005. IEEE, 2005, pp. 225–234.
[29] D. Sy, “Adapting usability investigations for agile user-centered design,”
J. Usability Studies, vol. 2, no. 3, pp. 112–132, May 2007.
[30] R. J. LeBlanc, A. Sobel, J. L. Diaz-Herrera, T. B. Hilburn et al.,Software
Engineering 2004: Curriculum Guidelines for Undergraduate Degree
Programs in Software Engineering. IEEE Computer Society, 2006.
[31] H. Topi, J. S. Valacich, R. T. Wright, K. Kaiser, J. F. Nunamaker Jr,
J. C. Sipior, and G.-J. de Vreede, “Is 2010: Curriculum guidelines for
undergraduate degree programs in information systems,Communica-
tions of the Association for Information Systems, vol. 26, no. 1, p. 18,
2010.
[32] K. Dorst and N. Cross, “Creativity in the design process: co-evolution
of problem–solution,” Design studies, vol. 22, no. 5, pp. 425–437, 2001.
[33] P. Ralph, “Re-imagining a course in software project management,” in
Proceedings of the 40th International Conference on Software Engineer-
ing: Software Engineering Education and Training. ACM, 2018, pp.
116–125.
[34] B. Buxton. (2007) Sketching and experience design. Stanford
University Human-Computer Interaction Seminar. [Online]. Available:
https://www.youtube.com/watch?v=xx1WveKV7aE
[35] Y. D. Pham, D. Fucci, and W. Maalej, “A first implementation of a design
thinking workshop during a mobile app development course project,” in
Proceedings of the 2nd International Workshop on Software Engineering
Education for Millennials. ACM, 2018, pp. 56–63.
[36] N. M. C. Valentim, W. Silva, and T. Conte, “The students’ perspectives
on applying design thinking for the design of mobile applications,” in
Proceedings of the 39th International Conference on Software Engineer-
ing: Software Engineering and Education Track. IEEE Press, 2017, pp.
77–86.
[37] M. Palacin-Silva, J. Khakurel, A. Happonen, T. Hynninen, and J. Porras,
“Infusing design thinking into a software engineering capstone course,”
in Software Engineering Education and Training (CSEE&T), 2017 IEEE
30th Conference on. IEEE, 2017, pp. 212–221.
[38] D. Ogle. (2009) Contextual inquiry. [Online]. Available: https:
//wiki.fluidproject.org/display/fluid/Contextual+Inquiry
[39] (2012) The affinity diagram tool. Six Sigma Daily. [Online]. Available:
http://www.sixsigmadaily.com/the- affinity-diagram- tool/
[40] B. Buxton, Sketching user experiences: getting the design right and the
right design. Morgan Kaufmann, 2010.
[41] S. Greenberg, S. Carpendale, N. Marquardt, and B. Buxton, “The
narrative storyboard: telling a story about use and context over time,
interactions, vol. 19, no. 1, pp. 64–69, 2012.
[42] L. Caballero, A. M. Moreno, and A. Seffah, “Persona as a tool to in-
volving human in agile methods: contributions from hci and marketing,
in International Conference on Human-Centred Software Engineering.
Springer, 2014, pp. 283–290.
[43] R. Bias, “Interface-walkthroughs: efficient collaborative testing,IEEE
Software, vol. 8, no. 5, pp. 94–95, 1991.
[44] T. Sedano, P. Ralph, and C. P´
eraire, “Sustainable software development
through overlapping pair rotation,” in Proceedings of the International
Symposium on Empirical Software Engineering and Measurement Inter-
national Conference on Software Engineering, ser. ESEM, 2016.
[45] ——, “Practice and perception of team code ownership,” in Proceedings
of the 20th International Conference on Evaluation and Assessment in
Software Engineering, ser. EASE. ACM, 2016.
[46] ——, “Software development waste,” in Proceedings of the 2017 Inter-
national Conference on Software Engineering, ser. ICSE ’17. IEEE,
2017.
[47] Teaching principles. Eberly Center for Teaching Excellence and
Educational Innovation, Carnegie Mellon University. [Online].
Available: https://www.cmu.edu/teaching/principles/teaching.html
[48] R. Elmansy. Brainstorming multiple ideas using charette
procedure. [Online]. Available: https://www.designorate.com/
brainstorming-using- charette-procedure/
[49] E. Ries, The lean startup: How today’s entrepreneurs use continuous
innovation to create radically successful businesses. Crown Books,
2011.
[50] J. Nielsen and R. Molich, “Heuristic evaluation of user interfaces,” in
Proceedings of the SIGCHI conference on Human factors in computing
systems. ACM, 1990, pp. 249–256.
[51] Jama software. [Online]. Available: https://www.jamasoftware.com
[52] M. Wigen Kernan. Foundations for modern requirements management.
Jama Software. [Online]. Available: https://www.jamasoftware.com/
blog/modern-requirements- management-at- cmu/
... From an academic point of view, little is known so far about this integration [6]. On one hand, even though Agile practices are extensively covered by academic courses, very few SE programs include usability [5] and, when they do, core UXD principles and practices are not always properly addressed [6][7][8][9]. ...
... From an academic point of view, little is known so far about this integration [6]. On one hand, even though Agile practices are extensively covered by academic courses, very few SE programs include usability [5] and, when they do, core UXD principles and practices are not always properly addressed [6][7][8][9]. On the other hand, very few publications have, to the best of our knowledge, specifically reported academic courses that cover the integration of Agile and UX. ...
... However, to the best of our knowledge, there are only two studies that discuss the integration of Agile and UX from a training perspective. Péraire [6] presents a Carnegie Mellon University graduate-level course that focuses on integrating interaction design and requirements engineering in the context of dual-track agile, following a mixed approach combining flipped-classroom and traditional delivery. She shares her experience in designing and teaching the course over a four-year period (2015-2019) and discusses the challenges involved in teaching such a course. ...
Preprint
Full-text available
The integration of Agile development and user experience (UX) has received significant attention over the past decade. The literature contains several process models and wide-ranging discussion about the benefits and challenges of this integration. However, academia has given this integration short shrift. In fact, there are very few publications covering educational courses dealing with Agile development and UX. In this paper, we report on our experience of designing and running a graduate software engineering course that covers the integration of Lean UX into Scrum and employs gamification to improve student engagement. We identified six lessons learned that new point to important aspects to be considered when integrating Agile development and UX in academia. For example, we discuss the complexity of managing Lean UX activities in short sprints or how the design of a testable and tactical hypothesis can be one of the most challenging aspects of the Lean UX process.
... This method provided an opportunity to practice SE principles and concepts in broad complex project contexts. In [33], the course delivery format is based on a blended approach (named dual-track agile), combining flipped and traditional classes in a project-based learning context. Dual-track agile approach combines the traditional agility strengths and user experience approaches. ...
... Eleven papers did not specify any content consumption tool. Looking into the other half of the reviewed papers, we found a list of tools used for content consumption: Adobe Connect Pro for in-class assessment (the assessment is performed through with tool polls that cover the assigned materials) [9]; iTunes music software system as a podcasting client (or a non-podcasting client) [12]; Online Git service for programming activities [9,15,19,41]; A proprietary tool was described by [33]; YouTube (browser or app) for video consumption [1, 6, 10, 16-20, 24, 34, 41]; and Google Classroom as a consumer environment [10,23]. In [18], the students freely chose their method for consuming the lecture material. ...
... Project-based learning [10] Cognitive work Problem-based learning [18] Hands-on activities Project-based learning [36] Hackathon, simulate software project Self-direct learning [33] Challenges, task project Project-based learning [29] Exercises, short case studies, group discussions ...
... There are several reports on teaching software engineering classes with real external stakeholders such as in [2]. Also, Péraire [3] reported on a dual track version of a software engineering course addressing the divide between software engineering and human-computer interaction through an integrated approach to requirements engineering and interaction design. Again, students had available real external stakeholders to communicate with as in a typical industry driven software engineering capstone course. ...
... Table III contains the nine-week schedule for the courses. Week 10 was used for exams and reports and did not contain any new material 3 . ...
Conference Paper
Full-text available
In this paper we discuss a Software Engineering Without Programming course we taught in the Winter 2020 quarter at Cal Poly, San Luis Obispo. We designed this course to target students outside of computing majors, and taught it with the purpose of getting them familiarized with the software development process. To provide software development support, we taught this course in concert with a traditional Software Engineering I course for Software Engineering majors. In this paper we concentrate on reporting our experiences related specifically to the teaching early stages of software development: development of software product vision, and requirements gathering. We discuss the topics covered in the course, the activities students participated in and the artifacts they created. Additionally, we report the results of two surveys (one conducted before the course started, and one conducted during Week 8 of the course) detailing student attitudes towards software development and the course material.
... Despite that, they wasted some time at the end of the summer when they did not get to implement a feature that they carefully planned of time. In [24], the aim was to collaborate user experience and development teams in a cross-functional way. The process consists of two tracks: Discovery and Delivery. ...
Preprint
Full-text available
The integration of Agile development with User Experience (UX) and with User-Centered Design (UCD) grabs IT companies' attention and has become one of the most significant topics in the last few years. In agile UX/UCD processes, the software development process is positively impacted. This systematic review of the challenges of integrating Agile with UX/UCD is provided here to assist other researchers in identifying the recent major challenges associated with Agile and UX/UCD. In addition, this review covers articles available in five research databases. Based on the search strategy, 73 studies were identified relevant to the scope from 2001 to 2021. The findings of this review provide insight into the research area of Agile UX/UCD and also offer future research directions. INDEX TERMS agile software development, user centered design, systematic review, agile user center design integration, agile user center design challenges
... In six articles, above-mentioned EL types occurred in combination: (1) industry/community research project and role-play (Robinson and Hall, 2018), (2) flipped classroom, applied research project, guest speakers, and field project (Péraire, 2019), (3) industry/community research project and interactive workshops , (4) applied research project, industry/community research project, and design hackathon (Hardy et al., 2018), (5) applied research project and industry/community research project (Mohan et al., 2012), and (6) internships, guest speakers, and interactive workshop . ...
Article
Full-text available
Experiential learning is an effective method to teach User Experience (UX) to Human-Computer Interaction (HCI) students. Despite its popularity, there seems to be no comprehensive overview on (1) the current use of experiential learning in UX education at universities and (2) student learning outcomes and benefits resulting from the use of experiential learning. Hence, we conducted a scoping review to provide such overview. We analyzed 45 articles published from 2000 to 2021 and we found 12 types of experiential learning employed by HCI educators: applied research project, industry/community research project, hands-on activity, role-play, interactive workshops, guest speakers, in-house work placement, internship, flipped classroom, field project, lab, and design hackathon, from most to least frequent. Twenty-six articles reported student learning outcomes and benefits: (1) enhanced UX technical knowledge, (2) applied textbook knowledge into practice, (3) acquired soft skills, (4) student satisfaction, (5) increased awareness of user diversity, and (6) increased job marketability. Overall, we advance current HCI teaching practices by providing HCI educators with a list of experiential learning types that they can adopt in their classes to teach UX.
Article
Software companies have been using Design Thinking (DT) as a user-centered design approach, putting the user at the center of the software development process. In this article, we report a Systematic Mapping Study to investigate the use of DT in software development. We evaluated 127 papers from 2010 to 2021. We analyzed how DT is integrated in software development, what are the models and techniques, what are the criteria used for selecting DT techniques, and what are the key points that DT practitioners should be aware of when using DT. As a result, we identified 3 strategies to integrate DT in software development, 16 models, and 85 techniques. We also found that the selection of techniques is related to the models’ working spaces being performed, and identified 7 criteria used for selecting DT techniques. Furthermore, we summarized 16 key points that DT practitioners should pay attention when using DT, and we proposed 4 takeaways for applying DT in software development Thus, our study contributes to DT practitioners by providing information to be used either as a starting point, or to integrate it into activities already performed by teams, or as a strategy to foster changes in the entire organization’s mindset.
Article
Contribution: This article presents a research for enhancing the computer science students' perception on the software project management subject. The main objective of this article is double. The first one is to redesign the current course by including new teaching and new learning methods that encourage students to learn the project management competences and skills. The second one is to analyze the satisfaction of the students regarding the new software project management course. The design of the new course has been based on the improvement proposals from the students, which were collected throughout a grounded theory (GT) study during two academic years. Background: Students must be motivated with both the technical and other transversal competencies provided by the different subjects in the computer science curricula. It is not easy to teach a management subject because students do not clearly find the relationship with their studies. However, it is widely accepted that computer science students need to be trained in project management to be able to work at full capacity in the industry. There is not much literature on how to increase the motivation of students in management subjects. Research Question: Which are the causes and consequences of a low level of interest for software project management in computer science studies? Methodology: Two different experiments were carried out. The first one consisted of determining, during two academic years, the main reasons why computer science students do not get to comprehend the need for such this subject in the curricula. From the GT results, a set of innovative actions were introduced in order to redesign the subject. In the second experiment, during the following two academic years, the satisfaction of the students regarding the changes introduced in the course was analyzed. Findings: The first finding was obtained from the GT study conducted. Four causes influencing students to do not give enough importance to software project management, two consequences derived from these causes and three contingencies to potentially mitigate the consequences were identified. The second finding was the corroboration that the new course design contributes to student motivation and engagement. Through the evaluation of the new course, students can better understand project management techniques and their application to projects. Data collected show that students are aware of the importance of these skills and competencies for their background and professional profile.
Conference Paper
Full-text available
Context: One of the most common artifacts in contemporary software projects is a product backlog comprising user stories, bugs, chores or other work items. However, little research has investigated how the backlog is generated or the precise role it plays in a project. Objective: The purpose of this paper is to determine what is a product backlog, what is its role, and how does it emerge? Method: Following Constructivist Grounded Theory, we conducted a two-year, five-month participant-observation study of eight software development projects at Pivotal, a large, international software company. We interviewed 56 software engineers, product designers, and product managers. We conducted a survey of 27 product designers. We alternated between analysis and theoretical sampling until achieving theoretical saturation. Results: We observed 13 practices and 6 obstacles related to product backlog generation. Limitations: Grounded Theory does not support statistical generalization. While the proposed theory of product backlogs appears widely applicable, organizations with different software development cultures may use different practices. Conclusion: The product backlog is simultaneously a model of work to be done and a boundary object that helps bridge the gap between the processes of generating user stories and realizing them in working code. It emerges from sensemaking (the team making sense of the project context) and coevolution (a cognitive process where the team simultaneously refines its understanding of the problematic context and fledgling solution concepts). Index Terms—Product backlog, dual-track agile, scrum, lean, extreme programming, user stories, design thinking, user-centered design, feature engineering
Conference Paper
Full-text available
It is now common for software engineering programs to include some project management education, typically in the nal year of the undergraduate program, or at the postgraduate level. Such courses are challenging for several reasons: faculty are unfamiliar with management education and literature; the software project management literature is dominated by nonempirical, atheoretical, unscientiic practitioner recommendations; common software engineering pedagogical approaches are inappropriate for teaching management; and many students seem unwilling or unable to take the course seriously (that is, by attending all classes and completing all assigned readings, activities and projects). This paper describes a postgraduate management course in software engineering, which was iteratively reened over seven years to address all of these problems. Its key features include: 1) scholarly, evidence-based readings; 2) quizzes on readings at the beginning of every class; 3) Brief, slide-free lectures; 4) copious in-class activities formalized into a gradeable workbook; 5) an ambitious, multistage project combining novel research, collaborative data collection and literature reviewing, peer review workshops and individual deliverables. The course embodies both research-led teaching and substantial, novel class-based research.
Conference Paper
Full-text available
Software engineering (SE) educators are challenged to balance the scope and depth in their courses to train students in skills which will fulfill the ever-evolving industry needs. Capstone courses are a tool for educators to transfer hands-on experience into practical knowledge and skills of SE students. This paper describes the design of a Casptone course, at Lappeenranta University of Technology. The designed course is human-centric SE capstone, infusing design thinking methods and agile practices into the project life-cycle knowhow. The capstone was offered in spring of 2017 as a 16-week course for 29 students. Design thinking was effective to perform requirement elicitation, software design and testing. Also, the applied approach allowed students to be self-directed which increased their motivation, as a result there was 0% dropout rate. Design thinking is a powerful mean of problem solving and effectively supports SE education in bringing a more hands-on and minds-on, problem-based curriculum.
Conference Paper
Full-text available
Design Thinking (DT) is relevant for companies committed to developing a more creative and innovative application. DT provides a human-centered view of technological artifact design. Therefore, it is important to learn DT in Computer Science and Software Engineering courses as an analytic and creative process, in order to better prepare students for the software development industry. We conducted an empirical study with 17 postgraduate students in the context of mobile applications design. We used coding procedures from the Grounded Theory method for analyzing the obtained qualitative data. Based on the results, we identified some difficulties that participants experienced in using different DT techniques. The results of this study can help teachers understand the difficulties faced by students in learning DT and, consequently, help them to look for new teaching strategies for their classes. Moreover, these results can contribute to the software industry showing the competitive advantages of using DT in the design of the applications under development, especially in mobile applications.
Conference Paper
Full-text available
Creating a graduate-level software engineering breadth course is challenging. The scope is wide. Students prefer hands-on work over theory. Industry increasingly values soft skills. Changing software technology requires the syllabus to be technology-agnostic, yet abstracting away technology compromises realism. Instructors must balance scope with depth of learning. At Carnegie Mellon University, we designed a flipped-classroom course that tackles these tradeoffs. The course has been offered since Fall 2014 in the Silicon Valley campus. In this paper, we describe the course's key features and summarize our experiences and lessons learned while designing, teaching, and maintaining it. We found that the pure flipped-classroom format was not optimal in ensuring sufficient transfer of knowledge, especially in remote settings. We initially underestimated teaching assistantship resources. We gradually complemented video lectures and hands-on live sessions with additional live components: easily replaceable recitations that focus on current technology and mini lectures that address application of theory and common wisdom. We also provided the students with more opportunities to share their successes and experiments with their peers. We achieved scalability by increasing the number of teaching assistants, paying attention to teaching assistant recruitment, and fostering a culture of mentoring among the teaching team.
Conference Paper
Full-text available
Context: Since software development is a complex socio-technical activity that involves coordinating different disciplines and skill sets, it provides ample opportunities for waste to emerge. Waste is any activity that produces no value for the customer or user. Objective: The purpose of this paper is to identify and describe different types of waste in software development. Method: Following Constructivist Grounded Theory, we conducted a two-year five-month participant-observation study of eight software development projects at Pivotal, a software development consultancy. We also interviewed 33 software engineers, interaction designers, and product managers, and analyzed one year of retrospection topics. We iterated between analysis and theoretical sampling until achieving theoretical saturation. Results: This paper introduces the first empirical waste taxonomy. It identifies nine wastes and explores their causes, underlying tensions, and overall relationship to the waste taxonomy found in Lean Software Development. Limitations: Grounded Theory does not support statistical generalization. While the proposed taxonomy appears widely applicable, organizations with different software development cultures may experience different waste types. Conclusion: Software development projects manifest nine types of waste: building the wrong feature or product, mismanaging the backlog, rework, unnecessarily complex solutions, extraneous cognitive load, psychological distress, waiting/multitasking, knowledge loss, and ineffective communication.
Conference Paper
Full-text available
Context: Conventional wisdom says that team disruptions (like team churn) should be avoided. However, we have observed software development projects that succeed despite high disruption. Objective: The purpose of this paper is to understand how to develop software effectively, even in the face of team disruption. Method: We followed Constructivist Grounded Theory. The primary researcher conducted participant-observation of several projects at Pivotal (a software development company), and interviewed 21 software engineers, interaction designers, and product managers. The researcher iteratively sampled and analyzed the collected data until achieving theoretical saturation. Results: This paper introduces a descriptive theory of Sustainable Software Development. The theory encompasses principles, policies, and practices aiming at removing knowledge silos and improving code quality (including discoverability and readability), hence leading to development sustainability. Limitations: While the results are highly relevant to the observed projects at Pivotal, the outcomes may not be transferable to other software development organizations with different software development cultures. Conclusion: The theory refines and extends the understanding of Extreme Programming by adding a few principles, policies, and practices (like the unique Overlapping Pair Rotation practice) and aligning these principles, policies, and practices towards the business goal of sustainability.
Conference Paper
Full-text available
Context: Team code ownership is a software development practice where any team member can modify any part of the team’s code. However, many factors beyond official policy affect a developer’s sense of ownership. Objective: The purpose of this paper is to understand the factors that affect a team’s sense of code ownership. Method: Following Constructivist Grounded Theory, the first author conducted participant-observation of several software development projects, and interviewed 21 software engineers, interaction designers, and product managers. Iterating between theoretical sampling and analysis continued until achieving theoretical saturation. Results: Team code ownership is a feeling. Developers feel team code ownership more when they understand the system context, have contributed to the code in question, perceive code quality as high, believe the product will satisfy the user needs, and perceive high team cohesion. Limitations: Outcomes of grounded theory research are not statistically generalizable to defined populations, and may not apply to organizations with different software development cultures. Conclusion: Team code ownership is rooted in numerous cognitive, emotional, contextual and technical factors and cannot be achieved simply by policy.
Conference Paper
Millennials prefer learning-by-doing and social learning, and project-based learning. At the same time, software engineering educators should take into account that software development projects require not only technical skills but also creativity---Design Thinking can help in achieving the latter. We conducted a workshop, following the Design Thinking approach of the d.school, to help students generate ideas for a mobile app development project course. In addition to the details for implementing the workshop, we report our observations and lessons learned. Moreover, we provide suggestions for further implementation of Design Thinking in similar courses.