DRAFT Research Project Mid-term Paper

User-Centered_Agile_Method_----_CHAPTER_2._INTRODUCTION_TO_THE_METHODS_EMPLOYED.pdf

Home >Business & Finance homework help >Operations Management homework help >DRAFT Research Project Mid-term Paper

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

1 V-shaped methods are waterfall methods wherein the phases occur successively, with one phase unable to begin until and unless the previous one has been completed. These phases are, in the order in which they occur: expression of needs, specifications, design, production, testing, validation and maintenance.

Deuff, Dominique, and Mathilde Cosquer. User-Centered Agile Method, John Wiley & Sons, Incorporated, 2013. ProQuest Ebook Central, http://ebookcentral.proquest.com/lib/harrisburg-ebooks/detail.action?docID=1187167. Created from harrisburg-ebooks on 2020-11-24 14:03:06.

C op

yr ig

ht ©

2 01

3. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

6 User-Centered Agile Method

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 The “agile manifesto” is available on the following Website: http://agilemanifesto.org/.

C op

yr ig

ht ©

2 01

3. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Introduction to the Methods Employed 7

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 [SUT 04]. 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

C op

yr ig

ht ©

2 01

3. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

8 User-Centered Agile Method

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 organizes itself with the aim of optimizing its productivity, its

3 The vision corresponds to a clear and concise definition of the product in terms of objectives and problems needing to be solved.

C op

yr ig

ht ©

2 01

3. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Introduction to the Methods Employed 9

flexibility, its creativity and enhancing its skills in order to achieve the objectives.

Scrum is based on two artifacts as a pivotal point for the activities:

– the product backlog: this is a prioritized list of items, with the most important items at the top of the list. This list represents the product’s functional perimeter. This list is not set in stone, and evolves over time with the addition, elimination and decomposition of functional items, and also on the basis of the new priorities encountered (changes in the level of priority of the users’ needs, market conditions and technological evolutions [SCH 11]). The items on the backlog have differing levels of detail. Those items on the list which are most important are usually detailed more explicitly than the optional items. As the project advances, the number of detailed items increases. Thus, as long as the product exists, the product backlog evolves and continues to live;

– the sprint backlog: this represents that part of the product backlog which is in the process of development in the current iteration. It is the set of tasks needing to be performed during an iteration. This list is decided upon at the beginning of the sprint, and usually cannot be altered during the undertaking of a sprint.

In certain books and articles describing Scrum, other artifacts are cited:

– the increment [SCH 11; RUB 12]: this is the functional partial product delivered by the development team at the end of each iteration;

– the “burndown charts” [AUB 10]: these are progress graphs which can be used to make predictions of the advancement of the elaboration of the product and what remains to be done in an iteration;

– the impediment list: this is the list of items standing in the way of the productivity of the development team and the quality of the product.

The progression of a Scrum process is framed by five ceremonies (see Figure 2.2):

– release planning meeting: this is the meeting which involves completing priorization of the items from the product backlog and distributing them into iterations of equal duration. This ceremony precedes the start of all the developments, and therefore takes place only once during the release;

C op

yr ig

ht ©

2 01

3. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

10 User-Centered Agile Method

– sprint planning meeting: this is the meeting at the very beginning of a sprint, intended to break down the items in the iteration just beginning, into short developmental tasks. These tasks are generally brought together into a task board, which organizes them into three categories: those which need to be developed, those in the process of being developed and those which have been completed. In the wake of this meeting, the developments of the current sprint begin in earnest, on the basis of the tasks defined;

– the daily scrum: this is a daily 15-minute window in which each member of the team briefly summarizes what he did the previous day, and what he intends to do that day. This point is crucial in Scrum, because it affords the opportunity to evaluate the progress of the project, to improve communication between the team members, to fine-tune the understanding of the project and to reduce the number of meetings by identifying problems as early as possible;

– the sprint review: this is a meeting at the end of a sprint, intended to demonstrate the functional partial product, i.e. the state of the project at the end of the sprint, in order to facilitate the making of decisions about the continuance of the project and the identification of potential items for the next iteration. During this ceremony, the Product Owner (PO) compares the product to his initial demand and, if necessary, suggests modifications to be made to it. In taking account of these modifications, the product backlog needs to be amended. There may, in fact, be an adaptation of the content of the sprints on the basis of the modifications requested;

– the sprint retrospective: this is the final meeting in a sprint. It follows the sprint review, and involves only the development team. The intention at this meeting is to identify what works well and what needs to be altered in order to collectively find solutions to improve the workflow.

