Agile Processes In Software Engineering And

Extreme Programming 18th International

Conference Xp 2017 Cologne Germany May 2226 2017
Proceedings 1st Edition Hubert Baumeister
download
https://ebookbell.com/product/agile-processes-in-software-
engineering-and-extreme-programming-18th-international-
conference-xp-2017-cologne-germany-may-2226-2017-proceedings-1st-
edition-hubert-baumeister-5884266

Explore and download more ebooks at ebookbell.com

Here are some recommended products that we believe you will be
interested in. You can click the link to download.

Agile Processes In Software Engineering And Extreme Programming 12th

International Conference Xp 2011 Madrid Spain May 1013 2011
Proceedings 1st Edition Ilenia Fronza

https://ebookbell.com/product/agile-processes-in-software-engineering-
and-extreme-programming-12th-international-conference-xp-2011-madrid-
spain-may-1013-2011-proceedings-1st-edition-ilenia-fronza-2226412

Agile Processes In Software Engineering And Extreme Programming 14th

International Conference Xp 2013 Vienna Austria June 37 2013
Proceedings 1st Edition Jeffry S Babb

https://ebookbell.com/product/agile-processes-in-software-engineering-
and-extreme-programming-14th-international-conference-xp-2013-vienna-
austria-june-37-2013-proceedings-1st-edition-jeffry-s-babb-4242186

Agile Processes In Software Engineering And Extreme Programming 13th

International Conference Xp 2012 Malm Sweden May 2125 2012 Proceedings
1st Edition Normand Sguin

https://ebookbell.com/product/agile-processes-in-software-engineering-
and-extreme-programming-13th-international-conference-xp-2012-malm-
sweden-may-2125-2012-proceedings-1st-edition-normand-sguin-4522554

Agile Processes In Software Engineering And Extreme Programming 15th

International Conference Xp 2014 Rome Italy May 2630 2014 Proceedings
1st Edition Giovanni Cantone

https://ebookbell.com/product/agile-processes-in-software-engineering-
and-extreme-programming-15th-international-conference-xp-2014-rome-
italy-may-2630-2014-proceedings-1st-edition-giovanni-cantone-4931014
Agile Processes In Software Engineering And Extreme Programming 10th
International Conference Xp 2009 Pula Sardinia Italy May 2529 2009
Proceedings Notes In Business Information Processing 1st Edition Pekka
Abrahamsson
https://ebookbell.com/product/agile-processes-in-software-engineering-
and-extreme-programming-10th-international-conference-xp-2009-pula-
sardinia-italy-may-2529-2009-proceedings-notes-in-business-
information-processing-1st-edition-pekka-abrahamsson-1223940

Agile Processes In Software Engineering And Extreme Programming 11th

International Conference Xp 2010 Trondheim Norway June 14 2010
Proceedings Lecture Notes In Business Information Processing 48 1st
Edition Alberto Sillitti
https://ebookbell.com/product/agile-processes-in-software-engineering-
and-extreme-programming-11th-international-conference-
xp-2010-trondheim-norway-june-14-2010-proceedings-lecture-notes-in-
business-information-processing-48-1st-edition-alberto-
sillitti-1658030

Agile Processes In Software Engineering And Extreme Programming 16th

International Conference Xp 2015 Helsinki Finland May 2529 2015
Proceedings 1st Edition Casper Lassenius

https://ebookbell.com/product/agile-processes-in-software-engineering-
and-extreme-programming-16th-international-conference-
xp-2015-helsinki-finland-may-2529-2015-proceedings-1st-edition-casper-
lassenius-5141414

Agile Processes In Software Engineering And Extreme Programming 17th

International Conference Xp 2016 Edinburgh Uk May 2427 2016
Proceedings 1st Edition Helen Sharp

https://ebookbell.com/product/agile-processes-in-software-engineering-
and-extreme-programming-17th-international-conference-
xp-2016-edinburgh-uk-may-2427-2016-proceedings-1st-edition-helen-
sharp-5484778

Agile Processes In Software Engineering And Extreme Programming

Workshops Xp 2021 Workshops Virtual Event June 1418 2021 Revised
Selected Papers 1st Edition Peggy Gregory

https://ebookbell.com/product/agile-processes-in-software-engineering-
and-extreme-programming-workshops-xp-2021-workshops-virtual-event-
june-1418-2021-revised-selected-papers-1st-edition-peggy-
gregory-51706176
 Hubert Baumeister
Horst Lichter
Matthias Riebisch (Eds.)

Agile Processes
LNBIP 283

in Software Engineering
and Extreme Programming
18th International Conference, XP 2017
Cologne, Germany, May 22–26, 2017
Proceedings
Lecture Notes
in Business Information Processing 283

Series Editors
Wil M.P. van der Aalst
Eindhoven Technical University, Eindhoven, The Netherlands
John Mylopoulos
University of Trento, Trento, Italy
Michael Rosemann
Queensland University of Technology, Brisbane, QLD, Australia
Michael J. Shaw
University of Illinois, Urbana-Champaign, IL, USA
Clemens Szyperski
Microsoft Research, Redmond, WA, USA
More information about this series at http://www.springer.com/series/7911
Hubert Baumeister Horst Lichter
•

Matthias Riebisch (Eds.)

Agile Processes
in Software Engineering
and Extreme Programming
18th International Conference, XP 2017
Cologne, Germany, May 22–26, 2017
Proceedings
Editors
Hubert Baumeister Matthias Riebisch
Technical University of Denmark University of Hamburg
Kongens Lyngby Hamburg
Denmark Germany
Horst Lichter
RWTH Aachen University
Aachen
Germany

ISSN 1865-1348 ISSN 1865-1356 (electronic)

Lecture Notes in Business Information Processing
ISBN 978-3-319-57632-9 ISBN 978-3-319-57633-6 (eBook)
DOI 10.1007/978-3-319-57633-6

Library of Congress Control Number: 2017937714

© The Editor(s) (if applicable) and The Author(s) 2017. This book is an open access publication.
Open Access This book is licensed under the terms of the Creative Commons Attribution 4.0 International
License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution
and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and
the source, provide a link to the Creative Commons license and indicate if changes were made.
The images or other third party material in this book are included in the book's Creative Commons license,
unless indicated otherwise in a credit line to the material. If material is not included in the book's Creative
Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use,
you will need to obtain permission directly from the copyright holder.
The use of general descriptive names, registered names, trademarks, service marks, etc. in this publication
does not imply, even in the absence of a specific statement, that such names are exempt from the relevant
protective laws and regulations and therefore free for general use.
The publisher, the authors and the editors are safe to assume that the advice and information in this book are
believed to be true and accurate at the date of publication. Neither the publisher nor the authors or the editors
give a warranty, express or implied, with respect to the material contained herein or for any errors or
omissions that may have been made. The publisher remains neutral with regard to jurisdictional claims in
published maps and institutional affiliations.

Printed on acid-free paper

This Springer imprint is published by Springer Nature

The registered company is Springer International Publishing AG
The registered company address is: Gewerbestrasse 11, 6330 Cham, Switzerland
 Preface

The 18th XP conference was held 2017 in the wonderful city of Cologne, Germany.
In the spirit of past XP conferences, XP 2017 was a place where researchers and
practitioners met to exchange new ideas and present their work. These proceedings
contain the full research papers, short research papers, and doctoral symposium papers
presented at the conference.
In all, 46 research papers were submitted (39 full and seven short papers). All
submitted papers went through a thorough review process, with each paper receiving at
least three reviews. Finally, the Program Committee accepted 14 papers as full research
papers (an acceptance rate of 35%). Moreover, six papers — submitted as short or full
research papers — were accepted as short research papers. The selected papers cover a
wide range of agile techniques and approaches. Many of them present results of
empirical studies aiming to systematically evaluate successful agile practices, others are
technology studies that are relevant to both researchers and practitioners.
In the tradition of former XP conferences, the XP 2017 conference program offered
many different session topics. Besides the scientific program, i.e., the research track,
doctoral symposium, and scientific workshops, the conference featured an industry and
practice track, experience reports, and Open Space sessions. Materials from all of these
sessions are available on the conference website at www.xp2017.org.
Moreover, three keynotes were given by highly renowned speakers. Andrea Goulet
from Corgibytes presented a talk on “Makers and Menders: Putting the Right Devel-
opers on the Right Projects” focusing on a group of developers called “menders” –
people who love taking an existing project and making it better over time. In his
keynote “End-to-End Agility at GitHub” Alain Hélaïli talked about the organization
and the efficient workflows at GitHub. Finally, Claes Wohlin from Blekinge Institute of
Technology answered the question “Evidence-Driven Change in Software Develop-
ment: Is It Feasible?”
Many people contributed to the success of the XP 2017 conference. We would like
to thank everyone, especially the authors and presenters of all papers, the Program
Committee members, the volunteers, and sponsors. Furthermore, we want to express
our gratitude to the XP 2017 organizers; they did a great job.

March 2017 Hubert Baumeister

Horst Lichter
Matthias Riebisch
 Organization

Organizing Committee
General Chair
Jutta Eckstein IT communication, Germany

Conference Chairs
Marc Clemens codecentric AG, Germany
Nils Wloka codecentric AG, Germany

Academic Program Committee

Academic Program Chairs
Hubert Baumeister Technical University of Denmark
Horst Lichter RWTH Aachen University, Germany
Matthias Riebisch University of Hamburg, Germany

Scientific Workshops
Roberto Tonelli University of Cagliari, Italy

Poster Chair
Ademar Aguiar University of Porto, Portugal

PhD Symposium Chair

Stefan Wagner University of Stuttgart, Germany

Industrial Program Committee

Tutorials/Workshops
Nancy Van Lean-Agile Partners, USA
Schooenderwoert

Working Software
Aslak Hellesøy Cucumber, UK

Individuals and Interaction

Diana Larsen FutureWorks Consulting, USA
VIII Organization

Customer Collaboration
Ken Power Cisco Systems, Ireland

Responding to Change
Jan Coupette codecentric AG, Germany

Experience Reports
Rebecca Wirfs-Brock Wirfs-Brock Associates, USA
Avraham Poupko Cisco Systems, Israel

Open Space
Alexander Kylburg Paragraph Eins, Germany

Program Committee (Research Papers)

Ademar Aguiar University of Porto, Portugal
Mikio Aoyama Nanzan University, Japan
Leonor Barroca The Open University, UK
Hubert Baumeister Technical University of Denmark, Denmark
Jan Bosch Chalmers University of Technology, Sweden
Steve Counsell Brunel University, UK
Torgeir Dingsøyr SINTEF, Norway
Christof Ebert Vector Consulting Services, Germany
Hakan Erdogmus Carnegie Mellon University, USA
Juan Garbajosa Technical University of Madrid, Spain
Alfredo Goldman University of São Paulo, Brazil
Des Greer Queen’s University Belfast, UK
Peggy Gregory University of Central Lancashire, UK
Rashina Hoda The University of Auckland, New Zealand
Helena Holmström Olsson Malmö University, Sweden
Casper Lassenius MIT, USA
Horst Lichter RWTH Aachen University, Germany
Lech Madeyski Wroclaw University of Science and Technology, Poland
Michele Marchesi University of Cagliari, Italy
Sabrina Marczak Pontifícia Universidade Católica do Rio Grande do Sul,
Brazil
Tommi Mikkonen University of Helsinki, Finland
Alok Mishra Atilim University, Turkey
Nils Brede Moe SINTEF, Norway
Juergen Muench Reutlingen University and University of Helsinki,
Germany/Finland
Sridhar Nerur University of Texas at Arlington, USA
Maria Paasivaara Helsinki University of Technology, Finland
Kai Petersen Blekinge Institute of Technology/Ericsson AB, Sweden
 Organization IX

Matthias Riebisch University of Hamburg, Germany

Pilar Rodríquez University of Oulu, Finland
Knut H. Rolland Westerdals Oslo School of Arts, Communication
and Technology, Norway
Bernhard Rumpe RWTH Aachen University, Germany
Kurt Schneider Leibniz Universität Hannover, Germany
Helen Sharp The Open University, UK
Darja Smite Blekinge Institute of Technology, Sweden
Roberto Tonelli University of Cagliari, Italy
Rini Van Solingen Delft University of Technology, The Netherlands
Stefan Wagner University of Stuttgart, Germany
Xiaofeng Wang Free University of Bozen-Bolzano, Italy
Hironori Washizaki Waseda University, Japan
Agustin Yague Universidad Politecnica de Madrid, Spain

Reviewers (Industry and Practice)

Giovanni Asproni Asprotunity, UK
Emily Bache Bache Consulting, Sweden
Filipe Correia Uphold, Portugal
Aino Corry Metadeveloper, Denmark
Lisa Crispin Pivotal, USA
Jutta Eckstein IT communication, Germany
Sallyann Freudenberg Sallyann Freudenberg Consulting, UK
Steve Holyer Steve Holyer and Associates, Switzerland
Lise Hvatum Schlumberger, USA
Allan Rennebo Jepsen Core Agile, Denmark
Jason Kerney Hunter Industries, USA
David Kramer Agile New England, USA
Casper Lassenius Aalto University, Finland
Olaf Lewitz trustartist.com, Germany
Ralph Miarka sinnvollFÜHREN, Austria
Maria Paasivaara Alto University, Finland
Dana Pylayeva Hudson’s Bay Company, USA
Seb Rose Cucumber, UK
Johanna Rothman Rothman Consulting Group, USA
Aki Salmi Ambientia, Finland
Andreas Schliep Das ScrumTeam, Switzerland
Irina Tsyganok Yoox Net-A-Porter Group
Nils Wloka codecentric AG, Germany
Joseph Yoder The Refactory, USA
Joe Wright Arnold Clark Automobiles, UK
X Organization

Additional Reviewers

Adam, Kai Kautz, Oliver

Bjørnson, Finn Olav Kusmenko, Evgeny
Britto, Ricardo Raco, Deni
Butting, Arvid Santana, Célio
Da Silva, Tiago Silva Santos, Viviane
Díaz, Jessica Stray, Viktoria
Edison, Henry Vestues, Kathrine
Fernández-Sánchez, Carlos Wang, Yang
Fögen, Konrad

Sponsors

“Cologne Cathedral” Sponsor

REWE digital

“Albertus Magnus” Sponsor

Accenture Interactive

“River Rhine” Sponsors

DATEV
EPLAN Software & Service
OPITZ CONSULTING
XebiaLabs

“Kölsch” Sponsor

Hänneschen and Bärbelchen

Organizer

codecentric
 Contents

Improving Agile Processes

Reflection in Agile Retrospectives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Yanti Andriyani, Rashina Hoda, and Robert Amor

What Influences the Speed of Prototyping? An Empirical Investigation

of Twenty Software Startups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Anh Nguyen-Duc, Xiaofeng Wang, and Pekka Abrahamsson

Key Challenges in Agile Requirements Engineering . . . . . . . . . . . . . . . . . . 37

Eva-Maria Schön, Dominique Winter, María José Escalona,
and Jörg Thomaschewski

Eeny, Meeny, Miny, Mo...: A Multiple Case Study on Selecting

a Technique for User-Interaction Data Collecting . . . . . . . . . . . . . . . . . . . . 52
Sampo Suonsyrjä

Comparing Requirements Decomposition Within the Scrum, Scrum

with Kanban, XP, and Banana Development Processes . . . . . . . . . . . . . . . . 68
Davide Taibi, Valentina Lenarduzzi, Andrea Janes, Kari Liukkunen,
and Muhammad Ovais Ahmad

Effects of Technical Debt Awareness: A Classroom Study . . . . . . . . . . . . . . 84

Graziela Simone Tonin, Alfredo Goldman, Carolyn Seaman,
and Diogo Pina

Agile in Organizations

Don’t Forget to Breathe: A Controlled Trial of Mindfulness Practices

in Agile Project Teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Peter den Heijer, Wibo Koole, and Christoph J. Stettina

Enhancing Agile Team Collaboration Through the Use of Large Digital

