The Agile Movement

The Agile
Movement
Modelos de Procesos y
Metodologías de Ingeniería de
software
Mayo de 2014
Universidad de Caldas
Facultad de Ingenierías
Maestría en Ingeniería Computacional

Content
Agile Methologies
The Agile Manifesto
Concrete agiles examples
CMMI & Agile

Sources
• Gerard O’Regan, Introduction to Software Process Improvement, Springer
2011. ISBN 978-0-85729-171-4
• Kenneth S. Rubin. Essential Scrum : a practical guide to the most popular
agile process. Copyright 2013 Pearson Education, Inc. ISBN 978-0-13-
704329-3
• Scott Ambler and Mark Lines. Disciplined Agile Delivery. A Practitioner’s
Guide to Agile Software Delivery in the Enterprise. Copyright 2012, IBM
Press. ISBN 978-0-13-281013-5.
• Joachim Rossberg and Mathias Olausson. Pro Application Lifecycle
Management with Visual Studio 2012. Apress, 2012. ISBN 978-1118314081
• Alan Shalloway et al. Essential Skills for the Agile Developer - A Guide to
Better Programming and Design. Copyright © 2012 Pearson Education, Inc.
ISBN 978-0-321-54373-8.
• Paul E. McMahon. Integrating CMMI® and Agile Development. 2011
Pearson Education, Inc. ISBN 978-0-321-71410-7.

Agile Introduction (I)
The Agile methodology / Agile development is a
software development methodology that claims
to be more responsive to customer needs than
traditional methods.

Agile Introduction (II)
Agile has a strong collaborative style of working and its
approach includes the following:
– Aim is to achieve a narrow fast-flowing value stream
– Feedback and adaptation employed in decision-making
– User stories and sprints are employed
– Stories are either done or not done
– Iterative and incremental development is employed
– A project is divided into iterations
– An iteration has a fixed length (i.e. Timeboxing is employed)
– Entire software development life cycle is employed for the
implementation of each story
– Change is accepted as a normal part of life in the Agile world

Agile Introduction (III)
– Delivery is made as early as possible
– Maintenance is seen as part of the development process
– Refactoring and evolutionary design employed
– Continuous integration is employed
– Short cycle times
– Emphasis on quality
– Stand-up meetings
– Plan regularly
– Direct interaction preferred over documentation
– Rapid conversion of requirements into working functionality
– Demonstrate value early
– Early decision-making

A tale about Agile (I)
In 2001 a group of people met at a Utah ski resort to talk, ski,
relax, and try to find common ground for software development.
This is the result:
“We are uncovering better ways of developing software by
doing it and helping others do it.
Through this work we have come to value:
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
That is, while there is value in the items on the right, we
value the items on the left more.”

A tale about Agile (II)
That is, while there is value in
the items on the right, we value
the items on the left more.
Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas

www.agilemanifesto.org (I)
“On February 11-13, 2001, at The Lodge at
Snowbird ski resort in the Wasatch mountains of
Utah, seventeen people met to talk, ski, relax, and
try to find common ground and of course, to eat.
What emerged was the Agile Software
Development Manifesto. Representatives from
Extreme Programming, SCRUM, DSDM, Adaptive
Software Development, Crystal, Feature-Driven
Development, Pragmatic Programming, and others
sympathetic to the need for an alternative to
documentation driven, heavyweight software
development processes convened.”

www.agilemanifesto.org (II)
the Agile Manifesto lays down the following principles:
• Our highest priority is to satisfy the customer through
early and continuous delivery of valuable software.
• Welcome changing requirements, even late in
development. Agile processes harness change for the
customer’s competitive advantage.
• Deliver working software frequently, from a couple of
weeks to a couple of months, with a preference to the
shorter timescale.
• Business people and developers must work together
daily throughout the project.

www.agilemanifesto.org (III)
• Build projects around motivated individuals. Give
them the environment and support they need, and trust
them to get the job done.
• The most efficient and effective method of conveying
information to and within a development team is face-
to-face conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development.
The sponsors, developers, and users should be able to
maintain a constant pace indefinitely.
• Continuous attention to technical excellence and
good design enhances agility.

www.agilemanifesto.org (IV)
• Simplicity—the art of maximizing the amount of work
not done—is essential.
• The best architectures, requirements, and designs
emerge from self-organizing teams.
• At regular intervals, the team reflects on how to
become more effective, then tunes and adjusts its
behavior accordingly.
More about Agile history in:
http://setandbma.wordpress.com/2012/03/23/agile-history/