Figure 2.2. Description of a sprint

C op

yr ig

ht ©

2 01

3. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Introduction to the Methods Employed 11

2.1.2.3. Question that arises regarding the period before the sprint planning meeting

The description of the Scrum method, as originally defined, begins with the release planning meeting. This means that the items in the product backlog need to be identified before the Scrum method per se can truly begin. Thus, the Scrum method gives us no guidance for describing these items. Consequently, in most books, there are descriptions of the phase located before the sprint planning meeting (the period between the beginning of the release and the beginning of the first sprint – see Figure 2.3). This phase is sometimes incorrectly called “sprint 0”, although it has none of the characteristic traits of a sprint (variable duration, no increment at the end, no ceremony specific to the sprint). In the context of this book, we have chosen to adopt the terminology sometimes employed on discussion forums relating to the Scrum method: pre-sprint.

Figure 2.3. Position of the pre-sprint in a release

This pre-sprint phase is intended, amongst other things, to “set up the team, define the vision, and produce an initial backlog” [AUB 10] and to acquire new knowledge [KEI 10]. It will be greater or lesser in length, depending on the maturity of the product to be developed. “Obviously, more time is needed in the case of the first release of a new project, based on a new technology, than for its nth release” [AUB 10]. Depending on the precision of the request made by the PO, this preliminary phase may involve taking account of the items from the product backlog proposed by the PO, as this may necessitate a work of identification and description of the items in the product backlog, most often in the form of “user stories”. A “user story” is a function which lends added value to the user of the system [COH 09]. It is described from the point of view of the end user, without going into the technical considerations or issues of ergonomic design.

C op

yr ig

ht ©

2 01

3. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

12 User-Centered Agile Method

Taking account of the phase preceding the release planning meeting also brings another element of reflection: the PO is not alone, and may be surrounded by participants who may be arranged into a team. J. Sutherland and K. Schwaber, in their latest description of Scrum, specify that “the Product Owner is a person – not a committee” [SCH 11]. On the other hand, the PO may surround himself with all sorts of people in a committee, to enrich and inform his thinking process, but it is ultimately the individual person, the PO, who will take the final decision and who will bear the responsibility for any decision taken. Thus, for C. Keith and K.S. Rubin, the PO is not alone in putting in place the items in the product backlog: he is surrounded by users or their representatives and numerous professionals involved in the project (a marketing research expert, a business-case development analyst, a User eXperience (UX) designer, a systems architect, etc.) [KEI 10; RUB 12]. For instance, in the world of digital games, the PO could be surrounded by a publisher-producer, a marketing expert and a studio leader (art, design and technique) [KEI 10].

Thus, the pre-sprint phase is often described in a more or less detailed fashion as being the phase where one or more collaborative workshops take place, with the aim of bringing a vision to the forefront, and on that basis, of obtaining an initial list of items in the form of “user stories” for the product backlog.

2.1.3. Scrum method as a framework for the User-Centered Agile method

As pointed out by K.S. Rubin [RUB 12], each implementation of Scrum is unique, owing to the application of specific engineering techniques and each company’s particular approach to Scrum practices. Consequently, in order to properly understand the description of the UCA method given in Chapter 4, we feel it important to properly specify our representation of the Scrum method.

To begin with, we think it is important – as do many other authors – to state categorically that there is a pre-sprint phase which takes place in advance of the developments. The goal during this phase is to gather “user stories” about the PO’s product. The phase can be carried out by a multidisciplinary team attached to the PO, and involves the development team. For the development phase, we adopt the classic description of Scrum: an identically fixed duration for each sprint, delimited by four ceremonies.

C op

yr ig

ht ©

2 01

3. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Introduction to the Methods Employed 13

F ig ur e 2. 4. R ep re se nt at io n of

th e ag ile m et ho d, Sc ru m

C op

yr ig

ht ©

2 01

3. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

14 User-Centered Agile Method

Figure 2.4 gives an overview of our representation of Scrum, showing:

– the PO, although we consider the icon given in Figure 2.5 to represent a multidisciplinary team;

– the development team, comprising the “Scrum master” and the developers. We have chosen to group these roles together, because the description of the UCA method does not entail any change in the role of the “Scrum master” attached to the development team (see Figure 2.5).

Figure 2.5. Representation of the roles of the PO and the development team

2.2. User-Centered Design method