Multi-touch Cardwalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Martin Kropp, Craig Anslow, Magdalena Mateescu, Roger Burkhard,
Dario Vischi, and Carmen Zahn

Knowledge Sharing in a Large Agile Organisation: A Survey Study . . . . . . . 135

Kati Kuusinen, Peggy Gregory, Helen Sharp, Leonor Barroca,
Katie Taylor, and Laurence Wood
XII Contents

Teaching Agile Methods to Software Engineering Professionals:

10 Years, 1000 Release Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Angela Martin, Craig Anslow, and David Johnson

Are Software Startups Applying Agile Practices? The State of the Practice
from a Large Survey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Jevgenija Pantiuchina, Marco Mondini, Dron Khanna, Xiaofeng Wang,
and Pekka Abrahamsson

Adopting Test Automation on Agile Development Projects:

A Grounded Theory Study of Indian Software Organizations . . . . . . . . . . . . 184
Sulabh Tyagi, Ritu Sibal, and Bharti Suri

Safety Critical Software

How is Security Testing Done in Agile Teams? A Cross-Case Analysis

of Four Software Teams. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Daniela Soares Cruzes, Michael Felderer, Tosin Daniel Oyetoyan,
Matthias Gander, and Irdin Pekaric

An Assessment of Avionics Software Development Practice:

Justifications for an Agile Development Process . . . . . . . . . . . . . . . . . . . . . 217
Geir K. Hanssen, Gosse Wedzinga, and Martijn Stuip

Short Research Papers

Inoculating an Agile Company with User-Centred Design:

An Empirical Study. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Silvia Bordin and Antonella De Angeli

On the Usage and Benefits of Agile Methods & Practices: A Case Study
at Bosch Chassis Systems Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Philipp Diebold and Udo Mayer

Checklists to Support Test Charter Design in Exploratory Testing . . . . . . . . . 251

Ahmad Nauman Ghazi, Ratna Pranathi Garigapati, and Kai Petersen

Discovering Software Process Deviations Using Visualizations . . . . . . . . . . . 259

Anna-Liisa Mattila, Kari Systä, Outi Sievi-Korte, Marko Leppänen,
and Tommi Mikkonen

Exploring Workflow Mechanisms and Task Allocation Strategies

in Agile Software Teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
Zainab Masood, Rashina Hoda, and Kelly Blincoe
 Contents XIII

Are Daily Stand-up Meetings Valuable? A Survey of Developers

in Software Teams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Viktoria Stray, Nils Brede Moe, and Gunnar R. Bergersen

Doctoral Symposium Papers

Knowledge Management and Reflective Practice in Daily Stand-Up

and Retrospective Meetings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
Yanti Andriyani

Self-Assignment: Task Allocation Practice in Agile Software Development. . . . 292

Zainab Masood

Software Development Practices Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . 298

Herez Moise Kattan and Alfredo Goldman

Author Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305

Improving Agile Processes
 Reflection in Agile Retrospectives

Yanti Andriyani1 ✉ , Rashina Hoda1, and Robert Amor2

( )

1
SEPTA Research, Department of Electrical and Computer Engineering,
The University of Auckland, Building 903, 386 Khyber Pass, New Market,
1023 Auckland, New Zealand
[email protected], [email protected]
2
Department of Computer Science, The University of Auckland, Auckland, New Zealand
[email protected]

Abstract. A retrospective is a standard agile meeting practice designed for agile

software teams to reflect and tune their process. Despite its integral importance,
we know little about what aspects are focused upon during retrospectives and how
reflection occurs in this practice. We conducted Case Study research involving
data collected from interviews of sixteen software practitioners from four agile
teams and observations of their retrospective meetings. We found that the impor‐
tant aspects focused on during the retrospective meeting include identifying and
discussing obstacles, discussing feelings, analyzing previous action points, iden‐
tifying background reasons, identifying future action points and generating a plan.
Reflection occurs when the agile teams embody these aspects within three levels
of reflection: reporting and responding, relating and reasoning, and recon‐
structing. Critically, we show that agile teams may not achieve all levels of
reflection simply by performing retrospective meetings. One of the key contri‐
butions of our work is to present a reflection framework for agile retrospective
meetings that explains and embeds three levels of reflection within the five steps
of a standard agile retrospective. Agile teams can use this framework to achieve
better focus and higher levels of reflection in their retrospective meetings.

Keywords: Agile retrospective meeting · Reflection · Levels of reflection ·

Teams · Agile software development · Reflective practice

1 Introduction

Retrospective meetings embody the ‘inspect and adapt’ principle of Agile Software
Development (ASD) [1, 2]. They are designed to enable agile teams to frequently eval‐
uate and find ways to adjust their process [3]. There are several purposes for retrospective
meetings, such as to evaluate the previous work cycle or sprint; to determine the aspects
that need to be focused on as areas of improvement; and to develop a team action plan
[4]. The purpose and the techniques of the retrospective meeting have been stated and
described clearly as a guide for agile teams [2, 5, 6].
Much of the existing research focuses on the techniques of performing retrospective
meetings and provides lesser detail about the reflection process involved [5–9]. The
Reflective Agile Learning Model (REALM) [7] classified reflection in ASD practices

© The Author(s) 2017

H. Baumeister et al. (Eds.): XP 2017, LNBIP 283, pp. 3–19, 2017.
DOI: 10.1007/978-3-319-57633-6_1
4 Y. Andriyani et al.

into reflection-in-action or reflection that occurs during a practice, and reflection-on-

action or reflection that occurs post a practice based on definitions of the same by Argyris
and Schön [10]. A retrospective meeting was seen to embody reflection-on-action where
the agile teams reflect post finishing their sprint [7]. However, what is focused on during
retrospectives and how reflection occurs in this practice is not well understood.
To address this gap, we conducted Case Study research by observing four agile teams
and interviewing 16 of their members guided by the following research questions:
RQ 1: What aspects are focused on during the retrospective meeting?
RQ 2: How does reflection occur in the retrospective meeting?

2 Related Work

2.1 Agile Retrospective Meeting

There is a standard format commonly used to conduct an agile retrospective meeting

which involves setting the stage, gathering data, generating insight, deciding what to
do and closing the retrospective meeting [2]. Setting the stage involves welcoming and
explaining the aim of the retrospective meeting. Gathering data involves agile teams
sharing their review and feedback, reporting on what happened during the previous
sprint and briefly discussing with other team members. In generating insight, agile teams
participate in a further discussion and making agreements about what issues to focus on,
and then on how to solve those issues and what areas that need to improve in the deciding
what to do stage. Closing the retrospective involves summarizing the retrospective
meeting and appreciating all team members’ efforts.
There are several recommendations for embedding reflective practice within standard
agile practices as it is related to team performance improvement [7–9]. Cockburn [8] intro‐
duced a reflection workshop which involves collecting issues and generating tasks and
decisions. This workshop is performed regularly during or after the post-iteration work‐
shop. Babb et al. [7] investigated reflection in agile practices based on Argyris and Schön’s
[10] classification and introduced the Reflective Agile Learning Model (REALM).
REALM describes how some agile practices embody reflection-in-action and reflection-
on-action. Retrospective meetings were seen to embody reflection-on-action where the
agile teams reflect post finishing their sprint [7].
Most of the existing research focuses on the techniques of performing a retrospective
or identifying a broad classification of the type of reflection that occurs, e.g. reflection-
on-action [7]. What actual topics or aspects are discussed during a retrospective and how
reflection occurs, however, is not well understood. We build upon these works by inves‐
tigating the retrospective meeting in depth.

2.2 Reflective Practice

Reflective practice according to Osterman and Kottkamp [11], is defined as “a means

by which practitioners can develop a greater level of self-awareness about the nature
 Reflection in Agile Retrospectives 5

and impact of their performance, an awareness that creates opportunities for profes‐
sional growth and development”.
Bain et al. [12] classified reflection into five levels: reporting, responding, relating,
reasoning and reconstructing. Level 1 and 2 are reporting and responding and enable
learners to share brief descriptions of their experience, their feelings about events, facts
or problems that they encountered. Level 3 is relating and involves connecting experi‐
ence with personal meaning. Understanding at this level occurs when learners try to
highlight good points (e.g. their ability, successful work) and negative points (e.g.
mistakes, failure) to learn and identify areas of improvement. Level 4 is reasoning where
learners explore the information shared as well as background knowledge related to the
occurrences. Level 5 is reconstructing which signifies a high level of learning where
learners generate the general framework of thinking, which is specified in a plan or action
for responding to similar obstacles in the future.
Our study refers to levels of reflection proposed by Bain et al. [12] and adjusts the
levels into three main levels, i.e. reporting and responding, relating and reasoning and
reconstructing, based on our observations of the agile retrospectives in practice.
Reporting and responding are grouped together as the first level as these levels closely
related to reviews sharing and discussions at the beginning of the retrospective meeting.
Relating and responding are grouped as the second level as agile teams participate in a
further discussion after they reported and responded to the reviews. The third level, the
reconstructing level is embodied when agile teams discuss to formulate a plan as an
improvement for the next sprint.

3 Research Method

The aim of this study is to investigate how reflection occurs in retrospective meetings.
Understanding this is particularly important as agile teams are reported to focus more
on their technical progress and tend to pay less attention to how reflection is performed
thereby compromising their potential for improvement [7, 13].
This research is conducted by implementing the Case Study research method [14].
First, existing studies related to reflection in retrospective meetings were reviewed, as
summarized in Sect. 2. The research gaps identified provided guidance on formulating
the interview questions. To gain rich data from interviews, we developed semi-struc‐
tured questions consisting of main questions and follow-up questions. The data collec‐
tion method is described in Sect. 3.1 and participant demographics summarized in
Table 1. All interviews and observation data were collected by the first author in person.
The raw data and emerging findings from the analysis were discussed in detail with the
supervisory team (co-authors) who provided feedback and guidance.

3.1 Data Collection

Participants. We wanted to include software practitioners with a minimum of 2 years’

industrial agile experience to participate in our research. During one of the Auckland
Agile meetups, we received interest in participation from an agile team lead working at
6 Y. Andriyani et al.

