Xxxx Xxxxxxxx 1 The Agile Development Process .docx

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 ...

1. 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,

2. 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].

3. 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

4. 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

5. 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

6. 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]

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.

8. 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

9. 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

10. 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.

11. 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:

12. 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

13. [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



http://dx.doi.org/10.1145/2133806.2133823
http://dx.doi.org/10.1145/1060710.1060712



ENC 3246: PROF COMM ENGINEERING – TECHNICAL
PROCESS PAPER

Writing and Submission Requirements


Length: 1500 words, minimum
Format: IEEE citation style, double-spaced, 12 pt serif font,
page numbers in upper right corner
(see additional instructions below)
Submission: Turn text in to E-Learning as an attached document
in Word format (.docx). Name the file using

your full name and the name of the assignment (e.g.: Emory
Smith Tech Process.doc).

Assignment Prompt and Context


Engineers constantly communicate technical

information. Two kinds of technical information get

frequent mention by practicing engineers: technical

14. terminology and process/procedures.

At the same time, the technical expertise of readers

varies, ranging broadly from: (1) non-expert clients

to (2) peers who share similar training to (3)

managers whose skill sets may or may not overlap

with the engineers working on a project.

For this paper, you will choose a process in your field

of engineering and write a short “white paper” about it. White
papers can be used within an organization for the

purpose of informing peers as well as externally to educate
clients or the public. Technical language is usually

defined within the context of the paper, with key terms getting
longer explanation.

Structure of the Technical Process Paper

The Technical Process Paper will have three sections, each
designated by an appropriate subheading. You may

use second-level subheadings as needed.



o In this section, the writer will explain why the process was
developed -- what engineering

15. problem or situation did the process solve?

– claims such as
“society needed” or

“manufacturers wanted” are too general.

development of additive

manufacturing?



o In this section, the writer will explain how the process works
as currently practiced. This is a

general explanation of the process, emphasizing principles of
operation.

general?

https://en.wikipedia.org/wiki/White_paper


tion 3: Detailed Example of the Process

o In this section, the writer will show how the process is
applied by carefully explaining an

example of the process in action.

manufacturing?

16. Goals

The goals of this assignment are to (1) communicate effectively
to a mixed audience, (2) use credible sources to

support your work (3) explain how the process relates to
contemporary issues related to your field, (4) create

figures appropriate to a communication task.

Other Instructions

1) The paper must have at least the three sections designated
above.

2) Each section must have at least one figure/image created by
the writer that is appropriate to that

section.

a. See the “Smart Art” options in Word for lots of templates
supporting this task.

b. More figures may be used. These may be published images or
ones created by the writer. Make

sure to cite images correctly.

3) The paper must have at least 6 high quality sources, with a
minimum of 2 unique sources per section.

a. “High quality” means sources from academic journals and
highly rated trade publications (such

as the magazines published by professional organizations).
General-use, public sources are NOT

17. allowed, except for images. Each instance of a low-quality
source will result in a 5% reduction in

grade.

b. Include both in-text citations as needed and a References list
in IEEE format.

4) The paper must have a title, and include a Table of Contents
(TOC) and Table of Figures (TOF).

a. TOCs can be created automatically using the Table of
Contents function in the References menu.

To use this function, simply use the Word Style Menu to create
subheadings. For TOFs, use the

“Insert Caption” function (located in References menu) to add
labels to images.

5) Stylistically, the paper is written in the 3rd person, for a
mixed audience. Technical language is allowed,

but important terms should be defined more extensively as this
kind of paper is meant to inform and

educate.

a. Do not use the second person (you/your/you’re).

b. Expand important terms using one or more of the extended
definition strategies discussed in

Technical Communication:

18. i. Parenthetical/Sentence

ii. Graphics

iii. Examples

iv. Partition

v. Principle of Operation

vi. Comparison/Contrast

vii. Analogy

viii. Etymology