Agile Software Development

(SE3823)
Ibrar Arhsad
ibrar.arshad@cust.edu.pk
PROJECT WHERE AGILE CAN BE APPLIED

• Small to medium-sized software developments

• Product development where multiple variants are required or
desirable
• Where the main deliverable can be broken down and produced
(and even potentially released or at least accepted by the end
customer) in incremental discrete packages
 However, the requirements and functions developed during each
iteration must be stand-alone and not have major dependencies with
other requirements and functions outside of the current iteration
SE 3823 Agile Software Development 2
AGILE METHODOLOGY MYTHS

• Agile is new (No true)

 No, agile is not new
 The Agile Manifesto was published in 2001
 The Scrum Pattern language was presented in 1995 during the Object
Oriented Programming, Systems, and Languages (OOPSLA) conference
 The Episodes pattern language (the forerunner of Extreme
Programming—XP) was described in PLoP 1995, Tom Gilb’s Evo
method dates back to 1976, and there are some who trace agile’s
roots back further still

SE 3823 Agile Software Development 3

AGILE METHODOLOGY MYTHS CONT..

• Agile means having no documentation

 While some people believe that being agile means one doesn’t need any
documentation, that’s hardly the truth; you can have as much
documentation as you like in agile
• Agile means “no design”
 No, being agile does not mean that there should be “no design”
 Design is inherent all the way through development, at every planning
meeting, and more
 In regards to this myth, however, agile does mean that you don’t need a big
up-front design that is invalidated five minutes after someone starts coding

SE 3823 Agile Software Development 4

AGILE METHODOLOGY MYTHS CONT..

• Agile means no planning

 Again, this myth is another “no”
 Agile probably requires more planning on part of a team
 Again, planning is spread throughout the whole development
exercise rather than at the front, and it involves the work of
everybody rather than one or two anointed individuals

SE 3823 Agile Software Development 5

AGILE METHODOLOGY MYTHS CONT..

• There is a right size for a user story

 There is no right size for a user story, every team is different—get
over it
 There are two rules for a user story or any other kind of
development story
• First, it should be small enough to be delivered sometime soon, i.e. it will not
take months and months
• Second, it has business value in its own right, i.e. someone somewhere can
say why it is valuable

SE 3823 Agile Software Development 6

AGILE METHODOLOGY MYTHS CONT..

• Work must fit in a sprint

 If you are doing hardcore Scrum then yes, each story should start and end inside the
same sprint but not all teams practice hardcore Scrum
 Many teams allow stories to overlap or break the stories down in some way
• Developers get to do what they like
 No, developers do not get to do what they like, if this is true for you then you are
doing it wrong
 Agile needs well-disciplined teams, what gets done should be lead from a specific
role, usually designated the customer or product owner
 If developers are doing what they like then there is a good chance something is
wrong with that role, the person playing it, or the authority vested in it

SE 3823 Agile Software Development 7

AGILE METHODOLOGY MYTHS CONT..

• Agile doesn’t work for fixed deadline projects

 Agile works best in fixed-deadline project environments. When team
members use agile, particularly the Scrum and XP versions, they receive
much of their power from the harnessing deadline effects: sizing work
to the deadline, individual motivation and willingness to renegotiate
just what is being built to meet a date
• Agile “out of the box” is good for every project
 When applying Agile to large projects and distributed development
teams or very large teams, some modifications and care need to be
taken to provide for their unique needs and requirements
SE 3823 Agile Software Development 8