Essay: Agile development

Essay details:

  • Subject area(s): Project management essays
  • Reading time: 7 minutes
  • Price: Free download
  • Published on: August 29, 2019
  • File format: Text
  • Number of pages: 2
  • Agile development
    0.0 rating based on 12,345 ratings
    Overall rating: 0 out of 5 based on 0 reviews.

Text preview of this essay:

This page of the essay has 1734 words. Download the full version above.

One of the requests from the collaborating companies to the usability and UX methods were they should fit the Scrum development rhyme.

To understand agile development, we have to understand what it breaks with. If a software project adapts a traditional development framework e.g. the waterfall approach, the requirements have to be defined upfront. Nowadays, this can be a problem, since requirements for a product can change from one day to another, new technologies can emerge, etc. This potential entails problems with adherence to deadlines and can end up causing large unexpected expenses.

In The Agile Samurai, Rasmusson et al. (2012) state that in a development process:

• You can’t gather all the requirements up front.

• The requirements you do gather will change.

• There is always more to do than time and money will allow.

The Agile Samurai, Rasmusson et al. (2012)

Three points, agile development processes consider. Agile software development processes are a family of development frameworks e.g. Scrum and XP. These development frameworks share a common philosophy, stated in Agile Manifesto (2001). The four main values are:

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan

(Agile Manifesto, 2001)

By employing an agile development framework, a company has the ability to respond to shifting requirements in the project. Furthermore, the collaboration between the development team and the customer becomes transparent since they collaborate closely, combined with the possibility of having the customer providing continues input and feedback to the development process.

In late 2013, Ambler and colleagues sent out a survey concerning i.a. traditional and agile software development. The survey had 173 respondents. The result from the survey revealed that projects using a traditional development approach were three times more often to fail than projects following an agile development approach, see Figure 1.

Figure 1. The rate of successful, challenged and failed projects in agile vs. traditional projects(Ambler et al., 2014).

Several different agile development frameworks exist. Contribution 2 in this thesis reviled Scrum to be the favorite agile framework used within the Danish industry. Scrum is furthermore the development framework used within the collaborative companies.

1.2.1. SCRUM

Scrum is an iterative and incremental framework, developed to optimize predictability and risk control. (Sutherland and Schwaber, 2011) Scrum has been used in software development since the beginning of 1990’s. It is important to note, that Scrum is not a process or technique for building products, but a framework where it is possible to apply different processes and techniques within. (Sutherland and Schwaber, 2011)

The premise for Scrum is that software development can be a very complicated and unpredictable process. [REF] Hence, the foundation of Scrum is based on empiricism, meaning that knowledge should come from experience, and decisions should be based on what is known. [REF] Figure 2 shows the Scrum process.

Figure 2. The Scrum framework [REF]

When applying the Scrum framework, you have a Scrum Team consisting of three roles: the product owner, the scrum master and the development team. The framework has four ceremonies: sprint planning; daily scrum(daily scrum); sprint review; retrospective and three roles: product owner; scrum master; the development team.

.

The primary artefact in Scrum is the Product Backlog. This backlog is a collection of requirements, often stated in user stories. The backlog is the project’s only source to the requirements. During Sprint planning the development team pulls backlog items into the sprint backlog. Normally a sprint duration is between two to four weeks (all the collaborating companies have sprint of three weeks duration). The primary ceremony in Scrum is the daily Scrum (daily stand-up), where the team have 15 minutes to talk about progress and obstacles in the work. At the end of the sprint, the whole team first performs a sprint review, often together with all stakeholders, the goal is to have a potentially shippable product increment that has been tested and is functional. To finalize the sprint, the team has a sprint retrospective to inspect itself and compose a plan for improvements, which can be executed during the next sprint.

1.3. USABILITY AND UX

When working with usability and UX it is important to have a shared understanding and foundation to the notion of especially UX. Different approaches exist when it comes to distinguish between usability and UX. However, all approaches agree upon UX originating from usability, and the change from usability towards UX includes a more positive, holistic, non-instrumental and hedonic view. [REF]

1.3.1. USABILITY

Usability is by the ISO 9241 standard defined as: “The extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.” [REF]

Usability engineering focuses on the ease of use and learnability, efficiency, memorability, errors and satisfaction of a product and on how the interaction can be measured. (Nielsen, 1994) Usability often focuses on executing tests with the focus on removing inferior and non-usable elements from a product, thus it is very risk oriented. [REF] Focus is on the efficiency of using the product rather than understanding how people experience the product. Hence usability methods have a more quantitative nature and include AB-testing, performance tests, usability evaluations, etc. [REF]

1.3.2. USER EXPERIENCE (UX)

Even though it is agreed that UX is originating from usability, no common definition of UX is agreed upon.

UX is by the ISO XX standard defined as: “Person’s perceptions and responses resulting from the use and/or anticipated use of a product, system or service” Furthermore, it is noted that: “User Experience includes all the users’ emotions, beliefs, preferences, perceptions, physical and psychological responses, behaviors and accomplishments that occur before, during and after use”. (ISO, 2010) A second note states: “User experience is a consequence of brand image, presentation, functionality, system performance, interactive behaviour and assistive capabilities of the interactive system the user’s internal and physical state resulting from prior experiences, attitudes, skills and personality, and the context of use”. (ISO, 2010)