Table 1. Team and team members demographics (RMD: Retrospective meeting duration in
minutes; P#: Individual participant number; FAP: first agile project)
Team Interview Agile RMD and the P# Role Agile Agile
Name ed/total method frequencies experience projects
members (Year) (Total)
Jupiter 5 out of Scrum 65 min (every P1 UI 1 6–8
10 two weeks) Designer
P2 Developer 0.5 1
P3 Developer 7+ 6–7
P4 Business 7+ 20+
analyst
P9 Tester 3+ 10+
Saturn 6 out of Scrum 55 min (every P4 Business 7+ 20+
10 two weeks) analyst
P5 Developer 3 10+
P6 Designer 1 month FP
P7 Designer 0.5 FAP
P8 Tester 3+ 6
P9 Tester 3+ 10+
Uranus 2 out of 3 Kanban 45 min (every P10 Tester, 1 2
two weeks) Developer
P11 Scrum 6 6
Master,
Business
Analyst,
Product
Owner
Neptune 4 out of 6 Scrum 15 min (when P12 Tester 2 1
needed) P13 Developer 1.5 FAP
P14 Developer 1 FAP
P15 Tester <1 year FAP
Working across all four teams P16 Test 7 10+
chapter
lead

the largest online auction company in New Zealand, Trade Me. Trade Me had been
practicing agile software development for over three years and provided access to four
teams. Its headquarters are located in Wellington and the regional offices are in Auckland
and Christchurch.
For confidentiality purposes, the teams are named Jupiter, Saturn, Uranus, and
Neptune. The team names and team members’ details can be seen in Table 1. Each team
consisted of between 3 and 10 members. All members were invited and those willing
were interviewed. All teams held retrospective meetings, which lasted for between 15
and 65 min. Sixteen individual practitioners from the four teams participated in the
interviews and the observations. All team members had a dedicated role in their team
 Reflection in Agile Retrospectives 7

and there were three participants that committed across different teams: P4 was not only
fully committed as a Business Analyst in Team Jupiter but also supported Team Saturn.
Similarly, P9 was a tester in Team Saturn and a half tester in Team Jupiter. P16 worked
as a test lead across all four teams.

Interviews and Observations. Face-to-face individual and one group interview (of six
team members) were conducted to gain comprehensive explanations, which would help
derive the real concerns from both individual and team perspectives. We conducted one-
on-one interviews with all participants (P1–P16), where the duration of individual inter‐
views varied from 35 to 50 min. We asked some semi-structured questions about their
experiences and perspectives related to reflection in a retrospective meeting. Some
sample questions include: “Based on the three main points discussed in a retrospec‐
tive (i.e. what went well, what went wrong, what can you improve), which one(s) do you
think are most helpful for your team’s reflection?”, “How does your team use those
points to find solutions and ways to improve? Could you give some real examples?” and
“What is the outcome of your retrospective meeting? Does your team/scrum
master preserve points from the meeting?”. A sample question of the group interview
includes: “I noticed that your team exhibited some different ways of sharing knowledge,
(e.g. post-it notes, verbal communication, drawing). Did it help your team to perform
reflection? How?”
The group interview was conducted immediately after the retrospective meeting of
Team Jupiter with six of its team members. Given the variable meeting times, work
commitments and deadlines for different teams, it was not possible to gain further team
availability for group interviews with the remaining three teams over and above the
individual interviews and team observations.
Observations were conducted during the retrospective meetings of all the teams and
of their general workplace. The observations aimed to capture the details of the retro‐
spective meeting (i.e. time spent, attendees, and discussion involved) and to help validate
the findings from the interviews. Photographs were taken during the observations in
order to document the actual situations in the meetings and the report presented by the
agile team members. Notes were taken to highlight the important aspects being shared.
The information collected (e.g. photographs and notes) from the observations were used
to support individual interviews by including the photographs and describing the activ‐
ities in the retrospective meetings as observed first hand. The duration of each obser‐
vation depended on how long the team conducted the retrospective meeting. Three out
of four teams conducted the meeting for around 40–60 min each and one team, Neptune,
had a shorter 15 min’ retrospective. Observational data (e.g. photographs and notes)
were found to support the findings from the interview data analysis thereby strengthening
them.

3.2 Data Analysis

This research involved sixteen individual interviews, one group interview (of six team
members), and notes taken from retrospective meeting observations which were
analyzed by conducting a thematic analysis. Thematic analysis is a method that aims to
8 Y. Andriyani et al.

recognize, analyze, evaluate and report patterns in data [15], which enables researchers
to search across a data set of interviews. Braun and Clarke [15] classify the analysis into
six phases: transcribing data, generating initial codes, searching for themes, reviewing
themes, defining and naming themes and making a report.
Sixteen interviews were transcribed and imported into NVivo software to facilitate
coding and thematic analysis. Generating initial codes involved code identification by
analyzing interesting features of a sentence, which were highlighted and added as a node
in NVivo representing a new code, such as identifying and discussing obstacles and
discussing feelings. Searching for themes involved comparing data with different codes
to see whether they have similar meanings or aspects. Parent themes were classified
based on five (grouped into three) levels of reflection, where each code was classified
based on the definition of each level.

Fig. 1. Levels of reflection in retrospective meetings: a thematic map (using levels of reflection
from Bain et al. [12])

Reviewing themes involved generating a thematic model to define the links and the
relationships between the themes (see Fig. 1). Defining and naming themes involved the
generation of several themes that emerged from the analysis, representing the aspects
discussed during retrospective meetings, which was formulated and explained in this
paper.

4 Findings

Following the thematic data analysis process, we identified seven themes that represent
important topics or aspects discussed in the retrospective meeting, which were then
mapped to the five (grouped into three) levels of reflection [12] (see Sect. 2.2).
 Reflection in Agile Retrospectives 9

Table 2 summarizes these themes along with their mapping to the reflection levels.
These themes and levels are described below along with pertinent quotes and photo‐
graphs from observations. The figures below (see Figs. 2 and 3) were captured during
the observation and show a glimpse of Team Jupiter and Team Saturn’s retrospective
meeting.

Table 2. Themes representing topics discussed during retrospectives, their description,

examples, and mapping to levels of reflection based on [12].
Levels of reflection Themes/topics discussed Description of themes Examples
Reporting and Identifying and Problems, issues and Unfinished tasks and
Responding discussing obstacles concern causing dependencies (e.g.
blockages expertise, activity,
resource or entity and
technical.)
Discussing feelings The Subjective response Negative and positive
that reflects the situation, feelings
fact or events from the
previous sprint
Relating and Reasoning Analyzing previous Evaluate the process Some improvement
action points improvement based on achieved or persisting
previous action points obstacles
Identifying background Analyzing some causes Testing environment
reasons and aspects related to issue related to external
issues on team person in different
improvement location, who is difficult
to contact
Identifying future action Evaluating what areas Evaluate successful
points need to be focused on stories and failures
more to be defined as
future action points
Reconstructing Generating a plan Define some action Action points
points for the next plan

Fig. 2. Team Jupiter’s retrospective Fig. 3. Team Saturn’s retrospective

10 Y. Andriyani et al.

4.1 Reporting and Responding

Reporting and responding can be realized when an agile team shares some aspects (e.g.
identifying and discussing obstacles and discussing feelings) while providing reviews
and feedback of the previous sprint. Each team had different techniques of performing
their reviews.
All teams were seen to engage in the reporting level of reflection by actively iden‐
tified and discussed obstacles and feelings. Similarly, all four teams were seen to be
actively involved in responding to their retrospective meeting discussions by providing
brief comments on the obstacles and feelings being shared. Teams were seen to report
on obstacles such as dependencies and unfinished tasks and respond with negative and
positive feelings based on the previous sprint, described below.

Identifying and Discussing Obstacles. Obstacles reported in the retrospective meet‐

ings related to the aspects that hindered the team from making progress. During the
retrospective meeting, agile teams gathered all the problems that occurred in the previous
sprint, which would be useful for the teams to highlight areas of improvement. There
were two specific obstacles reported: dependencies and unfinished tasks.

Dependencies. Most of the participant (11 out of 16) mentioned dependencies as the
specific type of obstacle most commonly reported in the retrospective meeting.
“If it’s delayed at the first point, if something is wrong at the first point the next person feels it.
So, if one brings it up [in the retrospective] and if it’s a true concern you will have support
because it does affect people.” P16 – Test Chapter Lead (Across All Teams)

By sharing problems about dependencies team members became aware of the other
team members’ tasks and how they related to their own tasks. By being aware of this
issue the team could think about ways to solve the dependency problems.

Unfinished tasks. Unfinished tasks were mentioned by three participants as an obstacle

reported in retrospective meetings. An unfinished task was a problem where team
members could not accomplish the tasks they had planned or considered the team to be
making slow progress.
“We were not achieving that daily goal and it is a kind of demotivating… let’s say you plan 10
stories for the sprint and you achieve just two or three. The rest we couldn’t complete for what‐
ever reason. So, we say that is one thing which didn’t go well.” P12 – Tester, Team Neptune

Surfacing this obstacle was helpful for teams to understand how much more effort
was required to finish the tasks, what tasks were challenging and why the tasks were
difficult to finish. For example, when Team Neptune faced a problem with a requirement
that delayed finishing tasks, they asked for clarifications from the product manager. It
was evident that dependencies led to unfinished tasks in some cases.

Discussing Feelings. Besides obstacles, agile teams also shared their feelings which
were visualized in several forms, e.g. as drawings or journey lines. The feelings shared
by team members represented the sense of facts and occurrences from the previous
sprint, such as when they were feeling down or happy.
 Reflection in Agile Retrospectives 11

There was an example of positive feelings shared, which had a positive impact on
the team’s productivity, where their work can be distributed well. Team Neptune
recruited an additional tester after they had a problem with tester resource. They felt
happy because their team was complete and balanced between developers and testers.
“We do put down smiley. When we got a new tester on board, a new person we had a happy
smiley saying that our squad is complete.” P12 – Tester, Team Neptune

These obstacles and feelings identified and discussed during the retrospective
meeting were supported by our observations of the retrospective meetings of Teams
Jupiter, Saturn, and Uranus. It was observed that Team Jupiter reported their review by
defining some words on sticky notes (see Fig. 4(a)).

(a) Team Jupiter (b) Team Saturn (c) Team Uranus

Fig. 4. (a) Words to describe obstacles and feelings in the Retrospective meeting; (b) and (c)
Journey lines visualizing emotions during a sprint in Retrospective meetings

For example, ‘muddy’ was used to describe a difficult situation where team members
had difficulty in understanding the detailed description of specific user stories in the
project. Upon asking a team member about what was the meaning of ‘muddy’, a partic‐
ipant explained:
“So, I think, he and I came up with the term of ‘muddy’; from observation - they were really
struggling to get the right data and really had to analyse the data for this project. I observed
that and for me, I would pick out a description which would explain what I’ve observed; as a
general team.”, P1 – User Interface Designer, Team Jupiter.

4.2 Relating and Reasoning

Relating and reasoning can be seen when agile teams compile the obstacles and the
feelings shared (from the previous reporting and responding level) and investigate the
relationship between those aspects. These levels consisted of activities such as analyzing
previous action points, identifying background reasons, identifying future action
points. The explanations below present the results from the individual interviews, which
supported by group interview and observations.

Analyzing Previous Action Points. An ‘action point’ refers to a specific item selected
by the team to focus on for improvement. In analyzing previous action points, agile
12 Y. Andriyani et al.

teams referred to the action points agreed upon by the team in the previous retrospective
and evaluated the actual effort made by the team on that specific point.
“..that’s how you define if you made any changes, we measure yourself based on your action
points and that you’ve actually made changes for. You could make 200 action points of your 20
weeks, but not a single one of those was followed up on, you really haven’t done anything.” P4
– Business Analyst, Team Jupiter and Saturn

From the example above, it was seen that agile teams reflected on the previous action
points by measuring the outcomes achieved by the teams (i.e. good or slow progress).
This statement was further supported by the observations where during the retrospective
meetings, agile teams shared the process improvement or the failures of the previous
sprint.

Identifying Background Reasons. The background reasons of the existing issues were
identified when teams were not actively progressing, they would explore the reasons
why and what blockers were related to this problem. By identifying the background
reasons, teams would understand what aspects needed to be improved.
This point is supported by Team Jupiter’s group interview, which a team member
tried to identify the reason of the major problem during the retrospective meeting.
“I think we addressed like the major issues are causing the squad stuck at the moment and things
like test environment and [..] dealing with an external dependency like platform team in [city
name]” P4 – Business Analyst, Team Jupiter and Saturn

During the retrospective meeting observation of Team Saturn, it was seen that there
was a cause analysis discussion. For example, when team members shared their sad
feelings experienced during the first week sprint, team members shared the reasons, such
as unclear user stories or the user story was considered as a big task. The scrum master
guided the team to identify the causes by asking why they used the sad feeling notation
for the first week. Several reasons were shared, such as too many tasks, the previous
estimation and the actual effort were different, the unclear scope of work restricted their
progress. Discussing those reasons led to the point where the team realized the main
background reason was about inaccurate estimation, i.e. the team had created high
achievement expectations for the big tasks without considering the actual effort required.

Identifying Future Action Points. Identifying future action points happened when the
teams analyzed previous action points and identified the background issues, which
followed by identifying areas of improvement and asking ideas and agreement from the
teams. From the discussion, the teams gained the understanding of the existing issues
which lead to the thoughts of what areas need to improve and how to improve. Identi‐
fying future action points, the teams discussed areas of improvement, which were
focused on the process improvement. For example, in the retrospective meeting, most
agile teams stressed testing environment issues that delayed the team progress.
“we list down what didn’t go well or problems or whatever, we usually derive action points on
those things, which is a good way to improve maybe something immediately like getting a test
environment set up so we can test something.…like a more immediate thing… but there are also
action points that are related to the squad as well; determine a team chart or something like
that.” P2 – Developer, Team Jupiter
 Reflection in Agile Retrospectives 13

From the example above, it was seen that by knowing the existing issues the team
to will understand several areas of the process that need to be focused on. To determine
future action points the teams also discussed by asking each other’s opinions.
“when we discussed it [a plan], we asked other people what they think about it, do they agree
or don’t they? If everyone says they think they agree with what you are saying, then we say so
what the action for that?” P12 – Tester, Team Neptune

During the retrospective observations of Team Saturn, an example of how the team
identified their future action points was noted. Team Saturn had identified that the main
reason for their slow progress was inaccurate estimation. Some ideas for addressing this
included elaborating the stories into small tasks, providing the clear ‘definition of done’
for specific tasks, and asking for clarifications from the product manager about the scope
of work. The team members were asked their opinions and perspectives about these
ideas. Most team members agreed on asking for clarifications from the product manager
and elaborating the stories into small tasks. Consequently, the Scrum master of Team
Saturn made these ideas as official action points for the next sprint.

4.3 Reconstructing
The Reconstructing level of reflection seems to happen when a team constructs an
agreement on a specific plan based on the team members’ perspectives. There were three
out of the four teams (Jupiter, Saturn, Uranus) that seemed to engage in the recon‐
structing level as they performed further discussions and finalized by generating action
points.

Generating a Plan. In reconstructing, teams generated plans decided from their discus‐
sion in the retrospective meeting. Action points are an explicit outcome of the retro‐
spective meeting. It is useful to remind all team members about the goal for the next
sprint, who will responsible, and what are the associated deadlines.
“So, when they go up on their board and they are doing their sprint work, they can see, “Right,
let’s not forget what came out of this retro” and it is getting ticked off.” P11 – Scrum Master,
Business Analyst and Product Owner, Team Uranus

This point was brought up in a group interview (of Team Jupiter) where most of the
team members agreed that action points were used as a reference for evaluating improve‐
ment in the next retrospective meeting.
“umm we pulled out action points on the board. So, over the next two weeks, we will make sure
that everything talked about we follow through on.” P4 – Business Analyst, Team Jupiter and
Saturn

It was observed that Team Jupiter preserved their concrete action points on their
Scrum board (see Fig. 5). Another evidence from the observations was Teams Saturn
and Uranus did not have action points but their Scrum master made some notes during
the meetings and shared verbally the points that needed to be focused on at the end of
the retrospective meeting.
14 Y. Andriyani et al.

Fig. 5. Action points generated by team Jupiter posted on their Scrum Board (Photo taken during
on-site observations)

5 Discussion

We now discuss the findings related to a reflection framework for agile retrospectives
including the levels of reflection achieved by the teams studied, implications for practice
and limitations of the study.
In response to the RQ1: What aspects are focused on during the retrospective
meeting? We found that there are six important aspects discussed in the retrospective
meetings: identifying and discussing obstacles, discussing feelings, analyzing previous
action points, identifying background reasons, identifying future action points and
generating a plan. In response to the RQ 2: How does reflection occur in the retrospec‐
tive meeting? We found that the reflection that occurs in retrospective meetings can be
classified into three levels of reflection [12], reporting and responding, relating and
reasoning, and reconstructing.

5.1 A Framework of Reflection in Agile Retrospective Meeting

Based on these findings, we present a reflection framework for agile retrospectives

(Fig. 6) that combines the five steps of the standard agile retrospective – set the stage,
gather data, generate insight and decide what to do, close the retrospective – and the
levels of reflection – reporting and responding, relating and reasoning, and recon‐
structing [12] within those steps.
 Reflection in Agile Retrospectives 15

Fig. 6. Reflection in agile retrospective meeting (levels of reflection depicted in shaded areas
based on [12])

Setting the stage involves welcoming and explaining the aim of the retrospective
meeting. Gathering data step embodies the reporting and responding level of reflection
as agile teams share their reviews (e.g. identifying and discussing obstacles and discus‐
sing feelings). Identifying and discussing obstacles and feelings in retrospective meet‐
ings was seen to correspond to ‘descriptive reflection’ [16] – a reflection which attempts
to answer questions such as: What is happening? What is this working, and for whom?
For whom is it not working? How do I know? How am I feeling? What am I pleased
and/or concerned about? What do I not understand? The obstacles and feelings shared
by all team members answer these questions. From the obstacles and feelings reported,
the teams would be able to record and collect important points of the previous sprint.
By having reviews (e.g. obstacles and feelings) of the previous sprint, team members
can be prepared to deal with other similar experiences.
Generating insight step embodies the relating and reasoning level, where agile
teams are involved in analyzing previous action points, identifying the background
reasons behind identified issues and identifying future action points. Discussing these
aspects was seen to be related to ‘descriptive reflection’, which attempts to answer
questions: does this relate to any of my stated goals and to what extent are they being
met? [16] and why the issues happen in the previous sprint? The answers to these ques‐
tions support the reflection in the form of comparative analysis and looking back to the
background issues, which help agile teams to determine what areas needed to be focused
on. Agile teams move to deep analysis on ideas or perspective shared to identify future
action points for the next sprint. It can be perceived that there is a transformation in the
discussion from answering what is happening? in the previous sprint; to what are the
alternative views of what is happening? and what are the implications of the matter
when viewed from these alternative perspectives? [16]. These questions are answered
when all team members provide their accounts about solutions of the obstacles or ways
to improve.
In the deciding what to do step, agile teams have an explicit formulation which is
generated in the form of action points (generating plans). The action points will be used
as a reference for agile teams to act upon and improve the process. Close the retrospec‐
tive step involves summarizing the outcomes of the retrospective meeting.
16 Y. Andriyani et al.

5.2 Levels of Reflection Build on Each Other

We now discuss the findings related to the levels of reflection achieved by the teams
studied. A key finding of our study was that not all teams were performing on every
level of reflection. So, while all teams performed retrospective meetings, not all achieved
the higher levels of reflection, in particular reconstructing. Table 3 summarizes the levels
of reflection achieved by each of the teams and the associated aspects or topics discussed
in each level.

Table 3. Levels of reflection achieved by the teams (J: Jupiter; S: Saturn; U: Uranus; N: Neptune)
Levels of Aspects discussed in retrospective meeting J S U N
reflection
Reporting and Identifying and discussing obstacles ✓ ✓ ✓ ✓
responding Discussing feelings ✓ ✓ ✓ X
Relating and Analyzing previous action points ✓ ✓ ✓ ✓
reasoning Identifying background reasons ✓ ✓ ✓ ✓
Identifying future action points ✓ ✓ ✓ X
Reconstructing Generating a plan ✓ ✓ ✓ X

Three teams were found to be fully engaged in all levels of reflection and one of the
teams, Team Neptune, performed partially on the first two levels and did not achieve
the final level of reflection, i.e. reconstructing. Based on the observation of their retro‐
spective meeting, it was seen that they did not discuss their feelings explicitly and only
discussed briefly the obstacles related to changing of task priorities needing confirmation
with the product manager. They did not discuss it further as once they agreed on that
obstacle then the product manager directly proceeded to the Scrum Board, discussed the
issue and wrapped up the meeting. They did not record any outcomes, such as a plan or
action points, from the meeting. There was little evidence of analyzing previous action
points, identifying background reasons and identifying future action points. Besides, the
duration of the meeting was also short, around 15 min, and they reported performing
retrospective meetings only when it was necessary. Another interesting observation was
that they had adapted the retrospective practice, which seemed too repetitive for them
and people often seemed to have forgotten about what happened during the last two
weeks’ sprint. As result, they were used to placing all the individual reviews written up
on sticky notes in a “retro box” – a box especially allocated to collect individual reflec‐
tion. If there were no sticky notes during a two weeks’ sprint, they would not perform
a retrospective meeting.
The case of Team Neptune is likely related to the fact that three out of six members
of Team Neptune were new to agile projects. They had in effect introduced a new
reflective practice, that of using a retro box, as a way to identify the need for conducting
a standard retrospective. However, a lack of reaching the reconstruction level suggests
that they were not able to generate a plan for improvement as several aspects of the
retrospective meeting were missing. Our findings confirm that the levels of reflection
are related and build on each other [12]. Furthermore, we show that the highest level of
 Reflection in Agile Retrospectives 17

reflection, reconstructing, may not be reached at all or not reached effectively until the
prior levels are accomplished effectively.

5.3 Implications for Research and Practice

For the researchers in the area of reflective practice and agile teams, our findings present
a new perspective for exploring reflective practice in agile teams. Using the framework
presented in the previous section, researchers can study agile teams’ reflective practice
in terms of levels of reflection both in retrospective meetings and other practices that
involve reflection (e.g. daily standup, pair programming [7]). Future studies can explore
new aspects or topics covered in each level and further explore how the levels build
upon each other in different team contexts.
For agile practitioners, our findings show that not all agile teams reach all levels of
reflection by simply performing retrospectives. By being aware of the different levels
of reflection meant to be achieved in each retrospective step, teams can consciously
strive to achieve the most out of their retrospective meetings. In particular, they can see
that only reporting and responding and relating and reasoning levels are not enough
rather reconstructing to generate action points and following up on those points in future
meetings is critical to harnessing retrospective meetings to achieve continuous improve‐
ment. Thus, in order to maximize the benefits of their retrospective meetings, we recom‐
mend agile teams use our reflection framework (Fig. 6) to self-assess their level as a
whole based on their personal understanding of their team context and track it in practice
to achieve higher levels of reflection.

5.4 Limitations

A key limitation of this study lies in the fact that observations of a single retrospective
meeting per team is not strong enough to establish and confirm a particular team’s overall
level of reflection. For example, it may be that in other retrospective meetings Team
Neptune reached higher levels of reflection. However, the findings were arrived at by
combining the data from interviews as well as the observations, which provides multiple
perspectives that support the findings. Another related limitation is that the findings are
limited to the contexts studied in this research, which in turn are dictated by the avail‐
ability of participants. Further studies can confirm, adapt, or extend our framework to
include different team contexts and reflective practices.

6 Conclusion

Previous studies have focused on specifying the techniques of conducting a retrospective

meeting, with little focus on how the reflection in the retrospective meeting actually
occurs. One of the key contributions of our work is to present a reflection framework
for agile retrospective meetings that explains and embeds five (grouped into three) levels
of reflection within the five steps of a standard agile retrospective meeting. Critically,
we show that agile teams may not achieve all levels of reflection simply by performing
18 Y. Andriyani et al.

retrospective meetings. As the levels of reflection build upon each other, teams need to
effectively identify and discuss their obstacles and feelings in the reporting and
responding level, followed by analyzing previous action points, identifying background
reasons, and identifying future action points in the relating and reasoning level and
generating a plan in the reconstructing level. Embedding these levels of reflection into
the retrospective meeting will help agile teams achieve better focus and higher levels of
reflection from performing retrospective meetings. Another implication is an increase
in their awareness of the main aspects that need to be discussed in the retrospective
meeting and how to formulate these aspects to generate a plan for improvement.

Acknowledgement. This research is supported by The University of Auckland and the Indonesia
Endowment Fund for Education (LPDP) S-669/LPDP/2013 as scholarship provider from the
Ministry of Finance, Indonesia.

References

1. Deemer, P., Benefield, G., Larman, C., Vodde, B.: A Lightweight Guide to the Theory and
Practice of Scrum Version 2.0, vol. 2015 (2012)
2. Derby, E., Larsen, D., Schwaber, K.: Agile Retrospectives: Making Good Teams Great.
Pragmatic Bookshelf, Raleigh (2006). 0977616649
3. Fowler, M., Highsmith, J.: The agile manifesto. Softw. Dev. 9, 29 (2001)
4. Sutherland, J., Schwaber, K.: The Scrum Guide. The Definitive Guide to Scrum: The Rules
of the Game (2011)
5. Salo, O.: Systematical validation of learning in agile software development environment. In:
Althoff, K.-D., Dengel, A., Bergmann, R., Nick, M., Roth-Berghofer, T. (eds.) WM 2005.
LNCS (LNAI), vol. 3782, pp. 106–110. Springer, Heidelberg (2005). doi:
10.1007/11590019_13
6. Salo, O., Kolehmainen, K., Kyllönen, P., Löthman, J., Salmijärvi, S., Abrahamsson, P.: Self-
adaptability of agile software processes: a case study on post-iteration workshops. In:
Eckstein, J., Baumeister, H. (eds.) XP 2004. LNCS, vol. 3092, pp. 184–193. Springer,
Heidelberg (2004). doi:10.1007/978-3-540-24853-8_21
7. Babb, J., Hoda, R., Nørbjerg, J.: Embedding reflection and learning into agile software
development. IEEE Softw. 31, 51–57 (2014). doi:10.1109/MS.2014.54
8. Cockburn, A., Highsmith, J.: Agile software development: the people factor. Computer 34,
131–133 (2001)
9. Dingsøyr, T., Hanssen, G.K.: Extending agile methods: postmortem reviews as extended
feedback. In: Henninger, S., Maurer, F. (eds.) LSO 2002. LNCS, vol. 2640, pp. 4–12. Springer,
Heidelberg (2003). doi:10.1007/978-3-540-40052-3_2
10. Argyris, C., Schon, D.A.: Organisational Learning II: Theory, Method and Practice.
Organisation Development Series. Adisson Wesley, Reading (1996)
11. Osterman, K., Kottkamp, R.: ReflectivePractice for Educators: Improving Schooling through
Professional Development. Corwin Press, Newbury Park (1993)
12. Bain, J.D., Ballantyne, R., Packer, J., Mills, C.: Using journal writing to enhance student
teachers’ reflectivity during field experience placements. Teachers Teach. Theor. Pract. 5, 51–
73 (1999). doi:10.1080/1354060990050104
13. Hoda, R., Babb, J., Nørbjerg, J.: Toward learning teams. IEEE Softw. 30, 95–98 (2013). doi:
10.1109/MS.2013.90
 Reflection in Agile Retrospectives 19

14. Yin, R.K.: Case Study Research: Design and Methods. Sage Publications, Inc. (2003)
15. Braun, V., Clarke, V.: Using thematic analysis in psychology. Qual. Res. Psychol. 3, 77–101
(2006)
16. Jay, J.K., Johnson, K.L.: Capturing complexity: a typology of reflective practice for teacher
education. Teach. Teacher Educ. 18, 73–85 (2002)

Open Access This chapter is licensed under the terms of the Creative Commons Attribution 4.0
International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing,
adaptation, distribution and reproduction in any medium or format, as long as you give appropriate
credit to the original author(s) and the source, provide a link to the Creative Commons license
and indicate if changes were made.
The images or other third party material in this chapter are included in the chapter’s Creative
Commons license, unless indicated otherwise in a credit line to the material. If material is not
included in the chapter’s Creative Commons license and your intended use is not permitted by
statutory regulation or exceeds the permitted use, you will need to obtain permission directly from
the copyright holder.
What Influences the Speed of Prototyping? An Empirical
Investigation of Twenty Software Startups

Anh Nguyen-Duc1 ✉ , Xiaofeng Wang2, and Pekka Abrahamsson1

( )

1
Department of Computer and Information Science (IDI), NTNU, 7491 Trondheim, Norway
{anhn,pekkaa}@ntnu.no
2
Free University of Bozen-Bolzano, Piazza Domenicani 3, 39100 Bolzano, Italy
[email protected]

Abstract. It is essential for startups to quickly experiment business ideas by

building tangible prototypes and collecting user feedback on them. As proto‐
typing is an inevitable part of learning for early stage software startups, how fast
startups can learn depends on how fast they can prototype. Despite of the impor‐
tance, there is a lack of research about prototyping in software startups. In this
study, we aimed at understanding what are factors influencing different types of
prototyping activities. We conducted a multiple case study on twenty European
software startups. The results are two folds; firstly we propose a prototype-centric
learning model in early stage software startups. Secondly, we identify factors
occur as barriers but also facilitators for prototyping in early stage software
startups. The factors are grouped into (1) artifacts, (2) team competence, (3)
collaboration, (4) customer and (5) process dimensions. To speed up a startup’s
progress at the early stage, it is important to incorporate the learning objective
into a well-defined collaborative approach of prototyping.

Keywords: Prototype · MVP · Prototyping-learning loop · Validated learning ·

Speed · Software startups

1 Introduction

With the startup movement, software industry is witnessing a paradigm shift from
serving customer requirements to creating customer value. The challenge for software
companies is no longer primarily on implementing customer requirements, but rather
on finding customer demands and providing a solution that delivers customer value [2].
Addressing uncertainty in both solution and problem domains has often been ad-hoc
and based on guesswork, which becomes one of the main reasons for failing startup
companies [3]. A demand on systematic approaches to manage the uncertainty has led
to an increased research interest on Lean Startup [4], New Product Development (NPD)
[5], software startups [6] and continuous experimentation [7].
In a competitive environment such as software industry, time-to-market is becoming
more and more critical as a success factor for startup companies. Business ideas under
development once revealed can be easily threatened by high speed copycats [9]. More‐
over, competitors can also follow an on-going journey of validating product-market fit

© The Author(s) 2017

H. Baumeister et al. (Eds.): XP 2017, LNBIP 283, pp. 20–36, 2017.
DOI: 10.1007/978-3-319-57633-6_2
 What Influences the Speed of Prototyping? 21

and arrive faster in the destination. Regardless of company sizes and application
domains, the knowledge of influencing factors for a quick learning loop is important for
software startups to form best-fit strategy in developing business experimentation [10].
A ‘Build-Measure-Learn’ loop, as a central concept of the Lean Startup method‐
ology, aims at speeding up the new product development cycle [4]. The central part of
the loop is to build a representation of the business, a so-called Minimum viable product
(MVP), to collect feedback from customers and to learn from that. Steve Blank empha‐
sizes the goal of MVPs is “to maximize learning through incremental and iterative
engineering” [2]. In the startup context, developers quickly and iteratively develop a
software application to validate business ideas [12]. As such, the study of validated
learning can be beneficial from Software Engineering (SE) concepts and practices, such
as rapid prototypes and evolutionary prototypes [13–15]. Consequently, the time-to-
release of prototypes is essential to determine the total time in the validated learning
loop.
Software startup research is increasingly recognized by researcher’s community,
with many practical aspects, such as User Experience, Software practices, competences
and startup ecosystem [6]. Despite of the importance, there is a lack of research about
prototyping in software startups. In a multi-influenced context with funding, human
resource and market concerns, it is crucial to understand how the speed of learning can
be supported by prototyping activities and what are the influencing factors. In a previous
study, we investigated how a prototype is built in software startups [12]. We found that
prototyping activities as a core value of startup experimentation needed to be seen as a
multifaceted phenomenon [12]. In this work, we are particularly interested in the factors
that slow down the learning process and those that speed it up. The research question
(RQ) is:

What factors influence the speed of prototyping in software startups?

The paper is organized as follows. Firstly, we present the background about business-
driven experimentation in software projects, software prototype and a proposal of an
analytical model of startup prototyping (Sect. 2). Then, we describe our research
approach and the cases studied (Sect. 3). After that, the qualitative findings are presented
(Sect. 4). Finally, we reflect on the findings, the threats to validity (Sect. 5), and draw
the conclusion and future work (Sect. 6).

2 Background

2.1 Business Driven Experimentation

From SE perspective, validated learning means the focus on integrating business value
in defining software development processes and practices. Even though experiment
systems are recognized as beneficial to software projects, there are barriers in adopting
them, such as integration of customer feedback, synchronizing vendors in short cycles
and lack of reasoning about customer requirements [16, 17]. Bosch et al. [18] advocate
for adjusting the Lean startup methodology to accommodate the development of
22 A. Nguyen-Duc et al.

multiple ideas and to integrate them when time for their testing and validation is too
long. Bosch suggested using 2-to-4-week experimentation iterations followed by
exposing the product to customers in order to collect feedbacks. Fagerholm et al. present
a model for continuous experimentation for start up companies [7], in which a key
element is the ability to release a prototype with suitable instrumentation, to manage
experiment plans, link experiment results with a product roadmap, and to manage a
flexible business strategy. Olsson et al. present a Hypothesis Experiment Data-Driven
Development model that integrates feature experiments with customer feedback in Agile
projects [19]. While these work characterize a process-like approach in developing
startups’ software products, Paternoster et al. grounded a model from 13 software
startups which describes a pattern that software startups often build evolutionary proto‐
types [20]. This study focuses on how startups are prototyping in reality and the influ‐
encing factors of the speed of learning by prototyping.

2.2 Prototype and Prototyping Activities

Brook mentioned “In software engineering, at least, the concept of rapid prototyping
has a name and a recognized value, whereas it does not always have the same status in
computer design and in building architecture” [21]. Prototyping implies a quick and
economic approach that serves to achieve understanding of what final products should
be [15]. From a technical perspective, prototypes can be differentiated according to its
relation to later product development. Throwaway prototypes are used mainly for spec‐
ification purposes; and they are not used as actual building blocks [15]. They are mostly
used in exploratory and experimental prototyping. Evolutionary prototypes provide a
basis for a real system, which is evolved out of the prototypes; they are used in evolu‐
tionary prototyping but can also be found in experimental prototyping (if it shows that
they provide a good basis for a system) [15].
From a business perspective, startups can create a representation of product ideas, a
so-called MVP, without actual product implementation. Eric Ries describes a classifi‐
cation of different types of MVPs [4], which are commonly used in the startup commun‐
ities. For instance, a MVP can be a short animation that explains what a product does
and why users should buy it. It can also be a user interface that looks like a real working
product, but the actual business process is manually carried out (Wizard of Oz MVP).
A concierge MVP is a manual service that consists of exactly the same steps users would
go through with the product.
A few research paid attention on improving prototyping activities, such as the speed
and effectiveness [28, 29]. Janssen et al. suggested code reuse to speed up writing code
to prototype [28]. Grevet et al. described a 6-stage prototyping approach to speed up
throw-away prototyping for new social computing systems using existing online systems
[29]. In our work, we address the speed of prototyping from a socio-technical perspec‐
tive, considering prototyping activities under human, market, finance and team factors.
 What Influences the Speed of Prototyping? 23

2.3 A Prototype-Centric Learning Model in Software Startups

The Build-Measure-Learn loop is a key concept in Lean Startup [4]. The loop is used
to manage and to operate software startups in finding a sustainable business model. A
key idea is to minimize waste and to focus only on the elements, which will be tested.
Lynn et al. describe another cycle, Probe and Learn, that is applicable to manage uncer‐
tainties about market, technology and time-to-market [25]. The authors suggest that
startups should go to customers with an early version of a product to learn about the
market, different applications and segments. Nguyen-Duc et al. propose a hunter-gather
double loop to capture the evolution of startup activities from idea to achieving a product
market fit [26]. The model visualizes the portion of product development vs. customer
development activities across the startup stages. While these studies provide an emphasis
on organization and evolution, they are well landed in an abstract space, not straight‐
forward to apply from the SE perspective.
In the SE literature, Gordon et al. propose a rapid prototyping system approach to
understand the prototype development of a system [27]. In the model, both low-fidelity
and high-fidelity prototypes are essential parts of developing a system [27]. Preliminary
product design activities create a throwaway prototype from the problem domain. A
series of throwaway low-fidelity prototypes can be created to capture the ideas of what
to built. Similarly, high-fidelity prototypes can also be evolved several times before
reaching the product launch.
A literature survey of software development shows that startups often build a proto‐
type in an evolutionary fashion and quickly learn from users’ feedback [20]. We argue
that both throwaway prototypes and evolutionary prototypes are important parts of
startups’ journey to a launched product. From the Lean startup perspective [4], learning
is an input and also an outcome for a prototype. We tailored the double loop model in
the previous work [26] by adapting Gordon’s system prototyping elements [27] to
capture the prototyping processes in the startup context, as shown in Fig. 1. The model
focus on prototyping as the core concept and compose four loops:
• Idea-prototype loop: iterations of refining business idea through throwaway proto‐
typing
• Throwaway prototype loop: iterations of constructing and learning from throwaway
prototypes
• Evolutionary prototype loop: iteration of constructing and learning from evolutionary
prototypes
• Pivot loop: starting a new cycle from the current product to a pivoted idea
Considering the model as a state-based system, it is possible to travel from a state to
any other one. However, the typical flow would happen within two loops. It can also
happen that a startup starts the loop from any state, for example, by doing a throwaway
prototype before getting to a stated problem. In the scope of this work, we did not go
in-depth about how these loops happen in our cases. The work will explore factors that
occur during the startup progress and influence throw-away and evolutionary proto‐
typing.
24 A. Nguyen-Duc et al.

Fig. 1. A prototype-centric learning model in software startups

3 Research Approach

3.1 Multiple Case Study Design

This study is one part of a larger research activity that investigates the role of engineering
activities in software startups. The objective is to explore commonalities, challenges and
engineering patterns in software startups, from the business idea to a launched product.
This study reports the findings from empirical data regarding prototyping activities. We
conducted multiple case studies for a robust result in typical software startup population
[11]. The unit of analysis is a startup company. We aimed at collecting as many startups
as possible for a variety of the sample. As the aim is to reflect the state-of-practice rather
than finding a secret recipe of success, we included startups in different stages and with
different revenue statuses.
There is often a difficulty in identifying a real startup case among other similar
phenomenon, such as freelancers, SMEs or part-time startups. We defined five criteria
for our case selection: (1) a startup that operates for at least six months, so their expe‐
rience can be relevant, (2) a startup that has at least a first running prototype, (3) a startup
that has at least an initial customer set, i.e. first customer payments or a group of users,
(4) a startup that has an intention to scale their business model, (5) a startup that has
software as a main part of business core value.
The process of identifying and collecting data was done in 11 months, from March
2015 to February 2016. Cases were searched from four channels, (1) startups within the
professional networks of the authors, (2) startups in the same town with the authors, (3)
startups listed in Startup Norway and (4) Crunchbase database. The contact list includes
219 startups from Norway, Finland, Italy, Germany, Netherlands, Singapore, India,
China, Pakistan and Vietnam. After sending out invitation emails, we received 41 feed‐
backs, approximately 18.7% response rate. Excluding startups that are not interested in
the research, or startups that do not pass our selection criteria, the final set of cases are
20 startups, aliased as S1 to S20.
 What Influences the Speed of Prototyping? 25

3.2 Data Collection and Analysis

Semi-structured individual interviews were used to collect data, since they enable the
focus on pre-defined research topics and flexible structures to discover unforeseen infor‐
mation [28]. Methodological triangulation in data collection is also implemented by
using evidence from documents and observations (in S01-S05, S09). Business docu‐
ments, such as business model canvases and business plans were exposed to the research
team as a preliminary step prepared for interviews. Observations were useful to under‐
stand how prototypes were implemented and used in the working environment.
The interviewees were asked questions about (1) business background (2) idea visu‐
alization and prototyping (3) product development (4) challenges and lessons learnt.
The stories about startup ideas, prototypes and product development is organized into
the schema as described in Fig. 1. Most of the interviews were conducted by the first
author, with the attendance of a second researcher (the third author or sometimes external
researchers in our network). This researcher has a long experience conducting interviews
in software companies. Each interview lasted from 55 min to 70 min and the interviewees
were informed about the audio recording and its importance to the study.
We used a thematic analysis – a technique for identifying, analyzing, and reporting
standards (or themes) found in qualitative data [22]. We started by reading all interview
transcripts and relevant documents, and coded them according to open coding [22]. A
set of pre-determined categories were used to guide the coding process, as we have some
interests in topics of (1) business original, (2) prototyping practices (3) pivoting (4)
testing (5) challenges and (6) key performance indicators (KPIs). We attempted to label
all meaningful text segments with appropriate codes. To feed data to this study, we
filtered the codes that are related to prototyping, technical implementation, and testing
activities prior to product launching. According to Sect. 2.2, throwaway prototypes were
low-fidelity artifacts, such as mockup, wireframe, or simple code. Evolutionary proto‐
types were perceived as product building blocks, such as heavy code activities, i.e.
feasibility testing of functionality, building new feature, etc. The relationship of the
factors to the speed of prototyping or production was identified via text about challenges,
or text specifying consequence on time-to-market or time to collect user feedback. We
noted and reported evidence on prototyping as follows (1) factors that relate to proto‐
typing activities in generals, (2) factors that slow down the prototyping activities and
(3) factors that speed up the prototyping activities.

3.3 Case Description

The characteristics of our cases are given in Table 1. It is noticeable that a large number of
the studied cases deliver peer-to-peer services as marketplaces or platforms (S01, S02, S03,
S07, S08, S11, S13, S16, S20). There are also cases that deliver value in Business-to-Busi‐
ness model (B2B) (S04, S06, S10, S12, S15, S17). The cases are dominantly characterized
by web-based and mobile-based software product with client-server architecture. We also
identified the product focuses in early and later phases of the software startups [23]. Among
them, there are some startups with annual revenue of one million euro or more (S06, S09).
26 A. Nguyen-Duc et al.

Regarding the development strategy, interestingly, there are seven cases (35%) that have
(parts of) product developed outside company boundary.

Table 1. Startup cases characteristics

Code Product type Early focus Later focus Dev. strategy No. of prot. Dev. method.
S01 Photo Feature Insource 2 Agile
marketplace
S02 News generator UX New feature Outsource 4 Agile
S03 Homemade food UX Insource 2 Adhoc
market
S04 Construction Simple feature New feature Outsource 5 Distributed agile
management
S05 Underwater Feasible Outsourcing, 7 Informal agile
camera technology subcontracting
S06 Sale visualization UX Flexible, scalable Insource 3 Informal scrum
tool
S07 Location Feature, UX Insource 3 Informal agile
recommendation
S08 Ticket platform Intuitiveness, Scalable and new Outsource 2 Agile
friendliness features
S09 Educational quiz User Scalable, Stable Insource 5 From adhoc to
system friendliness distributed agile
S10 IoT OS platform Ecosystem Functionality Insource 4 NO INFO.
S11 Ticket platform User friendly, More features, Insource 2 Adhoc
simple complexity
S12 Elearning Feature Insource 3 Agile
platform
S13 Shipping services NO INFO. NO INFO. Outsource 3 NO INFO.
S14 News services Feature Platform as a Insource 2+ Continuous
provider service development
S15 Smart grid NO INFO. NO INFO. Insource NO INFO. NO INFO.
application
S16 Secondhand innovative Product line Insource 3 NO INFO.
marketplace feature
S17 Simulation based UX, feature Flexibility, Insource 2+ NO INFO.
training Scalability
S18 Open source Community Feature Open source 4 Adhoc
messenger
S19 Location based UX Feature and Insource 5 Agile
alert system enhanced UX
S20 Elearning system User Standardization Insource 2 Agile
friendliness
*Notation: NO INFO. means missing information

The major reported development methodology is Agile, with iterative deliveries and
frequent customer feedback: “… Scrum based development, sprints of two weeks,
standup, wrap-up meeting, we like to work in this way.” (S06). In some cases, the
company reports a type of informal Agile process: “… fully informal but truly agile
process with working release maintained, … iterative development of functionality and
refactoring” (S05)
 What Influences the Speed of Prototyping? 27

One specific question asked to interviewees is how many prototypes have been made
before product launching. The answers vary from two to seven prototypes, either throw‐
away or evolutionary ones, before a launch. In many cases, we considered prototypes
as a tangible artifact that is experimented with (potential) users, customers and internal/
external stakeholders.

4 Result

Figure 2 describes the influencing elements on throw-away prototyping (detail on

Sect. 4.1) and evolutionary prototyping (detail on Sect. 4.2). It should be noticed that
the direction of impact is not given. Some elements specifically show the positive/nega‐
tive influences while other elements remain as general observations.

Fig. 2. Factors influencing the prototype-centric learning loops

4.1 Elements Influencing Throwaway Prototyping

4.1.1 Adoption of Collaborative Mock-up Tools
By adopting various tools, i.e. paper sketch, GUI mockups and wireframe tools, startups
achieve a fast and an economic prototype without any technical expertise, as described
in (S02, S09, S11, S13). In these cases, startups conducted very short iterations, from a
few days (S02, S11, S13) to a few weeks (S09), from a product or a service idea to
having the first user feedback. In S04, printing GUI layout in papers is reported as a
good practice for teamwork, especially improving the customer involvement: “normally
we draw in the piece of paper first and then we make mock-ups… and then the customer
joins us on that journey, then we click on the paper, we go to another one …” (S04). It
is also common that startups build mockups by using cloud-based software services. For
such an online tool, the teamwork mode is reported as an important feature that facilitates
collaborative design efforts among distributed team members (S02).
28 A. Nguyen-Duc et al.

4.1.2 UX Designer Onboard

Business side of a startup (often CEOs) is always in a need of expressing and visualizing
their ideas into more tangible artifacts. By doing that, sitting next to a designer is highly
desirable for CEOs in early stages. In S02, the CEO expresses the need for a close collab‐
oration with a designer in team: “In this case, I would really like a designer that sits here
together with us …” (S2). The role of a design in mobile application is highlighted in
another discussion with S2: “You might think of user interface as a make-up for a person.
But I think UI is the capacity that an app needs to interact with people.” It happens simi‐
larly in S12, when the CEO mentions about the process of designing the graphical part of
their prototypes: “The alternative is to create a specification … and just developing that
document and all the process around it is typically very resource intensive. We talk about
a future, … we make a prototype at a first phase implementation and then we adjust from
there based on dialogues in between us.” (S12). For frontend-rich applications, a designer
is a champion of the user experience, considering the viewpoint of users and keeping
consistency among graphical elements across different platforms.

4.1.3 Choices of Faking or Building

There are often many uncertainties about customers and their expectations in the early
stages of startups. Starting with a single-feature prototypes, or other approaches with
implementation come always with a risk of wasting effort. It is considered time-saving
to start with a clear mind about the throw-away strategy, by focusing on demonstrating
business value rather than reusing the technical components (S02). Uncertainty about
what to build and how to build often come with quick and dirty experiments without
proper architectural designs, appropriate coding practices and documents. In this
manner, frequent change of requirements or feature requests could lead to the increase
of technical debts in later phase. Experimenting by the development of a runnable
prototype was a costly and time-consuming experience in S09. In this way, the value of
a prototype should exceed its cost. In S03, the development team has a clear plan for
experimenting without “making the product” until they get the right product design. S11
applies the concept of “fake it until you make it”, to simulate a final product without
primary quality, both with functionalities and user experience. However, the focus on
the speed has also led to the minimum part of viability. In S11, customer demonstration
was done in a wizard of oz manner [4], customer interacting with an actual user interface,
but business logics and backend functionality were done by manual work. Even though
it is inefficient, the approach is easy and fast to build.

4.1.4 Collaboration Across Diverged Mindsets

We observed that in most of the cases, the ideas came from the CEOs, who are often
business people or serial entrepreneurs. While the decisions about what the products
should do come from a business mindset, they are implemented by developers with a
technical mindset. In some cases (S01, S04, S05), there are challenges in communicating
the product ideas and convincing the developers about the product value. In S04, it took
as much time to discuss on the value proposition as to sketch a mockup. Vice versa, the
communication of technical difficulties is also a time-consuming task, as mentioned by
 What Influences the Speed of Prototyping? 29

a developer in S05: “She [the CEO] is very sharp about business and finance stuffs, but
it takes a long discussion to explain her about the importance of having flexible product
design …” (S05). The communication challenge might also happen between startups
and customers, when no concrete prototypes are provided: “We work with a customer
organization, learn how they have worked with the current solutions and describe our
proposal via the prototype. It is hard for them to realize the benefit without concrete
examples…” (S04). It also appears that a prototype is late released due to the wrong
estimation of the CEO, who has no technical background. For example, in S1, the CEO
insisted on a customer feedback having a new field in a frontend form, which caused
the change of both business logic layer and data table structure.

4.1.5 Identification of a Right Set of Feedbacks

Steve Blank emphasizes the importance of early involvement of end users in product
development [2]. Particularly, in startups developing products for mass market (or B2C
business model), the feedback from the representative users of a market segment is
essential. Nevertheless, not all users’ input is equally valuable to product development.
It was difficult to find the customer feedback that is useful for validating hypotheses in
S02: “I have attended a various types of events like that. To be honest, there are not so
many interesting things there …” (S02). The CEO wandered in town and talked to
different people about the product idea. However, the approach is quickly found ineffi‐
cient, as the users’ feedbacks are often shallow. After that, the CEO targeted a group of
innovative users from startups and research community and documented many inter‐
esting ideas for the product features. The integration of such lead users, “whose strong
needs will become general in a market-place months or years in the future” [24], appears
to be an important factor to accelerate the speed of startup learning. Lead users are also
able to contribute via suggestions, testing and feedback, or even participate in the devel‐
opment and co-creation of new products or services, as observed in S14: “We always
do that in a close relation to our actual client stakeholders. Once we decide to narrow
it on a new product area, the first thing we do is to get a partnership with a customer
so that we can work together on a daily basis as stakeholders and product devel‐
opers…” (S14).

4.1.6 Fostering Customer Knowledge and Embedding into Prototypes

Prototypes can be seen from three different perspectives, function, look-and-feel and
role, in which role is the representation of usability of the prototype [2]. In order to
maximize lessons learned from a prototype, the vision on how end-users adopt a final
product need to be visualized and captured in the prototype. As the actual end users
are often not well known in the early phases, the integration of the user’s role into the
prototype design is a fuzzy task. The time pressure on prototyping makes startups
skip a detailed analysis of users’ behaviors. It seems that the adoption of customer/
market analysis tools are not so common in our startup sample. In S02, the CEO
emphasized the role of mapping tools, such as a customer journey map to describe the
customer’s experience: “I have been told by my friends about the tool [a customer
30 A. Nguyen-Duc et al.

journey map]. We used it to describe how customer interact with the system and
where could be the gap” (S02).

4.2 Elements Influencing Evolutionary Prototyping

4.2.1 Utilizing Plug-and-Play Components in Prototype
Utilizing ready-made components, such as Open source software (OSS) libraries and
frameworks unlocks the capacity of experimenting functional as well as non-functional
features. The adoption of OSS components was mentioned in all of the cases, from using
tools (S19), integration of OSS code (S02, S03, S05, S20), to participation in OSS
community (S18). The main benefits include reduced development cost and faster time-
to-release, which were mentioned by the CTOs of (S19) and (S20): “…we might not
even come to the idea of making it happen if we do not have OSS as an experiment.
Without OSS it would take a lot of time and very costly” (S19). It is an even more obvious
choice in open source type of platforms: “It is very hard nowadays not to use OSS
artifacts, especially when with Android development …” (S20). It also appears that many
advanced technologies were adopted via using OSS: “A core part of our product includes
a machine learning algorithm. We are lucky enough to find ml library in C++, entirely
OSS, super cool” (S02). By taking ready-made components, startups also reduce proto‐
typing time by simplifying architectural aspects to some existing patterns.

4.2.2 Synchronizing Customer Feedback in Loops

Communication among team members or between a startup company and its external
stakeholders is found as a significant factor delaying an iteration release. Insufficient
communication due to misunderstanding, cultural difference, language barrier, lack of
supporting tools happens often in outsourcing and remote partnership scenarios (S01,
S09): “Basically, we found some limitations that made it difficult to be efficient in the
way to communicate. And since we’re teams in different places it’s really important that
information flow works and also to make sure that all people—don’t have to be involved
in everything, and be able to group efficiently and create like projects, and store docu‐
ments, and all these things, and have video-share links, and articles, and all these
things.” (S09). The misunderstanding and reworking also happens when customers are
distant to developers and the customer feedbacks are not fully perceived. In S13, the
CEO and sales people interacted with customers and collected insightful feedback from
them. However, the feedback is not communicated efficiently to the development team
in other locations. This leads to unnecessary re-work with communication and imple‐
mentation effort and hence slows down the time to release.

4.2.3 Conflicting Feature Requests

It is a typical situation that evolutionary prototypes are built based on feature requests
from the first customers. Gradually, when having more customers, new feature requests
might vary from the business direction or even conflict with the previous functionalities.
S14 describes how they handled such situation: “either we solve them by providing them
different products or we do ignore parts of the market… We make a very clear statement
 What Influences the Speed of Prototyping? 31

to what we think the future of journalism is, then we pursue that and the cost of that is
neglecting parts of our market” (S14). Similarly, S15 expresses how their product
evolved through different iterations: “There will always be requirements arriving…
Sometimes the new requirements disrupt the old requirements. At the moment, we are
working to disrupt the old products” (S15). Considering what to develop and which
features to include adds complexity to future releases. Additionally, requests coming in
the middle of the development sprint from large customers might influence the feature
priority and delay the release further: “We’re in that situation all the time, it’s very
difficult to say no because giant customers telling you we need that functionality. If
you’re going to have us as customers you’re going to have to make it, we need it in the
contract that you have to make it. We also build it, we built it bigger and bigger” (S11).

4.2.4 Feature Creeps

Many startups add new features to fit the prototype to a changing group of early
customers. This leads to two possible challenges of satisfying customer demands, so-
called (1) feature creep and (2) product portfolio. Feature creep refers to the addition of
features to a product in a continuous manner: “We are adding features all the time. This
is not a product that will ever stop evolving. We will always have a strong engineering
team to develop the product forward. We are not talking about maintenance here. We
are talking about this being the core of the company’s competence” (S13). Startups
rarely have a requirement management process to manage product complexity. Conse‐
quently, feature creeps are considered harmful to the production and enhancement of
core features.
Moreover, this can be an unwanted expansion that requires changes also in the
product architecture and even in the strategic direction. In S04, after the first two releases
addressing a construction manager’s requirements, the third release was developed for
a construction operator’s demands. Consequently, S04’s product scope has grown from
a single feature MVP to a supply-chain management system: “So then we had a small
one just for easy communication between users of the building and the maintenance
guys… So the second feature was to manage document flow. And the third was to have
a 3D model of the building. And all these things here we spent a lot of time and we were
building in parallel with different prospects” (S04).
In a larger scale, the expansion could lead to deriving a product portfolio. Startups
face with challenges of keeping both the focus to increase the quality of core delivered
values and satisfaction of important customers. While not all good ideas can be turned
into features, some ideas are selected to develop further and might become the core value
providers for startups.

4.2.5 Solid Technical Competence Onboard

In several cases (S09, S01, S03, S06) the technical competence determines the speed of
feature releasing. Startups’ technical members are required to possess good technical
skills and they also need to be productive in an ambiguous development environment:
“We don’t hire people basically for them being cheap because we don’t have time. Our
challenge is time and to be more productive other kind of competing companies … it’s
32 A. Nguyen-Duc et al.

much better to have people that can—within a short time, could produce good code”
(S09). It is also important to write code in a clean and structured manner, to be quality-
aware in the early phases: “The back end was pretty good because he had hired my boss
at my current company … there was some friction there in how to develop systems
between the professional programmer, my boss, and the copy paste programmers. I
think that also contributed to it not working.” (S11). The combination of technical
competence and customer understanding is emphasized in another case: “… It is very
hard to find people both good at technology and have a good sense of commercial
edge…” (S08).

4.2.6 Dependence on Fast Changing Technologies

Startups often struggle with thriving in a technical uncertainty, whether under market
pull or technology push impacts [20]. Due to different reasons, e.g., specific devices,
platforms or protocols becoming popular in market, or new technology gaining
momentum, there are needs for changing the current product’s features to accommodate
new technology (S01, S09, S11). In a small scale, for instance, the adoption of new
animation effects, a different type of map, etc. leads to an extension of the current or
coming iterations. In S02, the development of an IOS application is delayed after the
codebase and all dependent libraries were forced to be upgraded to a newer version of
Swift. The team took time to resolve all the changes so the next release can be done in
Swift 3.0. The technology uncertainty is expected with mobile applications, as stated by
the CEO of S11: “…at the moment we are changing the technology platform. This
perhaps has been the biggest challenge we have decided where to stand and make a new
platform on development technology… So next generation which will be out in the
market place around summer next year will be quite heavily rearranged.” (S11). In a
large scale, the technical change can lead to a change of business directions.

5 Discussion

5.1 Reflections on the Results

We captured what happened during the early phases of the studied twenty software
startups. We identified the factors that are found to influence the speed of prototyping
across different types of prototypes. They can be grouped into (1) Artifacts, (2) Team
competence, (3) Collaboration, (4) Customer and (5) Process dimensions. Artifacts
include collaborative tools and reusable components. The practices of adopting artifacts
are important for saving time of prototyping user interfaces and functionalities. The issue
here is to select the suitable tools and components to match the prototyping’s purposes.
The requirement of team competence might vary due to the type of prototyping and the
type of products. For instance, UI-rich application would require a designer onboard at
the early stage while a good developer in the later stage. Collaboration, including
efficient communication of visions and tasks among startup teams and interaction with
external stakeholders, is important for shorten the learning loops. Besides, how
customers are involved in the prototyping loops has an impact on the duration of the
 What Influences the Speed of Prototyping? 33

prototyping. While inappropriate customer feedback delays the learning and creates
more prototyping loops, too many requests from customers delay the time-to-release
and introduce complexity to product management. Last but not least, prototyping is
performed under many uncertainty and dependencies. Defining practices and processes
to support decision-making under uncertainties would help in prototyping.

5.2 Threats to Validity

There are several threats to validity worth discussing [1]. One internal threat to validity
is the bias in the data collection, as the data might not represent the comprehensive case.
This is worth discussing as most of the cases are represented by one interview. In order
to mitigate this threat, we selected CTO and CEO as interviewees, who have the best
understanding about their startups. We also use other types of data sources, such as
documents and observations to increase our understanding about the cases (S01 – S05,
S09). The participative observations in S01 and S02 enabled deeper insights that go
beyond cross-sectional interviews. A construct validity threat is the possible inadequate
descriptions of constructs. We tried at our best to collect contextual information about
the startups, from social media and personal contacts. When analyzing data, the coding
process of interview transcripts was assisted by the authors’ prior knowledge about
prototyping and validated learning. This helped to focus on the investigated phenomenon
without losing relevant details.
The external validity is normally not addressed by case study research. Our result is
grounded on twenty cases, with diversity in company size, application domain, financial
model, and growth stage and organization structure, which adds the robustness to our
findings. Many themes, such as Sect. 4.1.1, Sect. 4.2.1, Sect. 4.2.5, Sect. 4.2.6 are
observed in more than half of the cases. Our sample is characterized by Norwegian
software startups, with a small team and bootstrap financing model. We do not consider
other types of startups, for example, internal cooperate startups, venture capital invested
startups, and American startups. Hence, the results cannot be directly applied to other
contexts, though analytical generalization may be possible in similar contexts.

6 Conclusions

To the best of our knowledge, this is the largest multiple case study research about
software startups. Grounded on twenty European startups, we adopted an analytical
framework to reveal different factors that influence the prototyping activities in early
stages of software startups. We found that both throw-away and evolutionary prototypes
were influenced by artifacts adoption approach, available team competence, collabora‐
tion and customer involvement. Even though there is certain limitation in our case
sample, there are still valuable lessons learnt for practitioners. For startups that follow
the Lean Startup approach, it is important to align the learning objective with a collab‐
orative and well-defined approach of prototyping. Moreover, startups need to find a
systematic approach to integrate relevant external feedback in all phases of prototyping.
34 A. Nguyen-Duc et al.

This work does not address the evolution of startups according to the learning loops,
i.e. what are lessons from idea to throw-away prototype, what are lessons from switching
from throw-away prototypes to evolutionary ones. Besides, future work can investigate
different types of learning brought by different types of prototypes. This work addressed
validated learning through an important angle, which is the speed of prototyping loops.
In the future work, we will explore another equally important aspect, which is the quality
of learning. Further studies might also identify the effective prototyping and develop‐
ment patterns among software startups.

References

1. Runeson, P., Höst, M.: Guidelines for conducting and reporting case study research in software
engineering. Empirical Softw. Eng. 14(2), 131–164 (2009)
2. Blank, S.: The Four Steps to the Epiphany: Successful Strategies for Products that Win, 2nd
edn. K & S Ranch Press (2013)
3. Giardino, C., Wang, X., Abrahamsson, P.: Why early-stage software startups fail: a behavioral
framework. In: Lassenius, C., Smolander, K. (eds.) ICSOB 2014. LNBIP, vol. 182, pp. 27–
41. Springer, Cham (2014). doi:10.1007/978-3-319-08738-2_3
4. Ries, E.: The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create
Radically Successful Businesses. Crown Business, New York (2011)
5. Cooper, R.G.: Stage-gate systems: a new tool for managing new products. Bus. Horiz. 33(3),
44–54 (1990)
6. Unterkalmsteiner, M., Abrahamsson, P., Wang, X., Nguyen-Duc, A., Shah, S., Bajwa, S.S.,
Yagüe, A.: Software startups: a research agenda. e-informatica. Softw. Eng. J. 10(1), 89–123
(2016)
7. Fagerholm, F., Guinea, A.S., Mäenpää, H., Münch, J.: The RIGHT model for continuous
experimentation. J. Syst. Softw. (2016)
8. Houde, S., Hill, C.: What do prototypes prototype. In: Helander, M., Landauer, T., Prabhu,
P. (eds.) Handbook of Human-Computer Interaction, 2nd edn. Elsevier Science (1997)
9. Accessed 1 Dec 2016. http://qz.com/771727/chinas-factories-in-shenzhen-can-copy-
products-at-breakneck-speed-and-its-time-for-the-rest-of-the-world-to-get-over-it/
10. Cohen, M.A., Eliasberg, J., Ho, T.H.: New product development: the performance and time-
to-market tradeoff. Manage. Sci. 42, 173–186 (1996)
11. Yin, R.K.: Case Study Research: Design and Methods, 4th edn. Sage Publications Inc,
Thousand Oaks (2008)
12. Duc, A.N., Abrahamsson, P.: Minimum viable product or multiple facet product? The role of
MVP in software startups. In: Sharp, H., Hall, T. (eds.) XP 2016. LNBIP, vol. 251, pp. 118–
130. Springer, Cham (2016). doi:10.1007/978-3-319-33515-5_10
13. Lichter, H., Schneider-Hufschmidt, M., Züllighoven, H.: Prototyping in industrial software
projects-bridging the gap between theory and practice. IEEE Trans. Softw. Eng. 20(11), 825–
832 (1994)
14. Floyd, C.: A systematic look at prototyping. In: Budde, R., Kuhlenkamp, K., Mathiassen, L.,
Zullighoven, H. (eds.) Approaches to Prototyping, pp. 1–18 (1984)
15. Beaudouin-Lafon, M., Mackay, W.E.: Prototyping development and tools. In: Jacko, J.A.,
Sears, A. (eds.) Handbook of Human-Computer Interaction, Revisited edn, pp. 1006–1031.
Lawrence Erlbaum Associates, New York (2007)
 What Influences the Speed of Prototyping? 35

16. Karvonen, T., Lwakatare, L.E., Sauvola, T., Bosch, J., Olsson, H.H., Kuvaja, P., Oivo, M.:
Hitting the target: practices for moving toward innovation experiment systems. In: Fernandes,
J.M., Machado, R.J., Wnuk, K. (eds.) ICSOB 2015. LNBIP, vol. 210, pp. 117–131. Springer,
Cham (2015). doi:10.1007/978-3-319-19593-3_10
17. Sauvola, T., Lwakatare, L.E., Karvonen, T., Kuvaja, P., Olsson, H.H., Bosch, J., Oivo, M.:
Towards customer-centric software development: a multiple-case study. In: 41st Euromicro
Conference on Software Engineering and Advanced Applications (2015)
18. Bosch, J., Holmström Olsson, H., Björk, J., Ljungblad, J.: The early stage software startup
development model: a framework for operationalizing lean principles in software startups. In:
Fitzgerald, B., Conboy, K., Power, K., Valerdi, R., Morgan, L., Stol, K.-J. (eds.) LESS 2013.
LNBIP, vol. 167, pp. 1–15. Springer, Heidelberg (2013). doi:10.1007/978-3-642-44930-7_1
19. Olsson, H.H., Alahyari, H., Bosch, J.: Climbing the “stairway to heaven”: a multiple-case
study exploring barriers in the transition from agile development towards continuous
deployment of software. In: 38th Euromicro Conference on Software Engineering and
Advanced Applications (2012)
20. Paternoster, N., Giardino, C., Unterkalmsteiner, M., Gorschek, T., Abrahamsson, P.: Software
development in startup companies: a systematic mapping study. Inf. Softw. Technol. 56(10),
1200–1218 (2014)
21. Brooks, F.P.: The Design of Design: Essays From a Computer Scientist. Addison-Wesley
Professional, Boston (2010)
22. Boyatzis, R.E.: Transforming Qualitative Information: Thematic Analysis and Code
Development. Sage Publications, Thousand Oaks (1998)
23. Nguyen-Duc, A., Shah, S., Abrahamsson, P.: Towards an early stage software startups
evolution model. In: 42nd Euromicro Conference on Software Engineering and Advanced
Applications (2016)
24. Von Hippel, E.: Lead users: a source of novel product concepts. Manage. Sci. 32(7), 791–805
(1986)
25. Lynn, G.S., Morone, J.G.: Marketing and discontinuous: the probe and learn process. Calif.
Manage. Rev. 38(3) (1996)
26. Nguyen-Duc, A., Seppnen, P., Abrahamsson, P.: Hunter-gatherer cycle: a conceptual model
of the evolution of startup innovation and engineering. In: 1st Workshop on Open Innovation
on Software Engineering, ICSSP (2015)
27. Luqi, F.K.: An introduction to rapid system prototyping. IEEE Trans. Softw. Eng. 28(9), 817–
821 (2002)
28. Jansen, S., Brinkkemper, S., Hunink, I., Demir, C.: Pragmatic and opportunistic reuse in
innovative start-up companies. IEEE Softw. 25(6), 42–49 (2008)
29. Grevet, C., Gilbert, E.: Piggyback prototyping: using existing, large-scale social computing
systems to prototype new ones. In: 33rd Annual ACM Conference on Human Factors in
Computing Systems; Seoul, Republic of Korea, pp. 4047–4056 (2015)
36 A. Nguyen-Duc et al.

Open Access This chapter is licensed under the terms of the Creative Commons Attribution 4.0
International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing,
adaptation, distribution and reproduction in any medium or format, as long as you give appropriate
credit to the original author(s) and the source, provide a link to the Creative Commons license
and indicate if changes were made.
The images or other third party material in this chapter are included in the chapter’s Creative
Commons license, unless indicated otherwise in a credit line to the material. If material is not
included in the chapter’s Creative Commons license and your intended use is not permitted by
statutory regulation or exceeds the permitted use, you will need to obtain permission directly from
the copyright holder.
 Key Challenges in Agile Requirements Engineering

Eva-Maria Schön1,2 ✉ , Dominique Winter3, María José Escalona1,

( )

and Jörg Thomaschewski3

1
University of Seville, Seville, Spain
[email protected], [email protected]
2
CGI Deutschland Ltd. & Co. KG, Hamburg, Germany
3
University of Applied Sciences Emden/Leer, Emden, Germany
[email protected],
[email protected]

Abstract. Agile Software Development (ASD) is becoming more popular in all

fields of industry. For an agile transformation, organizations need to continuously
improve their established approaches to Requirements Engineering (RE) as well
as their approaches to software development. This is accompanied by some chal‐
lenges in terms of agile RE. The main objective of this paper is to identify the
most important challenges in agile RE industry has to face today. Therefore, we
conducted an iterative expert judgement process with 26 experts in the field of
ASD, comprising three complementary rounds.
In sum, we identified 20 challenges in three rounds. Six of these challenges
are defined as key challenges. Based on the results, we provide options for dealing
with those key challenges by means of agile techniques and tools. The results
show that the identified challenges are often not limited to ASD, but they rather
refer to software development in general. Therefore, we can conclude that organ‐
izations still struggle with agile transition and understanding agile values, in
particular, in terms of stakeholder and user involvement.

Keywords: Agile Software Development · Requirements Engineering ·

Challenges · Agile RE · Stakeholder and user involvement · Human-Centered
Design

1 Introduction

Agile Software development (ASD) gains in popularity in today’s business world due
to enabling immediately changes in the direction of product development. These short-
term changes in direction require a flexible approach to Requirements Engineering (RE)
as well. In addition, agile methodologies (such as Scrum [1], Kanban [2] or Extreme
Programming [3]) are often combined with Human-Centered Design (HCD) [4] activ‐
ities in order to emphasize a value-driven approach to product development [5, 6]. To
this end, the field of agile RE has emerged during the last decade.
Focusing on user needs and value delivery becomes an important aspect in product
development due to the increasing competition in all areas. With regard to ASD, plan-
driven organizations moved away to value-driven organizations. On the one hand,

© The Author(s) 2017

H. Baumeister et al. (Eds.): XP 2017, LNBIP 283, pp. 37–51, 2017.
DOI: 10.1007/978-3-319-57633-6_3
38 E.-M. Schön et al.

people in plan-driven organizations often negotiate about project plans, pricing models
and the amount of features they can develop with the available resources. They are
emphasizing the generated outputs such as number of created features during a time
period. On the other hand, people in value-driven organizations discuss visions, expe‐
riences and human values as well as the way to address them through the product. They
focus on the outcomes that the delivered outputs entail.
Compared to sequential approaches to RE, which comprise a requirement analysis
phase before the development can even begin, agile RE is carried out along with the
development itself. Therefore, continuous management of requirements is a crucial
attribute. Requirements are regularly described from a user perspective in the form of
epics and user stories [7] instead of creating a requirements document [8]. Recent
research is showing that there are several ways of running RE in an agile environment
while involving users and stakeholders [5, 9–12].
Performing agile RE can lead to challenges organizations have to deal with. In liter‐
ature, there can be found some studies investigating challenges in agile RE (see [11–
15]). However, the related work still lacks in giving a general overview of the challenges
in current industry.
This study pursues the main objective of identifying the most important challenges
in agile RE industry has to address today. We aim to build a shared understanding
concerning these challenges among voices that matter by means of experts in the field
of agile RE. Thus, the research questions we pose are listed below:
– RQ1: What are the key challenges in Agile Requirements Engineering?
– RQ2: How can we deal with the identified key challenges?
The paper is structured as follows: Sect. 2 briefly summarizes the related work and
points out the research gap. Section 3 presents the applied research method and describes
the iterative expert judgement process. Then, Sect. 4 identifies the findings and discusses
both on their meaning and on the limitations of this study. Finally, Sect. 5 provides the
conclusions as well as an outlook on future research.

2 Related Work

There are related studies in the literature that investigate challenges in agile RE by means
of different research methods. Table 1 shows an overview of the reported challenges and
used research methods.
Analyzing the related work, we can state that the authors use two different kinds of
research approaches in general. On the one hand, Ramesh et al. [13] and Bjarnason et al.
[14] utilize case studies to investigate the challenges in the field. On the other hand,
Inayat et al. [11], Heikkila et al. [15] and Soares et al. [12] report challenges in agile RE
by analyzing primary studies with the aim to identify available evidence in existing
research.
Exploring the Variety of Random
Documents with Different Content
there next morning, but my ivory amulet I could not find; it was
gone, and with it, I knew, my salvation."
"That is all?" I asked the Second, as he stopped to wipe the sweat
from his forehead.
"All—at present," he answered, "for we sailed that same morning.
And I have never seen her since. And I never shall see her," he
added, in a tone that made me feel cold to hear.
"But you kept the stone?" I asked again.
"I could not get rid of it," he replied. "Once—you may believe me or
not, as you like—once, I took it from my waistcoat pocket and threw
it over the bulwarks. It did not touch the sea; next morning it was
there again in my pocket. So I made the best of what I knew was a
bad job; I got it mounted in London in a ring, and I wear it so in
defiance."
There was more of fear than defiance in his eyes just then; he
swung on his heel and turned away; nor did any further allusions to
the subject pass between us.
We reached Singapore shortly afterwards; and I noticed the Second
Mate getting more and more nervous. He tried to hide it and to
conquer it, he worked harder than any man on the boat.
At last we had got our cargo in and had finished coaling; the next
morning we should (machinery permitting) clear out for home. The
Second seemed easier that evening, but he had scarcely been in my
cabin half an hour when a convulsive spasm seemed to shoot
through him. He stood up, as if in agony, and cried out in a thick
guttural voice: "I've got to go," and made towards the alley-way.
I tried to stop him; he dragged me along as easily as if I had been a
child. Then, nearing the gangway, he shook me off and cried: "You
had better keep out of it; I shall be enough," and passed over the
gangway to the quay.
I went after him, just speaking to the watchman; yet even this delay
put me far behind, and I had to run to overtake him, so quickly did
he walk.
At last we reached the house, and the room he had described: he
ordered liquor, which I took care not to drink; and in desperate
defiance let his hand lie on the table, stretching out the finger that
held the ring.
Strive as I might to keep my head clear, I felt the fumes of the place
suffocating me; yet, stupefied as I was, I had a consciousness that
myriad eyes were around and watching us.
Below, through the hole where the ladder went, I saw the opium
smokers; at the back where the staircase mounted, I saw the door
open.
A woman entered, and at once the place seemed empty, save for
her and us.
The Second was looking too, and started suddenly. He got up and
walked towards her and threw her heavy veil aside. Then, in a voice
so calm that it astonished me, he said—
"You are not Flower of the Cinnamon?"
"No," she answered, "the Flower is not. But when she was, she was
my sister."
And she pressed forward towards me. "I am called," she said, to me,
not to him, "I am called the Sheen of Morning." And she made a low
obeisance towards me.
I did not speak, but looked towards her, looked passed her and saw
into the cellar. I saw a man, dark-skinned, yet no Hindoo, kindle a
fire on the ground; and as the flames leaped red, he sprinkled a
powder on them and the fire burnt green, and the smoke came
through the opening.
The woman was still bowed before me and watching me with
entreating eyes; but now the lustre went out of her eyes and they
had no more life in them than a sleep-walker's. Then she rose stiffly
and walked backward to the staircase door and so passed through;
and the door shut of itself, for I saw no one to shut it.
And the man, or devil, in the cellar put more powder on his fire, and
the flames burnt red, red as a bullock's blood. And the Second
turned slowly round and walked from the room into the street; and,
looking neither to the right nor the left, took his way still further
across the marsh. And I followed, shivering in my heart.
Nothing before or around us but the darkness and the heat of the
night that brought up the fever-fog; and from the distance came the
horrid noise of a Chinese sing-song.
And we still walked on, till, in the darkness of the night, there
loomed another darkness, thicker and more compact: and I saw it
was the shadow of a pagoda.
The Second led the way right to the entrance; as we reached the
threshold, a light sprang up within.
The Second was mounting the steps; I seized his arm and with my
whole force tried to retain him; he did not even pause, but dragged
me after him as if my strength were nothing. And so we went into
the temple.
The light shone from the other end: we drew closer to it and stood
in front. There, on a shrine, was an enormous figure of Buddha,
sitting cross-legged, with six arms extended. The light shone from
his eyes; and, glancing along his nostrils, on one side sparkled back.
In his nose was a jewel the duplicate of that the Second wore; on
the other side was a space for a second jewel, which was the
Second's.
As I looked, I cried aloud and started back; my hand was still on the
Second's arm, and so great was my terror that I drew him back with
me a space. At that moment the pavement in front of us opened
where but an instant before we had both been standing; and in the
void revealed, I felt and smelt, rather than saw, the fœtid moisture
of a bottomless water-pit. And the light in the idol's eyes burnt red.
A little finger touched my left hand: I turned. It was a woman, the
same woman of the hut; who whispered, so that none but I could
hear—
"Come, my lord, and quickly. Leave him to his fate, for he is
doomed. But thou, while there is yet time, come."
"Yes," I said to her; "but not alone. He must come too."
"Does my lord command it?" she asked.
"Yes," I said again.
"Then I will try," she whispered; "yet it is Death we three look in the
face."
She raised her hand and rubbed my lips with something she held,
something that was cold like menthol, and bitter as gall. She did
likewise to the Second, who at that seemed to awake from sleep and
stare about him bewildered. And taking me by the hand, and I the
Second, she led us to the door; and the door was shut and barred,
and the light in the idol went out.
"There is another way," she said at last, and led us on; till behind a
pillar she stopped and stooped, and, groping for some time, found at
last a rude staple in the stonework.
"Pull," she said, "for you are strong." And I pulled, and the stone
came round on invisible hinges. In the opening there disclosed I felt
rough-hewn steps that went down, and pushing myself through I
descended. Three steps I counted, and then there were no more;
and I lost my hand-hold and fell. I threw out my hands wildly in
search of some support; my head swung forward and struck against
a projection; and, insensible, I still fell—down, down....
When I came to myself I was lying on the ground, my head in the
woman's lap; and her hair had torn loose and was swathing my
temples; and as she bent to kiss me, I felt that her eyes were wet.

"HE DRAGGED ME ALONG AS EASILY AS A CHILD."

But between her and me came the memory of Mary, and the
promise the moon had seen at Rockhampton; and I did not kiss her
back, but took her hand, and said, "My sister, my sister." And so she
understood, and raised me up, and put something on my head that
cured its aching; and the Second came to my side and held me, and
we went on down the passage.
There was no light to guide us; but the walls shone with
phosphorescent drawings, and all the vile gods of Buddha's
Pantheon served us as horrid guides. We went on—the woman in
tears, I in pain, and the Second in terror and dismay—till there came
some rough-hewn steps, and these mounted, some stairs of wood;
there the woman left us and bade us wait.
Presently she returned and led us still upward, and lifted a flap and
let in a flood of light. And springing through, we were in the room of
the grog-shop—all alone, save for the invisible eyes that I knew
were watching us all around.
And we sat at the table; and I gave my hand to the woman, and
said again, "My sister," and she fell to weeping afresh.
I looked towards the Second, and his brow was wet with sweat, and
on his finger gleamed ominously the cursed stone.
I tried to get the ring off. It clung till with a wrench I had twisted it
and had it off, and left his finger free; and then, before the woman
could prevent me, had put it on my own. At that she shrank,
shivering; but I knocked the table loudly in summons.
 "I PULLED, AND THE STONE CAME ROUND ON INVISIBLE
HINGES."
A coolie came in, and I ordered two bottles of Bass; but in knocking
and ordering and talking I took care to show my ring. He saw, and
smiled maliciously; and coming back with the beer looked again. The
woman had disappeared, spirited away again by some invisible
power.
So the Second and I drank—he hugely, I scarcely at all. And then I
told him my scheme: that he must go back to the ship alone, for
without the ring I felt he had nothing to fear. He was reluctant to do
so, for he was a brave man; yet his terror was so great that in the
end he departed.
So I was left alone with the ring; and waiting till I thought it time,
began to reproach myself for running in danger when my life
belonged to Mary. Then I thought again: and I knew at last that
Mary herself would have me to do this. So I kept up a stout heart,
and ostentatiously leaving a dollar on the table, passed out.
There was a shadow in front of me—it was the woman, who fell at
my feet beseechingly.
"Fool," she said, "and foolhardy. Throw it away lest it kill you. For it
is a vampire that drinks men's blood."
And she took hold of my finger and tried to wrench the ring away;
but the flesh was closed up tightly round it, and it would not budge.
"It is the spell already winding round you," she said. "Yet it was not
you that my father cursed. What shall I do, my love, my love?
"Better throw away your finger than your soul," she said again; "cut
it off and so escape."
I searched for the knife in my belt, but my sheath was empty; and
we looked into each other's eyes in hollow despair.
"I would bite it," she cried, "but I cannot—I cannot; for I love you."
"You must not say that," I answered; "and you must not come with
me."
"My lord commands?" she asked, in pained humility.
And I said "Yes." And she disappeared into the darkness.
I strode on quickly across the swamp towards the quay, and already
I saw the lights gleam in the harbour. Yet even now I could not feel
at ease, and would glance round furtively and yet see nothing—until
suddenly the moon shot out from behind a cloud, and in front of my
eyes was a gleam that was not of light, but a reflection of light. I
quickly put out my left hand, and jagged steel pierced it, and I
shrieked aloud.
With my right hand I seized my assailant, who was anointed with oil
and slipped through my fingers like an eel. Yet he did not run, but
remained at a little distance, waiting to attack me again, and there
were others with him. By their stiffened upright black hair I saw they
were Malays; but the one who seemed their leader was the devil of
the cellar. And my heart thumped and thumped, as I waited.
Then a soft hand again touched me, and a voice said, "It is I," and
the woman had taken my finger that held the ring, and saying, "Yet
I must do it, because I love him," had bitten it clean through. And
shouting to the men in a tongue I knew not, she hurled it in their
midst; and their leader seized it, and yelled aloud in triumph, and
showed it to the others running round him.
And the woman spoke again, and to some purpose, for then the
men departed with the prize. And the moon went in again behind
the clouds.
"Do not slay me, my lord," the woman was saying, "for your life is
not yet saved."
She tore the veiling from her face and bandaged the stump that had
been my finger; and then she took my other hand, and, withdrawing
the dagger, sucked softly at the poison of the wound. But the pain
was too much for me, and I just leaned over and fell fainting to the
ground.
Next morning, I found myself in my bunk, and the Second was
watching over me, and the woman was crouching on the floor.
"That's right, old man," said the Second, "and now I'll fetch the
doctor."
The doctor was the chief engineer, who forthwith came aft with a
hot iron and seared the stump of my finger.
"And now, laddie, ye'll do," he said; "and I must awa, for there is
some leetle difficulty with the boilers."
"She carried you
here," said the
Second,
answering my
eyes, "though
how she
managed it I
can't say. And
she had sucked
the poison clean
from your
wound, and Mac
said there was
no danger left.
Though, mind
you, the kriss
had enough on it
to kill twenty
men.
"Yes," he went
on, "I'm all right,
and you shall tell
me how it
happened to you
afterwards. Now
you must "TAKING THE FINGER THAT HELD THE
swallow this RING, SHE BIT IT CLEAN THROUGH."
sleeping draught
Mac's left for
you."
And I swallowed the medicine he gave me.
But I did not sleep; I fell into a stupor. I could not move or speak;
yet I could hear and understand.
The sailors were clearing the decks above me; at intervals the steam
whistle sounded; we were preparing to get under way.
At last came the cry, "All strangers leave the ship," and there was a
bustle across the gangway.
The woman in the corner rose, came to my bunk and kissed me on
the lips, opened the door, went into the alley-way and on to the
deck. She mounted to the poop above my head, then a shadow
passed for a moment athwart my port-hole. I heard a splash—and
she had done suttee for her love of me.
The blade of the propeller began to revolve, and the ship to forge
slowly forward. My tongue was parched and my temples throbbing,
and the delirium of fever came over me.
My eyes still open looked far away forward, into the pagoda of
Singapore. And before the Buddha knelt the throng of worshippers,
and the idol looked down upon them in content and triumph, and in
his nostrils were now the catseyes, sparkling on either side. And a
shadowy form that I knew for the ghost of the woman came before
the god and fell prostrate, and lay there praying for me; and the idol
did not frown, but gazed still content; and I knew that the curse was
lifted from me.
Then my eyes could close, and the fire went from them, and the
darkness came and gentle sleep.
The next thing I knew was that Mac was pouring quinine down my
throat, and we were out at sea and the sun was shining. And at
Aden, where we coaled, was a letter from Mary; and I was well
again.
The Second met the fate he feared. You know from the papers how
the voyage ended; no one knows, and only I can guess, how it came
to end as it did. It was off Ushant, almost in sight of home. The
Second had the watch. The moon was at its full; there was not a
cloud to cast a shadow. The man at the wheel saw a huge rock loom
 on the starboard bow. He veered off
a point to give it a wide berth; the
Second came towards him and took
the wheel himself. And then, the
man declares, he headed straight for
the rock, his eyes fixed intently in
front of him, his hands a-tremble
with unavailing fear. The man
thought he was mad, and tried to
tear the spokes away; the Second,
with strength almost supernatural,
with one hand lifted him up, and
hurled him to the lower deck. Then
the ship forged on, straight to the
rock ahead.
The boats were lowered and quickly
filled, and were casting off. I sprang
up to the bridge—I touched the
Second's arm and took his hand in
mine.
As I hurried him down the gangway
and across the forehold, a boom of
the winch pinned him to the deck
and he could not move.

"SHE MOUNTED THE Then, as I live, I saw a woman—a

POOP AND JUMPED INTO black woman—holding him in her
THE WATER." arms, holding him down. There came
a rush of water. The vessel slid back
into the trough of the sea. The woman kissed him—he shrieked
aloud—and the waves sucked them in together.
The curse of the catseye was completed.
 MICE WORTH THEIR WEIGHT IN
GOLD.
SOME EXTRAVAGANT PETS.

By Gavin Macdonald.

Most of us kept mice in the days of our childhood. They were always
white with pink eyes, and our elders objected to them tooth and
nail.
Without warning, the mouse fancy has sprung into general
popularity, and the craze for rearing and showing the tiny creatures
has assumed the proportions of an important and fashionable hobby.
There is a National Mouse Club, a National Mouse Show, and a
hundred others of less importance. Nor is there lack of prizes. The
Mouse Challenge Bowl is a trophy worthy of consideration by a
Derby winner; and there are pots and medals and specials galore for
competition by enthusiastic members of the fancy.
 THIS MOUSE IS
INVESTIGATING OUR
PHOTOGRAPHER'S FLASH-
LIGHT APPARATUS.
A first visit to a famous collection is likely to occasion considerable
surprise to those who are only familiar with the white and pink-eyed
variety and the common little grey-backed member of the
household.
During the last two or three years various fanciers have been
industriously endeavouring to improve the breed, and they have
succeeded in producing the most beautiful specimens. The show
mouse is larger than the common household specimen. The eye is
much larger and fuller, and the coat would not disgrace a
thoroughbred racer. But the chief points are colour and marking.
These are simply wonderful. The self colours include not only black
and white, but almost every shade between. The black specimens
have rich silky coats. The white to be at all valuable must possess
black eyes. The pink eye has been eliminated altogether.
 (1) MOUSE CHALLENGE CUP. (2) A
MOUSE WITH TWO TAILS. (3)
HOW A LADY FANCIER FEEDS HER
PETS, AND (4) HOW SHE PLAYS
WITH THEM.
Sables exist in every possible shade, and some of them are of the
richest and most beautiful quality. Silver grey is a fashionable colour
this year, and I have seen some very perfect specimens with bluish-
grey coats.
The marked mouse is a most popular fancy, and no wonder, for in
this department the most wonderful results have been obtained, as
our illustrations prove.
At the present moment a well-known lady fancier is striving to obtain
a Dalmatian mouse. She has already a most wonderfully spotted
specimen, and hopes before long to show a perfect example.
Apart from their great beauty, fancy mice pay, and pay well. At the
National Mouse Show I was shown several specimens worth £5
apiece, and as much as £20 has been given for a champion. The two
mice in our picture of judging are both £5 animals.
Another thing about them is that they are practically all profit. The
bread and milk and occasional hemp seed upon which they live is
used in such small quantities that an expenditure of 6d. per week
will suffice to keep dozens.
Then there are many fanciers who make a lot of money out of their
young mice. A working man in the North of England, who is an
ardent fancier, makes no less than £15 per annum in this way,
besides an occasional pound or two for an extra-promising
specimen.
Many fanciers have very large collections. The secretary of the
National Mouse Club possesses some 2,000 in his cages, and I know
at least half a dozen others whose collections range between two
and five hundred. At one day old the mice are little pink objects
scarcely longer than a wax vesta, minus sight and minus coat. I saw
a litter of this age in Staffordshire some time ago. A fortnight later
they were in full war paint, and were winning prizes at a big show in
the "under eight weeks" class. It is well that they develop so quickly,
since at two years they get ill and out of condition and are usually
destroyed.
There are many collections in this country valued at £30, and I know
of one for which £100 has been offered and refused.
As with other fancy animals, the best specimens are selected from a
litter and the rest are drowned. The selected mice are reared with
the greatest care, and as soon as they are of the right size and age
they commence the round of the shows. At home they are kept in
immense tenement cages, divided into tiny compartments for two,
but they travel to the shows singly in special exhibition cages.

"MATCHLESS," THE CHAMPION MOUSE—SHOWING HOW

THE JUDGING IS DONE.
These exhibition cages are packed together in a live-stock box, and
on their arrival at their destination are taken charge of by special
stewards, who see to the feeding arrangements and place them in
their right classes.
Great interest is taken in the judging of these tiny creatures, and the
judge is always surrounded by an eager crowd of spectators. Usually
he contents himself with a glance in the box, shaking it up if the
occupant is of a lazy disposition. When it comes to taking stock of a
particularly good exhibit the mouse is taken out of the cage and
examined.
They are always lifted and held by their tails during this examination.
In the case of it being necessary to compare two competitors, they
are held on the sleeve as illustrated in our photograph of judging.
In this picture, Mr. Richards of Dursley, Gloucestershire, is seen
judging two specially fine specimens, the mouse to the left being Mr.
Singleton's famous champion "Matchless," one of the most perfect
show mice living.
The border on the first page of this article is entirely composed of
photographs of show animals, and gives a very good idea of the
beautiful markings so much sought after by fanciers.
Miss Grimston owns a famous collection, which she keeps at her
house in Mayfair. Each mouse is named, and the idiosyncrasies of its
character are well known to its mistress. Two fine specimens are
shown sitting on her hands. The mouse on the ladder is also hers.
This lady possesses a unique playground, fitted with a tiny
gymnasium. The young mice are turned into this for exercise and
play. It keeps them in health and coat, two very necessary
conditions for show purposes.
Miss Grimston is a particularly successful exhibitor, having captured
some dozens of prizes, including cups and medals. Her collection at
the present time contains some forty show specimens. They are
rarely home for long together. As soon as they return from one show
they are off to another.
 "WHEN THE CAT'S AWAY, THE MICE WILL PLAY."
The exhibition cages shown in the illustration at the foot of this page
are a representative collection.
Although more or less of regulation size, shape and ornamentation
are left to the individual taste of the fancier.
As a result, many of them are extremely decorative, poker-work
sketches and other novel methods of adornment being commonly
resorted to.
Many fanciers make their own cages and live-stock boxes, and
combine the mouse fancy with amateur carpentry. One fancier who
is his own carpenter has received so many applications for the
address of the maker of his exhibition cages, that he has taken up
cage-making professionally, and makes over £50 per annum in his
spare time by the sale of his handiwork.
It is needless to say that cats are unknown in the establishments of
show mouse owners, and show committees have to exercise the
greatest care in order to exclude cats from the exhibition rooms.
It is a capital hobby, full of interest and fascination.

SOME OF THE MICE CAGES AT THE NATIONAL SHOW.

 A CROWDED HOUR
A COMEDY OF THE STREETS.

By Clarence Rook.

Illustrated by B. E. Minns.

Very few people knew what really caused the crowd which collected
so suddenly one evening in front of a house in the neighbourhood of
High Street, Kensington—to be precise, in Lower Phillimore Place—
and practically blocked the traffic in that busy thoroughfare.
The crowd itself had no clear notion of the cause of its coming
together. For in order to produce a crowd it is by no means
necessary that the individuals who are to compose it should have
any reason for their assembling more definite than the fact that
there is an assembly.
Primarily, however, it was Esther who was the cause of the crowd.
Esther, who you must know is my sister, had been growing quite
prosperous. After a year or so of hard and unremunerative work,
Esther had gained a position on the staff of a leading ladies'
newspaper; and thereafter, week by week, Esther produced pictures
of attenuated ladies with crooked forefingers, attired in the height of
fashion, and pretending that their waists did not hurt them the least
bit.
So, finding herself with an assured income which, if not large, was
adequate to her modest needs, Esther determined to quit her dingy
lodgings in a Bloomsbury side-street and furnish a dwelling for
herself. In this project she was encouraged by her bosom friend
Susie, who, being a certificated nurse with a private practice, wanted
a comfortable home in the intervals between her cases, and was
willing to contribute some furniture and a share of the expenses.
After much search among the advertisements in the newspapers in
the Free Library, followed by hurried rushes on her bicycle to the
uttermost ends of London, Esther found a house in Lower Phillimore
Place of which two floors and the basement were to be let
unfurnished. It was precisely the sort of place the two girls wanted,
and as the rent was reasonable Esther at once arranged to take it.
Esther was to occupy the ground floor, the first floor would be
reserved for Susie whenever she required it; in the basement a
respectable woman would live, and cook, and sleep. Esther began to
look about for the respectable woman.
It was only then that Esther suddenly bethought herself of the
extreme danger of sleeping—a solitary and unprotected woman—
upon the ground-floor of a London house. For an hour or so the
difficulty seemed insurmountable, and it appeared to Esther that she
must cancel the agreement. I suggested a dog. But, as Esther at
once pointed out, a determined and unscrupulous murderer would
not hesitate to poison a dog.
Then I proposed that a respectable married couple should be
engaged. Probably, in consideration of living rent free, the woman
would do the housework during the day, and the husband would kill
murderers at night. Esther considered a moment. The idea appealed
to her.
"Why not a policeman and his wife?" said Esther.
With Esther to decide is to act. Within an hour she had laid her
scheme before the Inspector in charge at the Police Station by St.
Mary Abbott's, and enjoined upon him to search his division for a
married constable of lofty character who would like to live rent free
in a dry and roomy basement. Within twenty-four hours the
constable was found.
Esther viewed him with approval, for he was large and serious; he
had the highest of characters, and had married a cook from De Vere
Gardens who had received a plated teapot from her late mistress as
a mark of esteem. They both assured Esther that they would do
their best by her and the other young lady, and an appointment was
made for a view of the house in Phillimore Place.
And so it came about that, one evening, just as dusk was falling,
Esther and Susie met the constable and his wife outside the house,
and, after greeting each other on the pavement, entered together. At
that moment an errand-boy was slowly propelling a carrier tricycle
along by the kerb. His day's deliveries were accomplished, and, as
he looked this way and that way with a mind receptive of stray
impressions, his eye fell upon Esther and her companions. He was
immediately conscious of something unusual.
There is nothing remarkable about a policeman in Kensington High
Street; but a policeman being conducted into a house by a young
lady, and closely followed by two other women, one of whom wears
a nurse's uniform, affords matter for conjecture. The errand-boy
applied the brake to his cycle, and came slowly to a standstill just
below the house, at which he looked thoughtfully. Esther with the
constable and the nurse and the constable's wife had disappeared
through the front door, and for a minute or so nothing more
happened.
The boy, disappointed of his expected sensation, was just bending
forward to start his cycle again when he caught sight of an
acquaintance who was carrying a basket containing a dozen of stout.
A shrill whistle brought him to the side of the cycle.
"Wotcher!" he said.
"There's a copper gone in there," said the boy on the cycle, nodding
towards the house. "And a 'orspital nurse."
 "'THERE'S A COPPER GONE IN THERE, AND A 'ORSPITAL
NURSE,' SAID THE BOY ON THE CYCLE."
The other boy regarded the house critically.
"Was there a accident?" he asked.
The boy on the cycle, having no more information to give, said
nothing, but nodded again towards the house. Someone within had
struck a light, and the constable could be plainly seen standing in
the middle of the empty ground-floor room.
A hansom driver, crawling from the westwards in the hope of picking
up a fare to the Strand, paused in the act of lighting his pipe and
pulled up just in front of the cycle. A servant girl who had been sent
out to post a letter noticed an errand boy set down his basket upon
the ground and balance himself upon the rim, whereby he was
enabled to peer over the top of the railings, and she stood still to
watch him; while three sandwich men mournfully advertising a
concert at the Town Hall halted in the roadway and looked with dull
curiosity at the cabman, who had hitched himself round on his seat,
and with one leg swinging in mid-air was wondering what he could
charge for a really urgent case to St. George's Hospital.
"What's matter?" asked a homeward-bound workman who was
vaguely conscious of an unusual obstruction, and found the railings
a convenient support.
"Ain't nothing the matter," said the boy on the basket, looking round.
"You tike that fice 'ome."
The workman, finding it easier to stand still by the railings than to
walk, remained where he was.
"I stops where I am," he murmured; "see what's matter. All kinds
things happen in mighty metrolo—metrolopus."
The old gentleman who takes the air every evening along a beat of a
hundred yards or so of pavement in Phillimore Place halted and
looked inquiringly at the boy on the basket, disgustedly at the
workman clinging to the railings. Then, over the shoulder of the
workman the old gentleman caught sight of the policeman, who was
now standing in full light back to the window; while Susie, bending
down with tape-measure to calculate the amount of carpet required,
could be dimly seen by those outside to be busied with something
on the floor.
"Dear me!" said the old gentleman.
"There's—body in there," said the workman. "That's what 'tis. Body."
"Bless my soul!" said the old gentleman, looking round at the group
of people on the pavement. "Has there been a murder? Does anyone
know?"
No one cared to admit that he did not know what he was looking at,
whereas any positive statement might be controverted by someone
with knowledge. So no one answered, but all stood watching.
By this time the pavement was pretty well blocked, and wayfarers
had either to take to the roadway or to join the knot of people
collected in front of the railings and waiting anxiously upon events.

"'HAS THERE BEEN A MURDER? DOES ANYONE

KNOW?' SAID THE OLD GENTLEMAN."
Most of them chose the latter course, assuring each other that there
was really nothing to wait for.
"Oh, there's a 'orse down; let's go and look, Alf," said a young
woman to her husband, who was carrying something tasty for
supper in a piece of newspaper.
"Oh, kem on," said Alf. "You're always wanting to 'ang about for this,
that, and the other."
"Well, I'm sure, Alf, it's little enough excitement I get, day in, day
out, and—oh, wait a minute; I needn't reely wash biby to-night."
"'Taint a 'orse," said a seedy-looking man, whose height gave him a
view over the heads of the crowd. "It's in that house, that's where it
is."
"What is?" asked Alf, still incredulous.
"Oh, there's a pleeceman in there, Alf," said the young woman,
delightedly.
"Then there ain't much the matter," said Alf, his good temper
restored by the consciousness of a ready wit. "They're 'andy enough
when they ain't wanted to be, and when they are wanted——" He
sought vainly for a means of elaborating his joke. "Now then, where
yer shovin'?"
"Shovin' yerself," was the reply; "don't other people want to see
same as what you do?"
Welcome to our website – the perfect destination for book lovers and
knowledge seekers. We believe that every book holds a new world,
offering opportunities for learning, discovery, and personal growth.
That’s why we are dedicated to bringing you a diverse collection of
books, ranging from classic literature and specialized publications to
self-development guides and children's books.

More than just a book-buying platform, we strive to be a bridge

connecting you with timeless cultural and intellectual values. With an
elegant, user-friendly interface and a smart search system, you can
quickly find the books that best suit your interests. Additionally,
our special promotions and home delivery services help you save time
and fully enjoy the joy of reading.

Join us on a journey of knowledge exploration, passion nurturing, and

personal growth every day!

ebookbell.com