• SEMAT Deal (www.semat.org)
• The new deal for software development
(http://www.software-development-
experts.com/the-new-deal.aspx)
But, be careful with “Deals”

• Ongoing changes to requirements are
considered to be normal in the Agile world,
and it is believed to be more realistic to
change requirements regularly throughout the
project rather than attempting to define all of
the requirements at the start of the project.
• The methodology includes controls to
manage changes to the requirements, and
good communication and early regular
feedback are an essential part of the process.
Agile features - changes

• A story may be a new feature or a modification to an existing
feature. It is reduced to the minimum scope that can deliver
business value, and a feature may give rise to several
stories.
• Stories often build upon other stories and the entire software
development life cycle is employed for the implementation of
each story. Stories are either done or not done, i.e. there is
no such thing as a story being 80% done. The story is
complete only when it passes its acceptance tests.
• Stories are prioritized based on a number of factors including
– Business value of story
– Mitigation of risk
– Dependencies on other stories
Agile features – user stories

• Sprint planning is performed before the start of an
iteration. The goal is to assign stories to the iteration
to fill the available time. The estimates for each
story and their priority are determined, and the
prioritized stories are assigned to the iteration.
• A short morning stand-up meeting is held daily
during the iteration and attended by the project
manager and the project team. It discusses the
progress made the previous day, problem reporting
and tracking, and the work planned for the day
ahead. A separate meeting is conducted for issues
that require more detailed discussion.
Agile features – planning

• Once the iteration is complete the latest product
increment is demonstrated to an audience including
the product owner.
• This is to receive feedback as well as identifying
new requirements.
• The team also conducts a retrospective meeting to
identify what went well and what went poorly during
the iteration. This is to identify improvement actions
for future iterations.
Agile features – delivery

• Agile employs pair programming and a collaborative
style of working with the philosophy that two heads
are better than one.
• This allows multiple perspectives in decision-making
and a broader understanding of the issues.
Agile features – pair programming

• Software testing is very important and Agile
generally employs automated testing for unit,
acceptance, performance, and integration testing.
• Tests are run often and aim to catch programming
errors early. They are generally run on a separate
build server to ensure all dependencies are
checked.
• Tests are re-run before making a release.
• Agile employs test driven development with tests
written before the code. The developers write code
to make a test pass with ideally developers only
coding against failing tests.
• This approach forces the developer to write testable
code.
Agile features – testing

• Refactoring is employed in Agile as a design and
coding practice.
• The objective is to change how the software is
written without changing what it does.
• Refactoring is a tool for evolutionary design where
the design is regularly evaluated and improvements
implemented as they are identified.
• The automated test suite is essential in showing that
the integrity of the software is maintained following
refactoring.
Agile features – refactoring

• Continuous integration allows the system to be built
with every change.
• Early and regular integration allows early feedback
to be provided.
• It also allows all of the automated tests to be run,
thereby identifying problems earlier.
Agile features – integration

• AMDD
• Agile Modelling - Scott Ambler
• http://www.agilemodeling.com/style/
• TDD
• Refactoring
• Unit Testing
• Continuous Integration
• Pair development
• User stories
• Releasing
Most representative contributions

• http://www.extremeprogramming.org/
• http://xprogramming.com/index.php
• Extreme Programming (XP) is a
deliberate and disciplined approach
to software development. It stresses
customer satisfaction, an important
part of the Agile Manifesto. The
methodology is designed to deliver
the software the customer needs,
when it is needed. XP focuses on
responding to changing customer
requirements, even late in the life
cycle, so that customer satisfaction
(business value) is assured
eXtreme Programming (I)

• All code to be included in a production release is created by two
people working together at a single computer. This should
increase software quality without impacting time to delivery.
• The software should be delivered to the customers as early as
possible and a goal is to implement changes as suggested. XP
stresses that the developers should be able to courageously
respond to changing requirements and technology based on this
foundation.
• XP have user stories. These serve the same purpose as use
cases, but are not the same. They are used to create time
estimates for the project and also replace bulky requirements
documentation. The customer is responsible for writing the user
stories and they should be about things that the system needs to
do for them. Each user story is about three sentences of text
written by the customer in the customer’s own terminology without
any technical software jargon that a developer might use.
eXtreme Programming (II)

