1
Introduction
The constant evolution taking place in the field of Information and Communication Technology (ICT) means that an ever-broader range of users are employing this technology in increasingly flexible, changeable and varied cases of use. In parallel to this trend, owing to our demand for the provision of useful and usable solutions, the design of systems, services and products are becoming more and more complex. In response to this demanding context, the User-Centered Agile (UCA) method, which is presented in this book, is conceived to include both User-Centered Design (UCD) and agile development methods, taking full advantage of the particularities and assets of each of these approaches.
The foundation for the UCD method is the frequent and iterative participation of the user throughout a design project. Generally speaking, projects which operate on the basis of this approach are divided into three phases (see Figure 1.1): an analysis and design phase, a development phase and a validation and evaluation phase. An ergonomist, who is a specialist in UCD, usually makes a contribution at the earliest design stage, and is also involved in the final phase by way of user testing, but has little input during the intervening development period. However, the design phase, which is sometimes rather short, does not always allow for the involvement of real-world users. Furthermore, because the evaluation phase occurs only after the development has already taken place, the possibilities for modifications to be made are limited, for reasons of time and financial costs.
Figure 1.1. Division of projects into three phases
In parallel, for a number of years, agile methods (in particular the Scrum method) have become widely used by development teams. These are models which involve iterative and incremental development, intended to respond as faithfully as possible to the needs expressed by the project commissioners, offering a high degree of reactivity to their demands. These approaches facilitate rapidity in the development of a service, and flexibility to apply adaptations which appear necessary to this product during the development phase. Nevertheless, the end-user is not formally involved in the pursuance of these methods, meaning it is of limited use from the point of view of UCD.
UCD and agile methods have points in common: in particular the concept of iterations and the search for feedback. We can, therefore, envisage mutually integrating these two methods, with the aim of strengthening the taking into account of a “user” perspective. If a partial functional product is delivered at the end of each iteration, regular evaluation by users is possible, and, therefore, UCD can continue during the development phase and be present throughout the design process. Agile methods, for their part, can take account of the needs of the end-users, rather than just those expressed by the commissioner of the development project.
Put more clearly, the UCA method which was described briefly in the article [DEU 12] and which we are suggesting here is intended, primarily, to adjust the design phase to include a hybrid method wherein UCD and the agile Scrum method are interlocked, giving an overall view of the product. Then, in the development phase, the aim of the UCA approach is to enable an ergonomist to continue to apply the UCD process by way of regular miniuser testing sessions. Finally, in the validation phase, the method advocates that “conventional” user testing be employed. Figure 1.2 illustrates the logic of these three phases.
This method is presented in the form of rules and formal recommendations. It inevitably involves certain infringements on some of the rules unique to either method, since the aim is to integrate them together, and therefore find a balance in the interlocking of each with the other; and this cannot be done without some compromises on both sides.
Figure 1.2. Division of projects into three phases in the context of the UCA method
In the interests of a full appreciation of the method being proposed here, in Chapter 2, we introduce the methods employed – namely: the Scrum method, the UCD method and the user testing which occupies an important place in our proposed system.
In reviewing the literature, we were able to observe that the combination of UCD and agile methods is not a new topic, and many works highlight the relevance of such an approach. Chapter 3 analyzes the existing body of work published over the past decade on this subject, and also offers a summary of feedback on experiments conducted with the UCA method. We have based our thinking on all of these sources when devising the UCA method.
The UCA method is a working framework based on the logic introduced by Scrum – a project management oriented working framework. The method proposed herein is intended to be a “human-centered” extension of Scrum given the integration of UCD and user testing. It is for this reason that the description of the UCA method given in Chapter 4 is based entirely on the fundamental aspects of the Scrum agile method and employs its terminology and its elements.
The final chapter presents two case-studies which partly illustrate the application of the UCA method. Put differently, the two proposed projects employ the UCA method which we advocate here as closely as possible to its description, in view of the context of each project.
2
Introduction to the Methods Employed
The User-Centered Agile method (UCA) is intended to mutually integrate the agile method known as Scrum and the User-Centered Design (UCD) approach. It attempts to lay down a project management framework based on the Scrum method, integrating the advantages of UCD in order to better cater for the needs of the end users. Consequently, the aim of this chapter is to introduce these two approaches upon which the UCA method is founded, as well as the user testing technique – a technique used for evaluating a product, which occupies a very important place in the UCA method.
2.1. The agile method – Scrum
2.1.1. Fundamental elements of agile methods
In the 1980s, in the wake of the observation that the use of V-shaped models and development methods1 were leading to the failure of numerous software development projects (late delivery, over-budget costs, products which did not cater for the consumers’ needs, etc.), a great many research projects were carried out on iterative and incremental methods. They were not widely taken into account until, in 2001, a group of seventeen experts came together, with the intention of rallying iterative and incremental methods under the banner of “agile methods”. This rallying took place by way of a manifesto, the “agile manifesto”2, comprising four values and twelve principles shared by the many different existing methods.
Thus, the agile methods are iterative and incremental development models which are intended to cater as fully as possible for the needs expressed by the commissioners (the clients behind the development of the product), providing the opportunity to regularly evaluate the product, and offering a high degree of reactivity in relation to their requirements. They offer the flexibility to apply to the product any adaptations which appear necessary to be made during the course of the development phase. This is due to the fact that they respect the four fundamental values of the agile manifesto:
– the team: the team is far more important than the tools or operational procedures. Communication is a crucial concept in the interests of having a closely-knit team.
– the product: the product, even when unfinished, must always work.
– collaboration: the commissioner must be involved in the project in order to be able to provide information to the team at all times, thereby avoiding any differences between the demand and the realization of the product.
– acceptance of change: the team must accept the changes asked of them. The initial planning needs to be flexible in order for these changes to be taken into account.
Agile methods are primarily and traditionally applied for software development but, theoretically, they could be applied to any type of project. The different agile methods share the same philosophy and the same principles, but are different in the way in which they implement these principles and philosophy. Consequently, we have focused on one method in particular – Scrum – to enhance the UCA method.
2.1.2. Scrum method
In 1986, H. Takeuchi and I. Nonaka published an article explaining how certain Japanese companies were able to quickly come out with world-class products, based on self-managing teams and a highly involved style of management [TAK 86]. This article contained all the fundamental elements of the method which, hereafter, we shall call Scrum – the name bestowed by P. DeGrace and L.H. Stahl in 1991 [DEG 91], in reference to the rugby term mentioned in Takeuchi and Nonaka’s article.
In 1993, Jeff Sutherland applied this model for the first time to a development project, and he recounted his experience of it in a 2004 article [SUT04]. In 1995, Sutherland and Ken Schwaber laid down the fundamental aspects of the Scrum method [SCH 95].
Thereafter, many publications on the Scrum method were to see the light of day, including the works of K. Schwaber and M. Beedle [SCH 01], K. Schwaber [SCH 04], C. Aubry in France [AUB 10], and recently the Scrum Guide, co-authored by Ken Schwaber and Jeff Sutherland [SCH 11], and the work of K.S. Rubin [RUB 12].
The entirety of this section is given over to the description of this agile method, which is practical, simple and very widely used in the world of industrial software engineering.
2.1.2.1. An iteration-based process
Scrum is a project management method – a working framework championing an iterative and adaptive process of product development. Thus, it is based on iterations, generally lasting between two and four weeks, known as “sprints”. All sprints are of a fixed duration, and the activities which take place during them are organized in the same way for all the sprints. Each new sprint begins immediately after the previous one, and the defined goal of a sprint cannot be altered during its pursuance.
Owing to this iterative process, the product is constructed incrementally: each partial product at the end of each sprint is an operational product, potentially deliverable, and therefore functional and available.
In a project, the version of a product delivered at the end of the development phase is called a “release”. In an improper use of language, this denotation is also attributed to the period of time set aside to create a version of the product. Thus, in Scrum, a release is composed of a series of several sprints. Furthermore, several releases of a product may occur on the tail of one another (see Figure 2.1).
Figure 2.1. Iterative process of the agile method, Scrum, based on sprints of fixed duration
2.1.2.2. Fundamental elements and progression of the Scrum method
The Scrum method is based on three types of elements, which frame the development process: the roles of the participants in the project, the artifacts used and the ceremonies. Each of these elements has a specific meaning, and is essential to the method of bringing benefits to the project applying this approach. The process of the method consists of rules which forge connections between these different elements.
There are three roles in Scrum:
– the Product Owner (PO): this is the client who has commissioned the product. He provides a vision3 of the product which is shared with the whole of the team. The PO is responsible for defining the content of the product, managing the priorities of the items of the product and ensuring these priorities are understood by the development team;
– the Scrum master: the Scrum master is not a project manager. He is responsible for helping the team to apply the Scrum method and adapt it to their particular context. His duty is to eliminate impediments, i.e. events which could slow down the work of the team;
– the development team: the team is in charge of the development of the product, and organ...