User-Centered Design (UCD) is an approach to the design and development of interactive systems. The process is guided by knowledge of the end users, their contexts of use and their needs, with the aim of designing systems offering usefulness, ease of use and well-being. It also draws upon scientific knowledge relating to human-computer interaction (HCI). It seeks to remedy the fact that “Constructing systems based on an inappropriate or incomplete understanding of user needs is one of the main sources of systems failure” [ISO 10].

This approach applies to the whole of the User eXperience – i.e. “the experience the product creates for the people who use it in the real world” [GAR 10]. Put more specifically, this experience results from the set of perceptions, interactions or feelings that a user may have regarding a product, a system or a service before, during and after use of the device. This User eXperience (or “UX”) may relate to the experience of use in different contexts, the emotional experience, the aesthetic experience, the experience of customer support (purchase, installation, after-sales service, etc.), or to the values which the user associates with the product, etc. Thus, the aim of UCD

C op

yr ig

ht ©

2 01

3. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Introduction to the Methods Employed 15

is to design products, services and systems which offer the user the most positive experience possible.

This approach is applicable both for products and software, and both for public audiences and professional situations.

The UCD approach is described in the norm ISO 9241-210 [ISO 10]. This norm describes UCD by way of six principles:

1. The design is based upon an explicit understanding of users, tasks and environments.

2. Users are involved throughout design and development.

3. The design is driven and refined by user-centered evaluation.

4. The process is iterative.

5. The design addresses the whole User eXperience.

6. The design team includes multidisciplinary skills and perspectives.

According to this norm, UCD is a process which has four main stages, and which is iterative on all or some of these stages, as illustrated by the following diagram (see Figure 2.6).

Figure 2.6. The four main phases of UCD, based on the schema given in ISO 9241-210 [ISO 10]

C op

yr ig

ht ©

2 01

3. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

16 User-Centered Agile Method

The first stage is aimed at “understanding and specifying the context of use” of the future system: one of the objectives is to collect information about the pertinent characteristics of the future users (or groups of users) in relation to the service needing to be designed: for instance, their skills, their experience in the use of existing products, their physical characteristics, etc. It is also a question of identifying the users’ objectives and the characteristics of the tasks relative to the future system. Finally, the third objective relates to the description of the environment (technical, physical, social and cultural) or environments in which the future system will be used. A variety of methods may be used during this stage, such as observation, interviews, focus groups, etc.

The second stage consists of “specifying the user requirements”: these requirements are constraints stemming from the context of use previously described, and indeed from the knowledge or norms relating to the ergonomics and the user interface. These requirements also relate to the usability4 of the system in question, or they may be organizational in nature. “User requirements provide the basis for the design and evaluation of interactive systems to meet the user needs” [ISO 10].

The third stage consists of “producing design solutions”: on the basis of the previous stages, the objective here is to define the user tasks in relation to the system, the user-system interaction and the user interface. Depending on the state of advancement, the design solutions devised can range from a scenario to a prototype. They must be modified and supplemented as evaluations are carried out.

The fourth stage consists of “evaluating the design”: this stage is essential in the context of UCD. It must be instigated at the very earliest stages of the project, and may continue in the long term even up until the actual usage of the system by the user in their environment. According to ISO 9241-210 [ISO 10], “user-based testing” (hereafter referred to as “user testing” for the purposes of this book) and “inspection-based evaluation” (carried out by experts) are the two most frequently-employed approaches. The main objectives of these evaluations are to continue to progress in the

4 Extent to which a system, product or service can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use [ISO 10].

C op

yr ig

ht ©

2 01

3. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Introduction to the Methods Employed 17

understanding of the users’ needs and to evaluate the extent to which the design solutions conform to the requirements. The improvement points identified during the evaluation serve to validate a solution which satisfies the user requirements or serve as a basis for the design of the next version.

UCD is very widely used in ergonomics. According to the definition given by the International Ergonomics Association5, “ergonomics (or human factors) is the scientific discipline concerned with the understanding of the interactions among humans and other elements of a system, and the profession that applies theoretical principles, data and methods to design in order to optimize human well-being and the overall system.”

The benefits of UCD are many and increase the Return On Investment (ROI) [ISO 10]. Baccino et al. [BAC 05] offer a summarized view of these benefits as: reduced costs in terms of development and user support, improved productivity, satisfaction, safety, quality and learning, and finally increased revenues.

2.3. User testing method

