Extreme Programming (XP) as proposed by Kent Beck (Beck 1999, Beck 2004) is a ..... www.informatik.uni-hamburg.de/teaching/lvdetails.php?id=2003218121.
XPnUE – Defining and Teaching a Fusion of eXtreme Programming & Usability Engineering Hartmut Obendorf*, Axel Schmolitzky†, Matthias Finck* *Applied and Social Informatics Group / †Software Technology Group AGIS Center – Department for Informatics University of Hamburg Vogt-Kölln-Str. 30 D-22527 Hamburg, Germany {obendorf, schmolitzky, finck}@informatik.uni-hamburg.de
ABSTRACT Software engineering and usability engineering are two disciplines sharing the aim of improving the customer experience in software development. However, and although practitioners of both disciplines need to collaborate in practice, sketches for development processes often rely on a singular perspective. In this paper, we report some of the experiences we made when designing a course on a combination of extreme programming and usability engineering, based on a blend of perspectives on equal terms.
Keywords Usability engineering, software engineering, contextual design, scenario-based design, extreme programming
1. INTRODUCTION Software quality has been defined from different perspectives: while software engineering traditionally placed the focus on ‘inner’ qualities, such as architecture, scalability, use of software design principles, the readability and understandability of the source code, usability engineering (UE) techniques were developed to ensure that software development would respect the competence of users of software about the use context to increase the ‘outer’ quality of the software; the latter comprises perceived performance and usability and can be directly observed by the users. Extreme Programming (XP) as proposed by Kent Beck (Beck 1999, Beck 2004) is a solution that tries to address both ‘inner’ (technical) and ‘outer’ (use) quality of software, the former through a lean development practice based on informal communication where appropriate and a rigid test-first approach, the latter through propagation of continuous negotiation with a representative of the customer. However, requirements engineering as an activity within XP was not explicitly defined, and so the XP community has not established a common culture for gathering the requirements for a software system. While XP demonstrates its strengths in iterative software development where requirements may change as a system is incrementally put into use, the question of how to devise an initial design is largely unanswered. Since Usability engineering (UE) typically targets exactly this question, a combination of XP and usability engineering is highly attractive – yet fusing both is not as simple as one might hope for. This paper reports on our efforts to develop and to teach a process model (that we call XPnUE in the following) that combines agility as the central characteristic of XP with the overview of work practices that UE aims to provide. We take a process perspective at software development that stresses the learning aspect for both the client organization and the development team. Usability methods in this context are first and foremost a means of accessing the context of use, and gathering early feedback with rapidly developed prototypes. Usability testing can only support and shorten – not replace – the cyclic prototypical development process that we propose where functional prototypes are continually improved and extended as they are put to use. A central aspect we will expand on in the following pages is the formulation of an iteratively refined vision guiding the design – as an easily accessible representation of usability results. Before we describe the concept of XPnUE and reflect on the experiences we made teaching the postgraduate course, we first give some background information on the setting and the approaches we draw upon.
2. ACADEMIC SETTING In this paper we describe a postgraduate course that was developed and taught as a collaborative effort of the Applied and Social Informatics Group (ASI) and the Software Engineering Group (SWT) at the University of Hamburg (Obendorf et al. 2005). The former group has a focus in research and teaching on computer-supported collaborative work, software ergonomics and usability engineering, the latter on object-oriented software construction and agile participatory development methodologies. Both groups claim to focus on the development of interactive software systems, yet even though the groups know each other well and share many beliefs on what software should deliver, we experienced that our perspective on the process is still as different as our fields of expertise. The authors of this paper are working in one of these groups, respectively, and have a background in either software engineering, or in usability engineering. In summer
2004 we realized that both our groups could profit from an effort to combine the advantages of UE and XP and decided to design a course on developing a combined methodology. The curriculum at Hamburg University includes several courses in software engineering, starting with a first-year course on object-oriented programming and design with Java (Becker-Pechau et al. 2003); one focus is on the generation of a working knowledge transfer between industrial projects and university education (Bleek et al. 2005). While usability engineering techniques are taught in postgraduate courses, postgraduates begin working in the field of software design with a unique lecture series that combines software engineering with usability (Floyd and Oberquelle 2003). What was missing was the concrete application of a combination of methods coming from these fields, as subsequent courses – and graduate students – tended to focus on a single area. With the postgraduate course described here, we tried to bridge this gap and tried to involve students from both areas in the development of an approach combining the advantages of UE and XP. This should encouraged them to realize existing differences btween these approaches, how the two methodologies can profit from each other, and demonstrate usability techniques to future key multiplicators.
3. APPROACHES WE BUILD UPON In 2004, a second edition of the book that originally started the XP movement (Beck 1999) was published, refining some aspects of the process. More to the point of this article, the controversial concept of the ‘customer on site’ was discontinued and replaced by ‘real user involvement’ as a corollary technique (Beck & Andres 2004). This replacement of terms and the subsequently sparse use of the interaction designer role in the description of the process show the need for a more defined requirements gathering activity within XP. Scott Ambler proposed a variant of UML modeling as a means of communication with the customer (Ambler 2002), yet formal methods are known to create problems when communication is not with domain experts, but with real end users. While XP relies on the customer to deliver a specification, with stories filling a central function in the communication of client and developer (Cohn 2004), usability engineering methods generally try to ‘make the work visible’ (Suchman 1995) as a prerequisite to designing application solutions. To this end, scenarios have a long tradition in what is nowadays called usability engineering, even before that term was coined – Morten Kyng employed scenarios intensively as a communications medium for developing software (Greenbaum & Kyng 1991, Kyng 1995). John Carroll and Mary Beth Rosson proposed scenarios enriched with claims documenting design rationale as a method to speed up the task-artifact cycle (Carroll & Rosson 1992) and developed their method into a full process called Scenario-Based Development (Rosson & Carroll 2002). Although this process exists for some years now, no industrial application has been documented so far. Yet, scenarios are widely used in industry as a guide for development – often in a less elaborate form and not relying on textual representation for refinement of the interaction design, nonetheless with rather promising results (Weidenhaupt et al. 1998, Hertzum 2003). We also draw on Karen Holtzblatt’s and Hugh Beyer’s Contextual Inquiry (Beyer & Holtzblatt 1995) as an effective method of gathering information about the use context and responsibilities and relationships of end users. Based on their method of apprenticing to the user, they defined Contextual Design (CD) (Beyer & Holtzblatt 1997) as a complete development process. Yet again, implementation is only mentioned as a phase in the end, while CD itself gathers feedback on many levels, the iterative nature of development and deployment of nature is not accounted for. Recently, some elements of the process, including the main component, the user environment design targeted at work redesign, have been made optional in order to create a more lightweight methodology called Rapid Contextual Design (Holtzblatt et al. 2004). The approach we developed needed to preserve the rapid release cycle inherent in both the software and usability engineering processes, while intertwining the development of interaction design and program code that were isolated activities before, XP lacking a well-defined requirements specification methodology and UE deliberately excluding reciprocity of design and implementation. This led us to specify a process where vision and code are developed in parallel; after a brief starting phase when the overall product vision is formulated, the team needs to work on different levels of abstraction. It is clear that a vision cannot be complete, yet it should deliver a whole picture of what is to be that can serve as a basis for iterative refinement. We thus elected scenarios in different forms as the main medium for the product vision that had to fulfill a dual role: it was needed both as a medium of communication with customers and users and, internally, it worked as a guiding post for development efforts.
4. DEVELOPING AN AGILE PROCESS BLUEPRINT & TEACHING IT, TOO Although a certain distance to actual practical work cannot be avoided in an academic environment, we took some measures to base the definition of the development process on more than solely theoretical work: the first sketch for the process was developed from August 2004 through March 2005 in periodical meetings by two members each from the software engineering group and the software ergonomics group at Hamburg university; we could thus draw on our experience in the application of XP or UE methods in both academic and industrial projects. First, we tried to reflect on previous practice to build a common basis of understanding before starting to develop a new methodology. We found the need to define the territory of expertise of everyone involved and for a clear agreement about the target of the process to be much stronger than anticipated. In order to communicate about the relative importance of aspects of software quality in the product, we were quite surprised about the difficulties we had talking about values, methods and techniques. Although we work only a few steps down the corridor from each other, and assumed to have a common view on software development, we found various sources of miscommunication: basic terms have varying
meaning in XP and UE (e.g. a “design” activity can target software architecture (XP) or human-computer interaction (UE)). An exchange of vocabulary was thus necessary to define the values and motivations that stand behind the application of techniques such as the ‘planning game’ (XP) or the ‘affinity diagram’ (Contextual Design) – quite difficult a task, for books about both XP and UE try to deliver an applicable process and thus have to compromise the discussion of underlying theoretical motivation for the introduction of certain techniques.
4.1 The Process Blueprint Finally, we developed the proposal for a development process illustrated in Figure 1 by enriching the XP process with techniques taken from UE. As the XP process seems only to lack a well-defined requirements gathering activity, this might seem an easy task – yet simply adding an a-priori analysis of what should be built reduces the agility of the process: there is a desire to collect most of the requirements in the beginning, making an agile reaction to change more difficult – although usability engineering processes feature iterative design, the design is often carried out before implementation starts. We tried to circumvent this pitfall by using only very lightweight techniques from usability engineering and made arrangements to iteratively refine the requirements analysis as a parallel activity to implementation. For the activities listed in Figure 1, we adopted techniques from both Rapid Contextual Design (Baker et al. 2004) and Scenario-Based-Engineering (Rosson & Carroll 2002), which we had to change in order to fit them into the process. Contextual Investigation borrows from Contextual Inquiry but has less emphasis on completeness and modeling and more on understanding a (hopefully) relevant subset of the application domain, the Requirements Scenario leans on Rosson and Carroll’s Problem Scenario and the Vision or Use Scenario is a less strict version of the Activity Scenario, mixing activities with sketches of partial solutions within the interface. But the XP process also had to be modified, e.g. our notion of Stories includes Storyboards as possible (and often necessary) elements and Tasks can also lead to further contextual investigation, throw-away prototyping or the advancement of the Vision that is used to communicate about the proposed solution with customers and end users.
Figure 1: The XPnUE process incorporates fairly standardized design techniques; forms of representation, however, had to be invented anew (marked by asterisks). It was interesting to note that we could easily agree on the use of fairly standardized design techniques, such as paper prototyping or XP’s test-code-integrate cycle, yet had a much harder time to define the format for representing intermediate results. As our focus on agile, iterative design forbade the continuous maintenance of e.g. scenarios as design documents or the constitution of a comprehensive archive of contextual findings, we heavily rely on informal and incomplete information stored on notes on pin boards; this “informative workspace” workes both like its related XP technique, namely takes the function of organizing and visualizing progress, and like the “affinity diagram” used in Contextual Design, as part of the workspace visualized the team’s understanding of the problem domain and the projected solutions. The process starts off with a contextual investigation using interviews, workplace observations and apprenticeship observation (Beyer & Holtzblatt 1995), involving all members of the development team in workplace excursions. From the collected data and personal observations, requirement scenarios describing the current use of (also “analog”) tools were developed from the perspective of the speculatively missing functionality. Feedback from users and additional contextual investigations lead to incremental enhancement of scenarios and, finally, to the development of a coherent vision that encompasses both a problem statement and a proposed solution for the developed system. As we extensively use storyboard techniques for scenarios, the collected material is developed into a first sketch for concrete examples of the system look and feel, complementing the abstract vision with concrete use examples – we call these use scenarios. From these, we extract XP-like stories that encompass a smaller functional unit that is meaningful from both the user and the system perspective. These stories are directly implemented or, if necessary, incrementally refined through user feedback, e.g. using paper prototyping. Iterations denote weekly development cycles when the resulting prototype system is
presented to the user and new stories are collected. A release denotes a larger unit of development, when a functional prototype is delivered that can be put to use in the real context. At each release, the vision is reviewed and potentially extended to meet developing needs.The developing informative workspace, which a casual observer might mistake for a number of pinboards, became a central store for the information about the process, status with current hotspots, and the system vision.
4.2 Teaching & Developing the Process Blueprint We practically implemented our process blueprint within the scope of a post-graduate course in order to fathom how well the techniques we imported from different methodologies fit together in practice and what influence our changes would have regarding the agility of the process. From June 2004 through March 2005, members from both department met about every month, with a more intensive period in spring 2005, to exchange our experience with different techniques and begin to develop a common language, most notably developing a sensitivity for each others tender spots. Thinking agile on the meta-level, we then deliberately set out to collect practical experience early – even though our process blueprint was far from being finished, or even well-documented. To this end, all three authors accompanied a teaching project in summer 2005 that implemented the process model for a realistic software design project, a distributed calendar system. 18 participants formed a development team that needed to learn about both UE and XP techniques, yet nevertheless was set to implement and deliver a working prototype within the 4 months of course time. To develop the requirements scenarios, the project team needed to understand the role that an electronic calendar system played for different university personnel (secretaries and researchers) in their daily work for our departments. With this realistic setting, we experienced a large number of realistic difficulties for an academic course, ranging from dramatic schedule difficulties to feature-demanding users to capacity shortages, and some more. With some cutting back, however, we were able to follow most of the planned activities, run through two development cycles and deliver a working prototype in the end. This would not have been possible without the vision defined during the first weeks, as it was instrumental to coordinate teams working on different parts of the project. Documentation of the techniques in the process was also designed lightweight: a student-devised presentation was further developed by the team into a one-page-long description of the technique, listing its requirements, procedures, role in the process, and possible advantages and disadvantages. These descriptions were also iteratively and incrementally developed as we continued to follow our developing process. While not all students were willing or capable to participate in process development, we periodically took a (metaphorical) step back and reflected on the empirical results and experiences both as part of the course with our students and among the teachers.
5. Lessons Learned As the course was taught only once so far, our results will have to be taken with a grain of salt; still, we believe to have some interesting findings about both the teaching of a course without textbooks and the application of a blended design/ programming process.
5.1 Teaching XPnUE Teaching a postgraduate course comprising theoretical reflections about a fusion of eXtreme Programming and Usability Engineering and practical application of a novel approach for agile software development was an intensive experience for all participants. Evaluating our course, we found that although they reported an increased workload compared with other couses that taught better defined methodologies, most of the students appreciated the investigative nature of the course. Our post-evaluation indicated strong agreement with the research claims of the course, most participants would recommend the course to their fellow students. All in all, they attest a high learning effect: the practical nature of the course helped understand problems both in the process blueprint and in the software during implementation. One major problem we encountered, however, is caused by the alternation of theoretical reflection and practical implementation. While students often need to switch between these levels in a project course, usually the aim is to learn and understand an established methodology; in the course described here, the process blueprint was refined as we reacted on the project situation. Also, with the instance-based learning approach we used during the course, introducing techniques in detail only briefly before they were applied, there was no way to resort to a textbook in doubt or conflict; reflection of our evolving methodology required a deep understanding of the basics that we built the approach upon. To judge the suitability of the developed process, it was also necessary to differentiate between fundamental conflicts and constraints that were only introduced by the nature of the student project. Not all students were experienced enough to actively take part in the discussions and, to further complicate the situation, even we as teachers were not always of one mind. This disclosure of conflicts was uncomfortable for many of our students, yet we were also told that the exposure of the mindsets underlying our positions was helpful to gain a deeper understanding of both XP and UE. Another problem was simply that many of our students had difficulties presenting unfinished ‘products’. While this stems partly from our students’ lack of experience with informal, rapid prototyping methods and their usefulness, part could also be accounted to a fundamental mindset of (software) engineers to shy imperfection – paper prototypes were not accepted as real prototypes. While this presented some difficulties for the actual development project, course participants stated that one of the main lessons to take home was the value of informal methods. To demonstrate this value, however, we as teachers had to walk a thin line between project success and course effectivity: while taking control of the develop-
ment process might have benefitted the project, we sometimes had to hold back to let problematic situations escalate before intervening with e.g. prototyping techniques. This showed on the one hand that learning UE techniques by the book poses practical problems if methods are applied “in the right spirit”, on the other hand it triggered some of the most productive half-hour activities in the process. We believe that there is room for improvement at least in three areas: •
First, a task from a more arcane application domain would increase the motivation for user involvement during contextual investigation; while we cannot create realistic economical pressure as a motivation for tailoring the application to the user, this would eliminate the observed effect that our students at least initially felt as domain experts, since they often use calendar tools, too.
•
Second, it would be interesting to try a programming language different from Java (a candidate being Ruby on Rails, Thomas and Hansson 2005) that might allow more rapid development and less focus on technical questions e.g. concerning the software architecture.
•
Third, we found that users can not get “realistic” enough – our recruits included colleagues from the IT department that turned out to be able to join in with architectural discussions – not a good match for “normal” users.
5.2 Applying XPnUE Some observations promise to yield interesting results upon further analysis: we found the initial momentum in developing a coherent direction for development critical for the success of the whole project, we observed that all used techniques contributed to the process, yet for a larger and more long-lasting development effort better means for documentation need to be found. We witnessed a concentration upon architecture and implementation details just as the release came close, so discussion about the future development direction became difficult in the planning game. We can also list a first version of solutions: Get Started Quickly – When contextual inquiry is carried out by the whole team, communication problems are kept low and within the team a consensus about the problem domain is reached quickly. Short Feedback Cycles – Immediate feedback is vital to avoid surplus design work; systematic speculation in scenarios brings up questions from the users; throw-away prototyping helps to narrow down the design space. Define A Whole Vision – While a vision can never be complete, it must allow the extrapolation of the behavior of parts of the system that are not detailed in the vision. Metaphors can be employed to guide design, yet they should not necessarily be communicated to the users. Continue Design Under Iteration Pressure – Keep using UE techniques to think about consistent extension of your functionality. If your team stops further development on the vision in favor of more concrete implementation tasks, this will make planning the next phase more difficult. Rapid Unfinished Designs Work Well – Paper prototypes, informal drawings and static design stills can be more useful than a running prototype for communicating with users as they allow criticism on a similar basis. Mind the Culture Gap – The differences between HCI education and CS education should not be underestimated – similar words can carry very different meanings. Also, programming is not strictly engineering, but also a form of personal expression, and architectural discussions can draw the team’s focus easily. Combined, these factors complicate the application of seemingly simple UE methods.
6. CONCLUSION The course presented in this experience report tries to integrate the posture of and techniques from usability engineering methods into the extreme programming process. We found that the actual implementation of a blend of software and usability engineering within the university is a useful experience for students focusing on either of these fields. To try their hand at the practical implementation of a fusion of XP and UE reveals problems to our students that would otherwise remain hidden until their first encounter with interdisciplinary project work outside the academic world. Interweaving practice from the two disciplines requires – and encourages – a deeper understanding of the underlying motives; even preparing this course, this has been a very valuable experience for all the authors. We believe that fusing agile development methods that allow an iterative refinement of applications with usability engineering methods that concentrate on user experience remains an important field of research. Working closely together, practitioners from both worlds could be stimulated to adopt the complimenting perspective and to learn the value of techniques from a foreign domain. XP yields itself to modification as design activities typically targeted by UE methods are only vaguely described; thus, we still ‘did XP’, although our procedure widely differed from Kent Beck’s initial description of the process (Beck 1999).
Acknowledgements We would like to thank Martti Jeenicke for preparing the course with us and sharing his experiences. We are also indebted to Christiane Floyd and Horst Oberquelle for creating an environment that invites experimentation and communication between the software engineering group and the software ergonomics group.
References 1. Ambler, Scott (2002): “Agile Modeling”. Wiley. 2. Baker, Lisa; Beyer, Hugh; Holtzblatt, Karen (2004): “An Agile Customer-Centered Method: Rapid Contextual Design”, XP Agile Universe 2004 Proceedings, Calgary, Alberta, Canada. 3. Beck, Kent; Andres, Cynthia (2004): “Extreme Programming Explained: Embrace Change”. Second Edition. Addison-Wesley. 4. Beck, Kent (1999): “Extreme Programming Explained: Embrace Change”. Addison-Wesley. 5. Becker-Pechau, P., Breitling, H., Lippert, M., Schmolitzky, A. (2003) “Teaching Team Work: An Extreme Week for First-Year Programmers”, In Proc. of 4th International Conference XP 2003, Genova, Italy, Springer, LNCS 2675, S. 386-393. 6. Beyer, Hugh; Holtzblatt, Karen (1995): "Apprenticing with the Customer: A Collaborative Approach to Requirements Definition", Communications of the ACM Issue (May 1995). 7. Beyer, Hugh; Holtzblatt, Karen (1997): “Contextual Design: Defining Customer-Centered Systems”, Morgan Kaufmann Publishers Inc.: San Francisco. 8. Bleek, W.-G., Lilienthal, C., Schmolitzky, A. (2005): “Transferring Experience from Software Engineering Training in Industry to Mass University Education – The Big Picture“, Conference on Software Engineering Education & Training (CSEE&T) 2005, Ottawa, Canada; IEEE Press, pp. 195-203. 9. Birk, Andreas; Kohler, Kirstin; Leidermann, Frank (2003): “Der Weg zu einer stärkeren Verzahnung von Usability Engineering und Software Engineering”. UPA-Workshop Mensch & Computer 2003. 10. Carroll, John M.; Rosson, Mary B. (1992): “Getting around the task-artifact cycle: How to make claims and design by scenario”. ACM Transaction on Information Systems, 10, 181-212. 11. Clarke, L. (1991): “The use of scenarios by user interface designers”. In Diaper et al. (ed.): People and Computers VI. Cambridge University Press, 103-115. 12. Cohn, Mike (2004): “User Stories applied”. Addison-Wesley Professional. 13. Floyd, Christiane; Oberquelle, Horst (2003): Softwaretechnik und –ergonomie. Skript zur Vorlesung. http://swtwww.informatik.uni-hamburg.de/teaching/lvdetails.php?id=2003218121 14. Greenbaum, Joan M.; Kyng, Morten (1991): “Design at Work: Cooperative Design of Computer Systems”. Lawrence Erlbaum Associates, Inc., NJ. 15. Hertzum, Morten (2003): “Making use of scenarios: a field study of conceptual design”. Int. Journal of HumanComputer Studies, 58(2), 215-239, Feb. 2003. 16. Holtzblatt, Karen; Wendell, Jessamyn Burns; Wood, Shelley (2004): “Rapid Contextual Design: A How-to Guide to Key Techniques for User-Centered Design”, Morgan Kaufmann Publishers Inc.: San Francisco. 17. Kyng, Morten (1995): “Creating Contexts for Design”. In Carroll, John (Ed.), Scenario-Based Design, 1-24. John Wiley. 18. Obendorf, Hartmut; Finck, Matthias; Schmolitzky, Axel (2005): “Teaching balance and respect: HCI Group & Software Technology Group at the University of Hamburg”, interactions 12, 5 (Sept. 2005), 36-37. 19. Rosson, Mary Beth; Carroll, John (2002): “Usability Engineering: Scenario-based Development of Human-Computer Interaction”. San Francisco: Morgan-Kaufman. 20. Suchman, Lucy (1995): “Making work visible”. Communications of the ACM, v.38 n.9, 56ff., Sept. 1995. 21. Thomas, Dave; Hansson, David H. (2005): “Agile Development with Rails”, The Pragmatic Programmer. 22. Weidenhaupt, K.; Pohl, K.; Jarke, M.; Haumer, P. (1998): “Scenario Usage in System Development: A Report on Current Practice”. In IEEE Software, Mar. 1998, pp. 33-45.
