Conference PaperPDF Available

Customer Feedback and UCD in Agile Software Development



In this contribution, we address issues relating to the area of tension between User Centered Design (UCD) and agile software development. It reflects on a case study in a Ger-man software development company that focused on how this company integrates customer feedback and UCD into their agile practices. We identified aspects crucial for UCD as in-volved roles, channels & media for customer input as well as the filtering and selection mechanisms regarding this input. Against the background of the study as well as existing work, we then propose some issues, questions and input for discus-sions for the workshop on the integration of UCD and agile development at NordiCHI 2014.
Customer Feedback and UCD in Agile Software
Oliver Stickel, Sebastian Draxler, Gunnar Stevens
University of Siegen
Hoelderlinstr. 3, 57076 Siegen, Germany
oliver.stickel / sebastian.draxler / gunnar.stevens
In this contribution, we address issues relating to the area
of tension between User Centered Design (UCD) and agile
software development. It reflects on a case study in a Ger-
man software development company that focused on how this
company integrates customer feedback and UCD into their
agile practices. We identified aspects crucial for UCD as in-
volved roles, channels & media for customer input as well as
the filtering and selection mechanisms regarding this input.
Against the background of the study as well as existing work,
we then propose some issues, questions and input for discus-
sions for the workshop on the integration of UCD and agile
development at NordiCHI 2014.
Author Keywords
User Integration, Agile, Development Process, Scrum,
Usability, User Experience, Field Study, Qualitative
Research, User Centered Design
ACM Classification Keywords
D.2.9 Software Engineering: Management
Integration of the customer’s wishes, needs, input and feed-
back into software development on a continuous basis is cru-
cial in order to work towards maximizing the usability and
uxer experience (UX) of a software product as emphasized in
ISO 9241-210. Software development itself becomes increas-
ingly more agile which results in the necessity to integrate
agile development methods and UCD in order to achieve an
integrated perspective on design and use [12]. We are cur-
rently working on a research project aimed at helping Small
and Medium sized Enterprises (SMEs) to facilitate this inte-
gration by ways of supportive ICT, best practices and process
Paste the appropriate copyright statement here. ACM now supports three different
copyright statements:
ACM copyright: ACM holds the copyright on the work. This is the historical ap-
License: The author(s) retain copyright, but ACM receives an exclusive publication
Open Access: The author(s) wish to pay for the work to be open access. The addi-
tional fee must be paid to ACM.
This text field is large enough to hold the appropriate release statement assuming it is
single spaced.
model enhancements. To ground our work, we are conduct-
ing empirical research in German SMEs in order to under-
stand practices and challenges relating to customer integra-
tion, UCD and agile software development in situ. At this
point, we have completed our first in-depth case study into an
evolved, successful agile software development project (”Fi-
nanceX”, pseudonymized) of a company at the larger end of
the SME spectrum (”Mavolio corp.”, pseudonymized) with a
focus on UCD.
So far, our results indicate three important aspects related
to customer integration, UCD and agile development: Roles
which concern ones found in traditional agile doctrine but
also have been found to be expanded into other areas in prac-
tice. Channels and Media, i.e. conduits and means for com-
munication with the customer but also internally and the fil-
tering of customer input (i.e. appraising it, analyzing and un-
derstanding it, matching it to internal qualitative or technical
goals and similar challenges). We will structure this position
paper around this case study as well as the related literature.
We will first give a brief overview about the state of the art,
introduce our research methods and stance and subsequently
report on the results before discussing them and elaborating
further on issues, challenges and discussion points relating to
UCD and agile development for the NordiCHI 2014 work-
Agile software development [2] refers to relatively new
paradigms (e.g. Scrum [13] and Kanban [1]) to structure ICT
projects which differ from classical ones (e.g. the waterfall)
models in that they reject the notion of a “heavy”, largely
predefined and pre-planned project layout which is then pro-
cessed step by step. Instead, Agile methods state that during
the course of a software project, there will almost always be
change and propose to prepare for this and embrace it [21].
This results in four central values as codified in the Agile
Manifesto [2]: 1. Individuals and interactions over processes
and tools 2. Working software over comprehensive documen-
tation 3. Customer collaboration over contract negotiation 4.
Responding to change over following a plan.
The agile methodology utilized by the FinanceX team is
Scrum. Scrum can be characterized through “Sprints” which
are relatively short (usually less than four weeks) develop-
ment cycles, during which specific features are implemented
and after which a usable version should be completed. Cru-
cial for Scrum is the rule of 3-3-3-3 which stands for roles in-
ternal, roles external, artifacts and ceremonies (more in [18]).
The current state of user centered design (UCD) as codified in
ISO 9241-210 (more e.g. in [10]) can be seen as a normative
design and development model that argues for user/customer
integration in several phases of the process. The UCD ide-
ology specifically views the user as an asset of the product
development process. Furthermore, it explicitely focuses on
generating a positive user experience. It suggests to include
users in early idea finding phases, to carry out user research
(this covers everything that helps to understand who the users
are, what their system of values and requirements are, etc.),
(optionally include users in mock-up generation or evalua-
tion) and include users in the evaluation of releases. User cen-
tered design was developed to be open enough to be adapted
to existing software engineering approaches, as the specifi-
cation leaves room that has to be filled with interactions be-
tween a design team and an engineering team.
It has to be noted that agile methods already seem to incorpo-
rate some aspects and resemblances to UCD, e.g. the iterative
approaches and the emphasis on the customer [4]. This is also
stated in the Agile Manifesto itself, see [2]. There are mul-
tiple reports on this relation, e.g. a single case study on a
multinational corporation and its shift to agile [7] or [19], a
case report which notes that agility in the development pro-
cess together with adjustments in frequency and reporting of
usability testing activities to match the agile cycles has proven
beneficial for the usability and UX of their products.
However, it has also been noted frequently (e.g. [8, 6, 9])
that the actual integration of both worlds often does not work
as well as it might and is not yet well understood in prac-
tice. Hence, there have been multiple scientific workshops
and tutorials, e.g. [16] and suggestions for procedural mod-
els or frameworks to facilitate the integration, e.g. [14] who
base their framework on an Interaction Design Lifecycle and
specifically input design cycles into the agile process or [3]
who focuses on usability professionals and how to integrate
them in agile environments, not least by facilitating under-
standing for development practices on the UX side of the
team. Scrum roles are also regarded as relevant for the suc-
cessful integration of UCD and agile: Singh [15] identifies
the Project Owner (PO) as the most crucial role for such at-
tempts and states that POs often are overwhelmed since they
have to coordinate so many stakeholders, artifacts and cere-
monies and are frequently not qualified in-depth for usability
and UX which leads to the proposal to appoint two POs, one
of which focuses on a POs more traditional role while the
other ones responsibilities lean towards usability.
Our basic research for this case study was: How does Mavo-
lio integrate customer input and feedback into their agile soft-
ware development process and how does this relate to UCD?
It is important to note that we did not approach the field
with predefined categories of existing development processes
and tools but rather based our modus operandi on Grounded
Theory [17]. Therefore, we took our research question and
No. Role
I01 Product Owner
I02 Social Media Officer
I03 Chief of Support
I04 Customer Lab (2 interviewees)
I05 First Level Support employee
I06 Software Developer
I07 Product Owner, different software
project (contrast)
O01 Observation Scrum sprint planning
O02 Observation of two usability tests
Table 1. Interviews and Observations
quickly went into the field where we iteratively developed
our understanding and research strategy according to our find-
ings. The efforts described in this paper can hence be viewed
as stepping stones towards a more comprehensive theory of
UCD in agile software development processes. We view such
a stance which is driven by the data and the field to be impor-
tant given the disparities between theory and practice and the
ambiguities as described in the state of the art.
For our research, we selected FinanceX, one of multiple soft-
ware projects in development by Mavolio. FinanceX, a per-
sonal finance management system, was chosen because of its
market success, positive customer reviews and its internal fo-
cus on agility as well as user centeredness, usability and UX.
FinanceX also caters to a very broad audience, it is multi-
platform and hence was deemed quite challenging regarding
appropriate customer integration and UCD requirements. Our
reasoning behind choosing such a project was that we ex-
pected to gather broader data, identify more prominent chal-
lenges or breaking points and practices than in a smaller, less
evolved or narrower project.
Three researchers spent a total of about 15 hours in situ,
where we primarily conducted the following research activ-
ities: Seven face to face interviews of between one and two
hours each with key participants in Mavolio’s development
process (see tab. 1). The Project Owner was selected as the
first interviewee through its managing role for the software
project and the interview with him followed only very basic
guidelines. From here on out, the selection of the next in-
terviewees as well as the interview guidelines evolved from
the field. Specific queries to past interviewees if new ques-
tions or talking points arose from the field. Those were done
mostly face-to-face but some via e-mail.We also conducted
observations of two sessions of user tests in Mavolio’s in-
house usability testing laboratory (“CustomerLab”) as well as
a participant observation of a Scrum Sprint planning meeting.
From those activities, we gathered about twelve hours of au-
dio recordings which we transcribed in full, albeit content-
focused, only including breaks, exclamations and similar
meta-information if the corresponding occurrence was very
prominent. We also collected about 12 pages of handwritten
field notes and memos as well as multiple textual and visual
artifacts, e.g. usability testing reports from the CustomerLab
and screen shots from supportive ICT-tools utilized by Mavo-
lio. All data and artifacts were subsequently coded axially
and selectively [17]. The coding process started immediately
after the first interview and was continued and evolved all
throughout the research activities. Once to twice weekly, we
held discussion and mirroring efforts of the coding activities
in our research group. This also included four researchers
which were not active in the field and helped asking ques-
tions towards the data. We also had similar sessions with col-
leagues who were not involved in our research project at all
and provided us with valuable unbiased insights as well as
forced us as immersed researchers to explicate a significant
amount of tacit information. This permanent condensation of
the coding structure was followed up to the point where the
gathered data did not add significant new insight (saturation).
During this process, several categories emerged from the data
on which we will report next.
In this section, we will report on the three most prominent
codes: Roles, Channels & Media and Filtering as well as their
As in established Scrum doctrine, we found the role of the
Project Owner (PO) to be the central hub of the customer
integration and the focus on UCD. However, in the case of
FinanceX and deviating from classical Scrum, we found a
team of three POs who share their responsibilities: PO1 is the
visionary, specifying the “epics” (I01), PO2 has more of an
executive day-to-day role and PO3 leans towards interaction
design. However, all three POs have an eye on the user stories
and discuss them collaboratively, sometimes including other
members of the development team (e.g. for technical exper-
tise). In order for the POs to do their job, they obviously
need to receive customer input. For FinanceX, three roles or
departments are primarily responsible for gathering and pro-
viding this input:
The Support Team (ST), a unified in-house helpdesk. The
ST is organized hierarchically with support employees, team
leaders and one overall chief of support. The ST is in contact
with customers on a daily basis. Over the course of time,
there seem to have emerged experts for specific products or
product aspects within the ST.
The Social Media Officer (SMO) who monitors and engages
in communication relevant to the company on Social Me-
dia.Mavolio has separate Social Media presences for each of
its products as well as one for the company itself.
The Customer Lab (CL): An in-house usability lab which
handles user tests for all of Mavolio’s products on request
of the development teams (usually their heads, in FinanceX’s
case the POs). Tests occur in every stage of the development
and with different focusses (e.g. on the UI, on specific fea-
tures, etc.). Staff members of the CL also take part in Scrum
meetings if the CL is involved at that stage of the project.
Channels and Media
The Product Owners as the central coordinator utilizes a
Microsoft Team Foundation Server (TFS) to manage the Fi-
nanceX project. Entries in the TFS are categorized as Bugs,
Improvement Proposals (self-implemented, smaller quick-fix
alterations) or User Stories and can be prioritized. The TFS is
the PO’s central channel to the developer team. Other chan-
nels include E-Mail, phone and given the moderate size of
Mavolio, a lot of personal contact and office grapevine (ex-
pressly mentioned in almost all interviews). Externally, the
PO team is not in contact with customers on a daily basis,
but there is a dedicated public E-Mail address for FinanceX
which is read by the POs. Notably, there are a few long-time
or very dedicated customers who know the PO’s call-through
or their company E-Mail addresses and contact them directly
if they have suggestions or issues with the product. The POs
also monitor the ratings in the different app stores where Fi-
nanceX is available.
The Support Team offers E-Mail, web-based, chat and
phone support to the customers. Furthermore, there are bul-
letin boards for every product but they are considered as
“users helping users” and only loosely monitored by the ST.
The most important channels by far are considered to be E-
Mail and phone. During support calls or other forms of com-
munication, customers will often make suggestions, report
bugs or give other feedback. Mavolio’s support employees
are also trained to expressly ask for such information. All
customer feedback is recorded in a support database where
related issues are cross-referenced and counted. If issues are
deemed worthy (see “Filtering” for more detail on this pro-
cess), they can be fed into the TFS. The ST can also in some
instances initiate developer activities directly without the de-
tour through the PO, however, this happens only in very spe-
cific routine instances (e.g. if a customer suggests a new bank
should be integrated into the FinanceX app, which is usually a
straightforward and well-established process at Mavolio and
does not need to be wrapped into a User Story).
The Social Media Officer’s most important channels / me-
dia are obviously Facebook and Twitter as well as blogs. She
constantly monitors all platforms, keeping an overview about
what is happening, reading discussions and gathering feed-
back, error reports and suggestions. If discussions run to-
wards unwanted or wrong angles, the SMO also tries to in-
tervene. In case of problems like server outages or similar
issues, the SMO informs the customers over app available
channels and, more importantly, keeps them up to date. In-
ternally, the SMO is in close contact with the Support Team
via phone and E-Mail and sometimes refers customers to the
ST. Similarly to the ST, in some (pre-)defined routine aspects,
the SMO also talks directly to the development team and as-
signs them tasks. However, her central contact are the POs to
whom she relays customer feedback and suggestions, utiliz-
ing E-Mail as the tool of choice, often supplemented through
face to face discussions. Notably, she does not input informa-
tion into the TFS directly.
The Customer Lab primarily utilizes single-user sessions
with 5-20 sessions per test battery for a specific question or
feature, mostly relying on testing the software while Think-
ing Aloud [5] and being recorded with a camera as well as a
screen capturing tool. Sometimes, heuristic evaluations [11]
and cognitive walkthroughs [20] are utilized and currently,
the CL is branching out towards testing and understanding
users in situ at home or in their working environment. Af-
ter each session, smaller reports are created and fed into the
TFS for the POs. After each test battery, a more comprehen-
sive PDF report is created. Notably, it is possible for every-
body in the development team to tune into the live feed from
the usability testing sessions, although it has been expressed
in multiple interviews that developers usually do not do this.
Tests in the CL are only carried out on request of the POs, the
management or other decision making roles.
In the previous sections, we tried to clear up how and with the
participation of which roles customer feedback is gathered
and passed along through the company. There is, however,
one step missing which is what we call filtering. This relates
to the process of analyzing and assessing user feedback as
well as matching it to other feedback or internal goals for the
product. It also encompasses on the challenge of identify-
ing what the user really means or needs. These aspects have
quickly emerged in our interviews as so important that they
deserve deeper analysis.
Mavolio has a long history of experimenting with the incor-
poration of user feedback and UCD in their development cy-
cles and within this history, there have been failures, too.
One example from the interviews (I01, I03, I05) is a former
project where the development of a software product relied
very heavily on the input of a selected group of users which
were considered lead users for the area. However, as it turned
out later, the product became much too specialized and thus
didn’t appeal to many potential customers. Experiences like
this reinforced Mavolio’s focus on filtering as well as spread-
ing out the sources for the input – as outlined in the previous
sections, customer feedback is sampled through a wide range
of channels, representing an attempt to level the playing field
and keep specialization appropriate to the product.
The most important decision makers regarding the filtering
process are obviously the POs. They try to match their vi-
sion of the product with the customer input, adapt, prioritize
and, if deemed necessary, modify or deny specific feedback.
The CL does not filter actively at all, its staff simply aggre-
gates their results and hand them to the POs. The SMO also
does not really filter actively – she does however match ev-
ery incoming input with previous decisions made by the POs
and if the input is identical or very similar, she informs the
customer accordingly (e.g. request denied, request in devel-
opment, etc.) without alerting the POs. If a specific feedback
is new and she hands it over to the POs, she usually annotates
it and states her opinion about it, i.e. gives her input into the
filtering process. Most notably is the ST which does filter ac-
tively. Customer feedback is gathered and discussed between
the leader of the support team and the chief of support and
filtered. Thus, some feedback may never even reach the POs.
Consistently through all interviews, the exact operationaliza-
tion of the filtering process remains somewhat indistinct but
can be categorized broadly into two classes: Qualitative and
Quantitative Filtering. Quantitative filtering concerns the fre-
quency and intensity of a specific type of feedback. Espe-
cially the ST seems to utilize quantitative filtering which is
also easy to do for them since the customer feedback from
each call1is recorded in their database. Quantitative aspects
are, however, no guarantee for the feedback to get imple-
mented – an often cited example (I01, I02, I03, I04, I05) from
our interviews is that of a feature requested by a very large
amount of customers but which would make other features
planned by PO1 for the future of the product technologically
impossible and hence does not get implemented. The other
way around, i.e. individual or occasional cases seem more
straightforward: (Very) specific features which get requested
by very few people usually get filtered out.
Qualitative filtering is a “softer” aspect and seems primarily
associated with experience and routine rather than hard data.
It was hard for all interviewees to explicate techniques and
methods for qualitative filtering. Instead, in nearly every in-
terview, it was stated ex- or implicitly that a lot of know-how
with and a “feeling for” the product has to be developed over
time in order to get it right. A necessity to be a user of the
product oneself has also been mentioned. It seems as if the
SMO leans more towards qualitative filtering than the other
involved roles.
Qualitative and quantitative filtering mechanisms are reported
to compliment each other well and none of them is seen as
sufficient for itself. Especially the POs seem to try and con-
sider and value both aspects.
The involved roles seem exhaustive and complementing each
other. The trinity of POs in FinanceX’s case incidentally mir-
rors impulses found in the literature as mentioned in the state
of the art [15] and it seems that such a division of labor has
merit, especially if a software project gets bigger but also
calls for more coordination and articulation work through the
whole team (e.g. through a Scrum Master). Regarding pos-
sible conflicts between internal product vision of the ”own”
project vs. customer feedback, multiple empowered roles and
slightly different perspectives can help to avoid Group Think
– evidenced in our case study by heated discussions between
PO and SMO. The latter also does not have to focus on ad-
ministrative aspects which also lead to valuable differences
regarding the view of the product. It has to be said that chan-
nels like Social Media can not be the only form of gathering
feedback due to difficulties in sampling and focus. A role
which focuses on more rigorous testing is necessary – per-
sonified by the CL. Closing the circle is the ST which receives
continuous information about breaking points and feeds them
into the agile cycle.
Regarding channels and media: For the POs, a comprehen-
sive project management tool like TFS makes sense and pro-
vides an extensible infrastructure for the whole team. For the
SMO, Facebook and Twitter as the two largest social media
1In the sense of all kinds of communication, not just telephone calls.
are obvious for a mass market product like FinanceX. How-
ever, for other projects, the selection of media might be differ-
ent and include e.g. specialized bulletin boards, depending on
the target audience. The fact that the SMO does not use the
TFS seems counter-productive. The CLs channels and me-
dia are already quite wide (with plans to expand) regarding
their recruiting and testing which makes them a good exam-
ple for other SME interested in incorporating more customer
feedback. Cooperation of the CL with the SMO makes sense
for recruiting test participants as well as exchanging and dis-
cussing impressions. The ST’s tools are fairly straightfor-
ward, and include chat, phone, e-mail, databases, etc. They
seem well thought out and functional. A possible point of
improvement would be the utilization of a customer feedback
tool similarly to [22] directly into the software which could
provide the ST and hence the whole Agile development pro-
cess with valuable in-situ feedback from the users’ usage sit-
The aspect of filtering is one of the most interesting and cru-
cial ones we have encountered, yet it is also the most fuzzy
one by far, making it difficult to really pin down. One les-
son to learn from Mavolio definitely seems to be the neces-
sity for a comprehensive and appropriately widespread net
for gathering input as described and discussed in the previ-
ous sections. This is not filtering yet but necessary grounding
for the filtering process. The next important step is to have
structured role distribution regarding the power of filtering
and decision making. Mavolio has a grown, divergent struc-
ture here: While the POs are clearly the decision makers and
the CL and the SMO only gather, comment and subsequently
forward feedback to the POs, the ST participates in active
As explained in the discussion regarding channels and media,
CL, SMO and ST all have slightly different perspectives on
the customer’s feedback and needs and thus, a similar chain
of forwarding for the ST as it is practice with the CL and
the SMO would seem sensible and pose a possible point of
intervention and improvement in the process. This view is
supplemented through the differing foci regarding filtering
techniques: The SMO leans towards qualitative filtering, be-
ing immersed thoroughly in the product and the population
of its users. The CL seems balanced between qualitative and
quantitative filtering aspects given its scientific methodology.
The ST ostensibly tends towards quantitative filtering which
is only logical given the throughput rate of a support call cen-
ter in comparison to the SMO and the CL. Assuming (as was
stated multiple times in our interviews) that qualitative and
quantitative filtering have to compliment each other, it would
seem sensible to engage in pre-filtering as little as possible,
respectively as little as sensible: Similarly to the SMOs cur-
rent practice, it makes sense to match customer feedback with
previously made decisions and inform customers accordingly
if a (very) similar request has already been denied or is being
processed. To do this, a comprehensive database has to be
kept and be accessible to all concerning roles – ideally, this
would be done in the project management software.
Regarding the operationalization of filtering techniques,
quantitative filtering seems to be the more straightforward
one – given thorough documentation in database form, cus-
tomer feedback can be quantified and analyzed rather easily.
This data can supply valuable intelligence into trends. How-
ever, it seems extremely important to supplement the quanti-
tative view qualitatively: A good idea is not necessarily the
same as an often requested one – valuable ideas and insights
can be rare, too. This makes qualitative filtering a necessity.
To explain its operationalization with an analogy: In our in-
terviews, we found certain similarities between this kind of
filtering and qualitative sciences like ethnography: Deep im-
mersion into and interaction with the product’s user base and
using the product oneself – getting a feel for it and forming ex-
perience – has been stated as very important and later, differ-
ent perspectives and their intersections are considered valu-
able (one could compare this to the concept of inter-coder
reliability in qualitative data analysis). Furthermore, a certain
distance from possible moderating factors (like budget aspecs
or other business influences) seems associated with success-
ful qualitative filtering in a manner not unlike the (artificial)
naive approach utilized by ethnomethodologists. All in all,
both views compliment each other and if possible, none of
them should be viewed on its own when engaging in filtering.
Discussion points and issues
We would like to wrap up our case study with some position
points, theses and impulses for discussions which are based
on the literature and our case study and which we would like
to debate further in the Workshop on the integration of UCD
and agile development:
Customer integration is invaluable for UCD: This is the
most obvious point and well-established in the scientific
community but many SMEs do not seem to accept this yet
which should be discussed further.
Agile development seems useful for UCD: Generally
speaking, agile seems well suited to be mapped to UCD
methods and customer integration through its structure but
has deficits (see below) which need to be reflected in a
process model.
Multi-stage is crucial: Customer integration at only a single
point can falsify the feedback significantly. Those points
should be identified and discussed further.
”Listeners” need to be empowered and actually listened to:
The people gathering user feedback through the different
channels and at multiple stages need to have a voice in
the process, e.g. through explicit participation in the agile
process and need to be able to challenge decision making
Customer feedback needs to be filtered: Not everything a
customer wants can be done or is actually a good idea.
Qualitative and quantitative filtering mechanisms should be
Filtering is not easy: Personal needs to be educated, to ac-
tually use the product and to develop a frame of mind not
unlike that of a qualitative researcher to filter qualitatively.
Quantitative filtering needs support systems like databases
which should be connected to the project management tool.
The Project Owner is the critical point: The PO needs to
make a significant amount of highly UCD motivated de-
cisions which is why she or he needs a grounded (multi-
stage) base and related expertise for those decisions.
Consider two POs: Given the previous point, it may be sen-
sible to apply two POs to cover the necessary skill sets and
balance the workload. If this is done, it is vital to establish
and communicate the different responsibilities of the POs.
1. Anderson, D. J., and Reinertsen, D. G. Kanban:
Successful Evolutionary Change for Your Technology
Business. Blue Hole Press, Sequim, Washington, Apr.
2. Beck, K., Beedle, M., Van Bennekum, A., Cockburn, A.,
Cunningham, W., Fowler, M., Grenning, J., Highsmith,
J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin,
R. C., Mellor, S., Schwaber, K., Sutherland, J., and
Thomas, D. Agile Manifesto, 2001.
3. Beyer, H. User-Centered Agile Methods, 2010.
4. Chamberlain, S., Sharp, H., and Maiden, N. Towards a
Framework for Integrating Agile Development and
User-Centred Design. In Extreme Programming and
Agile Processes in Software Engineering, vol. 4044.
2006, 143–153.
5. Ericsson, K. A., and Simon, H. A. How to study
thinking in everyday life: Contrasting think-aloud
protocols with descriptions and explanations of thinking.
Mind, Culture, and Activity 5, 3 (1998), 178–186.
6. Ferreira, J., Noble, J., and Biddle, R. Agile Development
Iterations and UI Design. AGILE 2007 (AGILE 2007)
7. Isomursu, M., Sirotkin, A., Voltti, P., and Halonen, M.
User Experience Design Goes Agile in Lean
Transformation – A Case Study. 2012 Agile Conference
(2012), 1–10.
8. Lee, J. C. Embracing agile development of usable
software systems. Conference on Human Factors in
Computing Systems (2006).
9. Lievesley, M. a., and Yee, J. S. R. The role of the
interaction designer in an agile software development
process. CHI ’06 extended abstracts on Human factors
in computing systems - CHI EA ’06 (2006), 1025.
10. Mao, J.-Y., Vredenburg, K., Smith, P. W., and Carey, T.
The state of user-centered design practice. Commun.
ACM 48, 3 (Mar. 2005), 105109.
11. Nielsen, J., and Molich, R. Heuristic evaluation of user
interfaces. In Proceedings of the SIGCHI conference on
Human factors in computing systems, ACM (1990),
12. Pipek, V., and Wulf, V. Infrastructuring: Towards an
integrated perspetive on the design and use of
information technology. Journal of the Association of
Information System (JAIS) (2009).
13. Schwaber, K. Scrum development process. In
Proceedings of the 10th Annual ACM Conference on
Object Oriented Programming Systems, Languages, and
Applications (OOPSLA (1995), 117–134.
14. Silva, T., Silveira, M. S., Maurer, F., Hellmann, T.,
Paulo, U. D. S. a., Carlos, C. D. S. a., Carlos, S. a., and
Universidade, P. User Experience Design and Agile
Development : From Theory to Practice. Journal of
Software Engineering and Applications 2012, October
(2012), 743–751.
15. Singh, M. U-SCRUM: An Agile Methodology for
Promoting Usability. Agile 2008 Conference (2008).
16. Steria, J. G. W., and Alsos, O. UX and Agile. Tutorial,
NordiCHI conference 2010 (2010).
17. Strauss, A., and Corbin, J. Basics of Qualitative
Research, vol. 3. 2008.
18. Sutherland, J., Schwaber, K., Scrum, C.-c. O. . C. O.,
and Sutherl, C. J. The scrum papers: Nuts, bolts, and
origins of an agile process.
19. Sy, D. Adapting Usability Investigations for Agile
User-Centered Design. Journal of Usability Studies 2
(2007), 112–132.
20. Wharton, C., Rieman, J., Lewis, C., and Polson, P. The
cognitive walkthrough method: A practitioner’s guide.
In Usability inspection methods, John Wiley & Sons,
Inc. (1994), 105–140.
21. Williams, L., and Cockburn, A. Agile software
development: it’s about feedback and change. Computer
36 (2003).
22. Yetim, F., Draxler, S., Stevens, G., and Wulf, V.
Fostering continuous user participation by embedding a
communication support tool in user interfaces. AIS
Transactions on Human-Computer Interaction 4, 2
(June 2012), 153–168.
... Die Integration der Living Lab Dienstleistungen funktioniert aber nicht bei jedem Entwicklungsprozess gleich gut und hängt auch von der jeweiligen Unternehmenskultur ab. So werden Unternehmen, die nach dem Wasserfall-Modell entwickeln und bei denen eine Technikzentrierte Kultur vorherrscht, nicht in gleicher Weise vom Living Lab Ansatz profitieren, wie ein Design-orientiertes Unternehmen, das bereits nach einem agilen UCD-Prozess entwickelt (Sy, 2007;Stickel et al., 2014 ...
... Die Integration der Living Lab Dienstleistungen funktioniert aber nicht bei jedem Entwicklungsprozess gleich gut und hängt auch von der jeweiligen Unternehmenskultur ab. So werden Unternehmen, die nach dem Wasserfall-Modell entwickeln und bei denen eine Technikzentrierte Kultur vorherrscht, nicht in gleicher Weise vom Living Lab Ansatz profitieren, wie ein Design-orientiertes Unternehmen, das bereits nach einem agilen UCD-Prozess entwickelt (Sy, 2007;Stickel et al., 2014 ...
Conference Paper
Full-text available
Das Konzept des Living Lab ist eine in der Wissenschaft anerkannte Innovations- und Forschungsmethodik. Im betrieblichen Kontext - insbesondere in kleinen und mittleren Unternehmen (KMU) – wird sie bislang jedoch kaum genutzt. Um die Nutzung im kommerziellen Kontext von Smart Home zu erforschen, wird im Forschungsprojekt SmartLive aktuell ein Living Lab zum Thema aufgebaut, bei dem Unternehmen, Forscher sowie ca. 30 teilnehmenden Haushalte die alltägliche Nutzung von kommerziellen, sowie experimentell entwickelten Lösungen untersuchen und neue Interaktionskonzepte gemeinsam erarbeiten. Ferner wurden mit den teilnehmenden Unternehmen Interviews zu deren Entwicklungsprozessen, deren Einstellung zu Usability und User Experience (UUX), sowie den Potenzialen und Möglichkeiten eines Living Labs für KMU geführt. Ziel der Interviews ist es, darauf aufbauend UUX-Dienstleistungen zu identifizieren, die rund um ein kommerziell betriebenes Living Lab angeboten werden können. Hierbei wurde zunächst das Kompetenz-Netzwerk als ein wichtiges Asset eines Living Lab hervorgehoben, da es eine projektförmige Kooperation fördert. Zudem wurde der Bedarf nach flexiblen Dienstleistungen ähnlich einem Baukastensystem deutlich, mit dessen Hilfe relativ kurzfristig als auch nachhaltige innovative Konzepte erprobt, Marketingstrategien entwickelt sowie prototypische Entwicklungen hinsichtlich UUX und technischer Qualität evaluiert werden können.
Full-text available
This book is dedicated to the Godfathers of Scrum, Takeuchi and Nonaka [1], who gave Scrum its name and helped created a global transformation of software development. In 2021 Scrum is used in over 77% of Agile transformations worldwide. Many others have contributed to the creation of Scrum: • Jim Coplien and the ATT Bell Labs Pasteur Project for the paper on the most productive software development team ever documented – the Borland Quattro Pro Project [2]. The first Scrum team implemented the Scrum daily meeting after reading this paper. • Nobel Laureates Muhammad Yunus and the Grameen Bank for originating microenterprise development and the Accion International President’s Advisory Board, responsible for much of microenterprise development in the western hemisphere. As a member of the Accion advisory board, Jeff Sutherland noticed the strategy for bootstrapping the poor out of poverty is a model for freeing hundreds of thousands of software developers from developer abuse caused by poor management practices. • Alan Kay and his team at Xerox Parc [3] for inventing Smalltalk, the mouse, the graphical user interface, the personal computer, the Ethernet, and the laser printer. Listening to his insights on innovation inspired the first Scrum team to go from “good” to “great” [4]. • Professor Rodney Brooks for launching the startup iRobot in space leased from Jeff Sutherland. He taught us the subsumption architecture [5], how to create simple rules to produce highly intelligent performance from complex adaptive systems. • Christopher Langton of Los Alamos Labs and the Sante Fe Institute for coining the term “artificial life” and showing that increasing degrees of freedom up to the edge of chaotic behavior accelerated their evolution [6]. Scrum feels “chaotic” by intent, so as to accelerate software evolution. • The French object-database developers working near the MIT campus at Graphael (later Object Databases, then Matisse Software) for demonstrating first in Lisp and then in C++ the Agile patterns of pair programming, radical refactoring, continuous integration, common ownership of code, world class user interface design, and other tips and tricks which Kent Bent used to create eXtreme Programming a decade later. These were all incorporated into the first Scrum. • The Creative Initiative Foundation for their work with Silicon Valley volunteers to help make the world a better place, the underlying motivation driving the founders of Scrum. This connected the Co-Creators of Scrum with the early systems thinking of MIT Professor Peter Senge who later wrote “The Fifth Discipline.” • Capers Jones and his productivity experts at Software Productivity Research who analyzed and reanalyzed the output of early Scrum teams, as well as many of the software products built with Scrum during 1994-2000 [7]. These analyses allowed us to provide a money back guarantee that users would double productivity during the first month using tools created by the first Scrum. • The first Scrum team – John Scumniotales (Scrum Master), Don Roedner (Product Owner), Jeff McKenna (Senior Consultant), Joe Kinsella (object-relational mapping), Laurel Ginder (QA), and three Danish developers - Grzegorz Ciepiel, Bent Illum, and John Lindgreen. They endured repeated failure, depressing analysis of these failures in front of their technical peers from other companies, and transcendence of their missteps. They were the first Scrum team to achieve the hyperproductive state for which Scrum was designed and their product, Object Studio, is in 2021 still considered one of the top five development tools every created by industry leaders. Little did they know that Scrum would be their greatest contribution, although Object Studio still lives on as a successful product almost 30 years later. • PatientKeeper, Inc., the first company to fully implement an “All at Once” or Type C Scrum involving the entire company in Scrum practice. This innovation in process design has been documented by Mary and Tom Poppendieck in their book on Lean Software Development [8]. “I find that the vast majority of organizations are still trying to do too much stuff, and thus find themselves thrashing. The only organization I know of which has really solved this is Patient Keeper [9].” PatientKeeper was the first company to achieve a hyperproductive revenue state driven by Scrum in 2007. Revenue quadrupled from 13M to 50M in one year. • Jim Johnson, CEO of the Standish Group, continuously shared data on over 500,000 project sets, each with 8-25 projects over the years since Scrum began. These data continually showed that while Agile projects (77% Scrum) were more successful than traditional projects, 58% of Agile projects fail to deliver. The data in the 2018 Chaos Report – Decision Latency Theory: It’s All About the Interval [10] showed clearly that Scrum success was primarily driven by shortening decision time. • Last, but not least, many Scrum practitioners experience the quality without a name (QWAN) - a phrase used by Christopher Alexander in his book “The Timeless Way of Building” [11]. Alexander describes a certain quality that we seek, but which cannot be named. This may be the most important feature of Scrum and can only be spoken of as a set of core values - openness, focus, commitment, courage, and respect. It could be viewed as the “speed of trust” or one of the sources of “ba” often seen on Scrum teams. Ba is the Japanese term for the creative flow of innovation described by Takeuchi and Nonaka [12].
Conference Paper
This paper describes the results of a single-case case study, exploring the role of user experience (UX) work in agile software development. The case study company is a large multinational telecommunication company undergoing a lean transformation process. In this case, lean transformation includes the adoption of agile software development practices. Transformation to agile practices had taken place one year prior to the analysis. The analysis is based on documentation analysis and semi-structured interviews of seven software development professionals. The results show that there were difficulties integrating UX design and software engineering work in an agile and iterative manner. The transition process succeeded in shifting UX and related documentation to a central planning role. The roles of the UX designers in the teams were still under re-definition. There was also a clear need to establish new ways of collaboration between UX professionals and software designers.
The stated, accepted philosophy for systems development is that the development process is a well understood approach that can be planned, estimated, and successfully completed. This has proven incorrect in practice. SCRUM assumes that the systems development process is an unpredictable, complicated process that can only be roughly described as an overall progression. SCRUM defines the systems development process as a loose set of activities that combines known, workable tools and techniques with the best that a development team can devise to build systems. Since these activities are loose, controls to manage the process and inherent risk are used. SCRUM is an enhancement of the commonly used iterative/incremental object-oriented development cycle.
When our company chose to adopt an Agile development process for new products, our User Experience Team took the opportunity to adjust, and consequently improve, our user-centered design (UCD) practices. Our interface design work required data from contextual investigations to guide rapid iterations of prototypes, validated by formative usability testing. This meant that we needed to find a way to conduct usability tests, interviews, and contextual inquiry—both in the lab and the field—within an Agile framework. To achieve this, we adjusted the timing and granularity of these investigations, and the way that we reported our usability findings. This paper describes our main adaptations. We have found that the new Agile UCD methods produce better-designed products than the "waterfall" versions of the same techniques. Agile communication modes have allowed us to narrow the gap between uncovering usability issues and acting on those issues by incorporating changes into the product.