User testing is one of the techniques used as part of UCD (see the previous section). This technique is essential in ergonomics, as it is useful for evaluating the usability of the device by presenting the end user (or a representative of the end user) with the device, on concrete terms. This technique also enables us to continue to collect information about the use context.

In the earliest phases of design, evaluations can be made on the basis of simple screen sketches. These can be used to pick up on the shortcomings in early versions and obtain feedback on the earliest design choices. Then, as the design process advances, the prototypes will become more and more functional. The objective then will be more to evaluate the extent to which these prototypes satisfy the user requirements and the usability of the solution. It should be noted that the prototypes, even if they can only be partially functional, must be realistic (in terms of titles and content) from a user’s point of view, and must not contain bugs, so that the user can gain a

5 Website of the International Ergonomics Association: http://www.iea.cc/.

C op

yr ig

ht ©

2 01

3. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

18 User-Centered Agile Method

mental projection of what the actual, full use would be like. In no case should user testing be taken to be a functional qualification test.6 Finally, on commercialized versions of the product, user testing may be helpful with a view to creating a new version.

User testing involves placing the participant in a situation of use of the device by staging realistic scenarios – i.e. scenarios that are close to real- world usage (see Figure 2.7). An example might be: “You have just moved into a new apartment. You wish to install a telephone line. You are looking on your telecommunication operator’s Website for information regarding this service”. Each test is carried out on an individual basis, and lasts for around one and a half hours. The tests are generally recorded so as to facilitate the task of data analysis. The participants in the tests must be representative of the target audience.

Figure 2.7. Illustration of a participant undertaking a test scenario, whilst an ergonomist in the control room observes and takes notes

With regard to the number of people who need to carry out this test, recommendations vary within the existing body of literature, from between five and fifteen. In practice, it tends to be 10 ± 2. For Nielsen and Landauer [NIE 93], a cohort of five individual test users is sufficient to identify 85% of problems with usability. In the eyes of Baccino et al. [BAC 05], 10-15 users, minimum, would be necessary for statistical calculations. Later studies built on the results reported by Nielsen and Landauer, added certain nuances: Faulkner [FAU 03], while he does not refute the above claim, adds that with

6 Functional qualification tests are intended to put actions in place which will verify whether the product or system can deliver the performances required of it, and functions correctly in the intended target environment.

C op

yr ig

ht ©

2 01

3. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

Introduction to the Methods Employed 19

a group of 10 users we can be more certain of identifying 80% of problems (95% with 20 users); for Woolrych and Cockton [WOO 01], this figure of five users could be re-evaluated depending on the heterogeneity of the users, the complexity of the tasks and the rigorousness of the test protocol. Yet it must not be forgotten that the feedback from even a single user is interesting and valuable (Nielsen and Landauer hold that a lone tester can identify on average, nearly 30% of problems), because even this information can be used as input for the task of improvement.

When drawing up the test protocol, the evaluator, who is trained in this technique, should be familiar with the interface being evaluated and the context of use for which it is intended. Thus, he is able to identify the critical points which will serve as a basis for writing the scenarios, and is able to design realistic scenarios for the user. He will then choose the data- collection methods which are able to serve the objectives of the evaluation. The norm ISO 16982 [ISO 02] gives an inventory of most of these methods. The observation method is at the root of user testing, as it enables the evaluator to gather objective data about behavior, performances, problems encountered and paths taken during the test session. The measured performance indicators might include, e.g. the time taken to complete a task, the number of errors, the time taken to correct an error, the number of times a user has given up on a task, etc. The technique of “thinking aloud” is another essential method to use when conducting the tests. This involves asking the tester to verbalize his thought process, either during the realization of the scenario or once it has been completed. The objective of these verbalizations is to obtain information about the mental processes at work, and thereby to gain a fuller understanding of what is being or has been observed. Questionnaires and interviews also are methods which are very widely used during a test session. Thus, at the end of the test, the evaluator can ask a set of questions in order to glean information about the general impression (opinion, satisfaction, esthetics, etc.). Other techniques may also be applied, such as “eye-tracking” or the collection of log files (these are files which record the path taken by the user when interacting with the system via the interface).

By analyzing the data collected from such user testing, we can identify problems in usability, interpret them and go on to suggest avenues for improvement.

C op

yr ig

ht ©

2 01

3. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed

C op

yr ig

ht ©

2 01

3. J

oh n

W ile

y &

S on

s, In

co rp

or at

ed . A

ll rig

ht s

re se

rv ed