In the User Experience White Paper by Roto et al. (2011) the term user experience is defined as: “An encounter with a system that has a beginning and an end. It refers to an overall designation of how people have experienced (verb) a period of encountering a system”. When dealing with the concept of UX three main factors can be classified:

1. Context: It is of importance to have in mind, that UX may change when the context changes.

2. User: The user is dynamic, hence UX is dynamic.

3. System: The UX properties designed into the product is important.

(Roto et al., 2011)

A fourth factor to have in mind, when working with UX, is as mentioned in the ISO standard and by the Roto et al. (2011), the time perspective. UX rely on the user’s emotions and attitudes towards e.g. the product, hence UX methods try to access these aspects and have a more qualitative nature. Examples of methods could be contextual inquiries, focus groups, interview, etc. [REF]

1.3.3. USABILITY AND UX IN THIS PROJECT

Moczarny et al. (2012) stated that UX and usability can relate to each other in three different perspectives, see Figure 4.

Figure 4. Three different perspectives on how usability and UX relate to each other. (Moczarny et al., 2012)

The definition of UX in the present work is that UX is a broader, superior area, one might say umbrella, which includes usability, see 1st perspective in Figure 4. This definition is in consistency with how Radiometer works with usability and UX e.g. nurses feel secure (have a good UX) when using the device due to the easiness of use (good usability).

1.3.4. USABILITY AND UX METHODS

The number of usability and UX methods is quite high. Ferre et al. (2005) counted 95 different methods and techniques. This is too large a sample to consider working with and some of them overlap quite much. I therefore make use of the list of methods presented at usabilitynet.org, since the variety in these methods is more extensive. This list from usabilitynet.org:

• Affinity diagramming

• Allocate tasks

• Attitude questionnaires

• Brainstorming

• Card sorting

• Competitor analysis

• Context of use analysis

• Contextual inquiry

• Cost-benefit analysis

• Critical incident analysis

• Design guidelines

• Diagnostic evaluation

• Evaluate prototype

• Evaluating an existing system

• Expert evaluation

• Field study

• Focus groups

• Getting started

• Heuristic evaluation

• Interviews

• Observation of users

• Parallel design • Participatory evaluation

• Paper prototyping

• Patterns

• Performance testing

• Planning usability

• Pleasure

• Post release testing

• Prototyping

• Questionnaires

• Rapid prototyping

• Remote testing

• Requirements meeting

• Scenarios of use

• Stakeholder meeting

• Storyboarding

• Style guides

• Subjective evaluation

• Surveys

• Task analysis

• Usability testing

• Use cases

• User satisfaction

• Wizard of OZ

(usabilitynet.org, 2015)

To narrow down the list and judge which methods would be more appropriate to be used by the developers, further selection had to be done. First some selection criteria were formed from the setting, I was working in:

• The methods were to be used under the more formative phases in the development. Hence, methods more suitable for the initial phase (e.g. user studies and surveys) and the more extensive evaluation phase (e.g. usability evaluations and expert reviews) were not selected .

• The methods should be fairly easy to lean, plan, conduct and analyze, since non experts are to perform them.

• More…

Furthermore, the collaborating companies had some wishes and requests for the methods. The methods should:

• Enabling the developers to perform delimited formative testing (Radiometer and SenDx)

• Enabling the developers to get to know the end-users (Radiometer)

• Feed directly into the development process (Radiometer and SenSx)

• Provide a simple way to gather insights of user behavior (Radiometer, SenDx and TC Electronic)

• Fit into the companies agile development process (Radiometer, SenDx and TC Electronic)

From these selection criteria a short list of the potential suitable methods were made:

• Observations

• AB-testing

• Different lightweight methods such as:

o Instant Data Analysis (IDA) (Kjeldskov et al., 2004)

o Rapid Iterative Testing and Evaluation (RITE) (Medlock et al., 2002)

• Heuristic Evaluation (Nielsen and Molich, 1990)

• Cognitive walkthrough (Polson et al., 1992)

• Think aloud test (Lewis, 1982)

• Focus groups (Krueger and Casey, 2001)

Due to the duration of the PhD study, three methods were selected in consultation with the companies. The methods were:

• Focus group technique, modified by (Øvad and Larsen, 2014). This is denoted Focused Workshop. For details see Contribution X and Y.

• Comparative usability testing, modified by (Øvad et al., 2015). This is denoted AB-testing. For details see Contribution X and Y.

• Contextual Inquiry as described by (Beyer and Holtzblatt, 1997; Holtzblatt et al., 2005) and modified by (Øvad and Larsen, 2016). This is denoted Contextual Interview. For details see Contribution X and Y.

...(download the rest of the essay above)

About this essay:

This essay was submitted to us by a student in order to help you with your studies.

If you use part of this page in your own work, you need to provide a citation, as follows:

Essay Sauce, Agile development. Available from:<https://www.essaysauce.com/project-management-essays/agile-development/> [Accessed 18-11-19].

Review this essay:

Please note that the above text is only a preview of this essay.

Name
Email
Review Title
Rating
Review Content

Latest reviews: