Technical Paper due in 12 hours

Xxxx Xxxxxxxx 1

The Agile Development Process

History of the Agile Process

In the 1990’s, the field of software development was dominated by the Waterfall

process. This process focused on meeting the strict requirements given by the client, with

no room for flexibility [1]. Specifically, developers would receive explicit documentation on

the requirements needed for a certain piece of software. Then, the developers would

continue linearly with the design and implementation of this software, without consulting

the client for any further assistance. Then only upon completion of the project, they would

present the software to the client [2]. See Figure 1 below for an illustration of this process.

Figure 1: Overview of the Waterfall process. Development proceeded linearly, implementing the client’s requirements over one iteration. However, the needs of the industry changed. Over time, it no longer became

economical to adhere to a linear development process [1]. Developers would design and

Xxxx Xxxxxxxx 2

implement software according to the clients’ requirements, but upon completing the

products, the clients wanted parts of it to be modified. It became extremely time-

consuming and expensive to change parts of the software that had already grown so large

and complicated [3]. Hence, the process model needed to be changed.

In 2001, 17 individuals who supported a more economical development process

gathered and developed what is now known as the Agile development process [1]. This

process embraces the creation of desirable software without excessive documentation, the

input of the customer, and navigating change [1].

The Current State of the Agile Process

Define Requirements

The first step in the Agile process for developing a piece of software is to receive the

requirements from the client. These requirements are the features, performance needs, and

other constraints that the client wants at that particular time [2]. Even though these

requirements are introduced in the beginning, the Agile process welcomes change in the

requirements as the software is developed [4].

Develop Functionality

After receiving specifications from the client, the developers will assess these

requirements and determine what they can accomplish in a sprint. A sprint is a short

period of time, usually around one to two weeks, where a small group of developers focus

on implementing certain parts of the product needed [5]. There are multiple sprints within

the development life cycle of the process, promoting room for variation as clients’ needs

Xxxx Xxxxxxxx 3

and developers’ capabilities change [5]. The chosen requirements for the sprint are then

delegated to each team member depending on their abilities.

There is a structure to each of these sprints. The team meets daily and holds a stand-

up meeting. This is a short meeting, usually about 15 minutes long, where the team is

informed of the current status of development [6]. Each team member takes their turn

speaking individually. They describe what they have accomplished in the past day, the

problems they have encountered along the way, and what they plan to work on before the

next stand-up meeting [6]. This allows each team member to remain accountable for their

work and see how their contributions fit into the context of other team members’ work.

Sprint Retrospective

At the end of each sprint, the team holds another meeting called the sprint

retrospective. During this meeting, the team reflects on what they were able to accomplish

and areas of weakness that appeared during the sprint [4]. The team can discuss factors

such as how many of the required features were implemented or events that impeded

development [5]. Considering this reflection, the team brainstorms ideas about how they

can improve their performance. Based on these ideas, they then set guidelines to follow in

the next sprint, hoping to adjust their behavior for increased productivity [4].

Client Feedback

Additionally, development teams hold meetings with the client at the end of each

sprint. The team presents to the client the features they implemented during the sprint [5].

The client then can express satisfaction or dissatisfaction towards the features

Xxxx Xxxxxxxx 4

implemented. The client may not have expected a feature to turn out the way it did and

could request to have it changed. The client may also decide that a new feature should be

added. The Agile process welcomes this feedback [2]. The team documents the client’s

feedback and uses it to drive their goals for the next sprint.

This cycle of development, reflection, and adjusting the approach continues in the

form of these sprints until the project is complete. This occurs either when the client is

satisfied or the development team has reached its maximum capability [6]. Figure 2

illustrates the cyclic nature of the Agile process.

Figure 2: Illustration of Agile development process. The process consists of developing functionality, demoing the functionality implemented, getting feedback from the client, and making changes. Then this process is repeated again until the project is complete. [7]

Xxxx Xxxxxxxx 5

The Agile Process in Action

Juxt is a software development company that works with clients to create the

websites that suit their business needs. The company uses the Agile process for most of

their development, since they find it to be effective (See Figure 3). Their most recent client

is an entrepreneur who wishes to run a website where he can sell products he buys from

Japan to citizens in the US. He meets with six developers from the team and explains the

features he wants on this website [6]. He expresses that he wants to be able to display the

items he has in stock, functionality for customers to buy his items, and an interface where

he can easily enter his inventory.

Figure 3: Agile components used by the Juxt team and each benefits their workflow.

Xxxx Xxxxxxxx 6

After this meeting with the client, the team meets and discusses what their plan of

action will be for the first sprint. They delegate small tasks to each team member and set

goals so that the team can finish these tasks in time [6]. For example, one of the developers

is assigned the task of launching the database that the client will use for entering his

inventory. Another developer is responsible for constructing the basic layout that the

website will have [8].

For the duration of the two-week-long sprint, the developers focus on implementing

the tasks assigned to them. Every day, they have a 15-minute stand-up meeting [8]. One of

the developers, Rebecca, explains that in the past day she has created the layout of the

products page and is able to populate the page with items from the database. However, she

says that she is having issues implementing an algorithm to sort the page by best-selling

items [8]. She plans to research commonly used sorting algorithms in the online

marketplace field. Another developer, Robert, speaks up and tells Rebecca that he has

experience working with this kind of feature. He provides Rebecca with a link that contains

useful information about sorting items by popularity.

At the end of this sprint, the development team holds their sprint retrospective.

During their reflection about the development process, a team member named Brian

speaks up about an issue the team encountered [9]. Brian was responsible for reviewing

the code that each developer produced. He found that the code organization was hard to

understand, as the filenames were vague and did not properly describe the code’s function.

Thus, reviewing the code was a time-consuming process. The team brainstorms solutions

to this problem and suggests in the next sprint to adapt a strict naming convention for the

Xxxx Xxxxxxxx 7

filenames [9]. This will allow Brian to spend less time reviewing the code and this become

more efficient.

In addition to this sprint retrospective, the team meets with the client to present the

features they have implemented so far. Upon showing the client the current appearance of

the website, the client observes that the team’s use of a sidebar for navigation seems

outdated [8]. He decides he wants a horizontal navigation bar at the top of the page for a

more modern look. The team hasn’t gotten too far into the construction of the website, so

changing the navigation bar’s style will not be difficult [8].

With this feedback from the client, they are able to plan the tasks for next sprint.

They adjust their approach to the development of the website and assign a developer to

implement the change the client suggested [5]. The team continues sprints similar to this

one until the client deems the website acceptable for use.

Xxxx Xxxxxxxx 8

References

[1] L. Williams, “What Agile Teams Think of Agile Principles”. Communications of the ACM,

vol. 55, issue 4, pp 71-76, April 2012. DOI: 10.1145/2133806.2133823

[2] S. Nerur et al., “Challenges of Migrating to Agile Methodologies”. Communications of the

ACM, vol. 48, issue 5, pp 73-78, May 2005. DOI: 10.1145/1060710.1060712

[3] P. Laplante and C. Neill, “The Demise of the Waterfall Model Is Imminent”. Queue - Game

Development, vol. 1, issue 10, pp. 10-15, February 2004. DOI: 10.1145/971564.971573

[4] D. Largent, “Getting and staying agile”. XRDS: Crossroads, vol. 17, issue 1, pp. 38-41, Fall

2010. DOI: 10.1145/1836543.1836555

[5] Hakim et al., “Sprint: Agile specifications in Shockwave and Flash”. DUX ’03 Proceedings

of the 2003 conference on Designing for user experiences, pp 1-14, 2003. DOI:

10.1145/997078.997111

[6] J. Bergin, “Patterns for agile development practice part 3 (version 4),” in PLoP

'06 Proceedings of the 2006 conference on Pattern languages of programs, ACM. DOI:

10.1145/1415472.1415475

[7] Agile1, http://www.strategybeach.com/wp-content/uploads/2013/09/Agile1.png,

http://strategybeach.com/our-agile-development-methodology/,

accessed on 6/6/2016

[8] O. McHugh et al., “Agile Practices: The Impact on Trust in Software Project Teams”. IEEE

Software, vol. 29, issue 3, pp. 71-76, 2012. DOI: 10.1109/MS.2011.118

[9] R. Wirfs-Brock, “Designing with an Agile Attitude”. IEEE Software, vol. 26, issue 2, pp.

68-69, 2009. DOI: 10.1109/MS.2009.32