• XP also emphasizes teamwork. Managers, customers, and
developers are all part of a team dedicated to delivering high-
quality software. XP implements a simple and effective way to
handle team work.
• There are four ways XP improves software team work;
communication, simplicity, feedback, and courage.
• It is essential that XP programmers communicate with their
customers and fellow programmers. The design should be simple
and clean. Feedback is supplied by testing the software from the
first day of development.
• Testing is done by writing the unit tests before even writing the
code. This is called TDD and has started to become a very well
used practice in many projects, not only agile ones.
• Another important issue is that XP stresses the importance of
delivering working software in increments so that the customer
can give feedback as early as possible. By expecting that this will
happen, developers are ready for implementing changes.
eXtreme Programming (III)

SCRUM
Source:http://www.mozaicworks.com/agile/scrum/
Source:SCRUM México  http://scrum.org.mx/?page_id=7
“the rugby approach” (1986) - Harvard Business Review
Takeuchi and Nonacha argued that small cross-functional teams
produced the best results from a historical viewpoint.
http://www.sao.corvallis.or.us/drupal/files/The%20New%20New%
20Product%20Development%20Game.pdf

SCRUM (II) Source: http://www.axosoft.com/scrumvideo

SCRUM (III) Source: Disciplined Agile Delivery
The Scrum lifecycle

• Product backlog (work item list)
• Value-driven lifecycle
• Daily Scrum (coordination meeting).
• Sprint review and demonstration
• Sprint retrospective
• User story driven development (usage-driven
development).
See: http://www.implementingscrum.com/
SCRUM (IV)

• Release planning: it suggests abstracting the project plan to
a higher level that describes higher level milestones such as
delivery of small increments of demonstrable functionality.
These higher level plan items can then be allocated to a
set of sprints (iterations) over the life of the project.
• Sprint planning (iteration planning): At the beginning of the
sprint/iteration the team plans in detail what they will deliver
and how they will do the work. This involves taking a set of
highest priority requirements off the backlog and then
decomposing these requirements into detailed tasks. The
team estimates this work and commits to the product owner
that they will deliver the work according to the plan that they
have created themselves.
SCRUM (V)

You must know the Disciplined Agile Delivery of
Scott Ambler, in order to understand the value
of EPF process and libraries.
Key Issue

• Agile Modeling (AM) is a practice-based
methodology for effective modeling and
documentation of software-based systems.
• At a more detailed level AM is a collection
of values, principles, and practices for
modeling software that can be applied on
a software development project in an
effective and lightweight manner.
• AM was purposely architected to be a source
of strategies that can be tailored into other
base processes.
Agile Modelling (I)

• With an Agile Model Driven Development (AMDD)
approach you typically do just enough high-level
modeling at the beginning of a project to understand
the scope and potential architecture of the system.
• During construction iterations you do modeling as
part of your iteration planning activities and then
take a just-in-time (JIT) model storming approach
where you model for several minutes as a precursor
to several hours of coding.
• AMDD recommends that practitioners take a test-
driven approach to development although does not
insist on it
Agile Modelling (II)

Agile Modelling (III)
Source: Disciplined Agile Delivery

Agile Modelling (IV)
Source: Disciplined Agile Delivery and http://www.agilemodeling.com/

Agile Modelling Features
•Active stakeholder participation
•Architecture envisioning
•Document continuously
•Document late
•Executable specifications
•Iteration modeling
•Just barely good enough artifacts (sufficient artifacts)
•Look-ahead modeling
•Model storming
•Multiple models
•Prioritized requirements (work item list)
•Requirements envisioning
•Single source information
•Test-driven development (TDD)

Other agile methodologies
• Lean Development
• Kanban
• DSDM
• ASD
• Crystal

CMMI & Agile (I)
The CMMI model is not a set of dictated
practices. It is a model that is intended to be
used to “reason” about our processes to help
us ask the right questions leading to an
understanding of our weaknesses and areas
of needed improvement.

CMMI & Agile (II)
Source: Integrating CMMI and Agile Development

CMMI & Agile (III)

How CMMI and Agile Help Each Other (I)

How CMMI and Agile Help Each Other (II)

How CMMI and Agile Help Each Other (III)

The Agile Movement

Related slideshows

More Related Content

The Agile Movement