3. About Agile
Agile is a Software Development Methodology
It means ‘ability to move quickly and easily’ and responding swiftly to change
It’s a time boxed, iterative approach
Develop and deliver software incrementally from the start of the project, instead of trying to
deliver it all at once near the end.
Page 3 12/15/2016
4. About Agile (Cont.)
Iterations are typically 1 to 4 weeks so that the development is aligned with the changing
business needs
It works by breaking projects down into little bits of user functionality called user stories,
prioritizing them, and then continuously delivering them in short two week cycles
called iterations.
Page 4 12/15/2016
8. Make a list
Sitting down with the customers
make a list of features they would like to see in their software.
We call these things user stories
and they become the To Do list for project.
Page 8 12/15/2016
10. Size things up
Size user stories using Agile estimation techniques
Coming up with a guess as to how long each user story will take.
Page 10 12/15/2016
11. Time Estimations
Don’t estimate things absolutely, as we are not
good at that.
Try to estimate things relatively as we are good at
that
Page 11 12/15/2016
12. Time Estimations (Cont.)
Relatively sizing means – don’t worry about exactly how big a story is.
Worry more how this story’s size compares to others.
Page 12 12/15/2016
13. Set some priorities
Like any other lists, there always seems to be more to do
than time allows.
Ask the customer to prioritize their list
Get the most important stuff done first, and save the
least important for last.
Page 13 12/15/2016
14. Start executing
Start delivering some value.
Start at the top. Work your way to the bottom.
Building, iterating, and getting feedback from your customer as you go.
Page 14 12/15/2016
15. Update the plan as you go
Then, as you and your customer starting delivering, one
of two things is going to happen. You'll discover:
You're going fast enough. All is good.
Or, You have too much to do and not enough time.
At this point you have two choices. You can either a) do less
and cut scope (recommended). Or you can b) push out the
date and ask for more money.
Page 15 12/15/2016
17. Continuous Activities
Analysis, design, coding, and testing are continuous
activities
You are never done analysis, design, coding and
testing on an Agile project.
So long as there are features to build, and the means
to deliver them, these activities continue for the
duration of the project.
Page 17 12/15/2016
18. Development is iterative
Iterative development means starting with something really simple, and adding to it
incrementally over time.
It means evolving the architecture, accepting that your requirements are going to
change, and continuously refining and tweaking your product as you go.
Page 18 12/15/2016
19. Planning is adaptive
When reality disagrees with their plans, Agilists find it easier to change their plans than
reality. It is called adaptive planning.
And while there are many ways to changes plans, the preferred way is to flex on scope.
Page 19 12/15/2016
20. Scope can vary
Agile deals with the age old problem of having too much to do and not enough time by
doing less.
By fixing time, budget, and quality, and being flexing around scope, Agile team's
maintain the integrity of their plans, work within their means, and avoid the burn out,
drama, and dysfunction traditionally associated with our industry.
Page 20 12/15/2016
21. Requirements can change
Traditionally change has been avoided on software projects because of it's high
perceived cost late in the game. Agile challenges this notion and believes the cost of
change can be relatively flat.
Through a combination of modern software engineering practices, and open and honest
planning, Agilists accept and embrace change even late in delivery process.
Page 21 12/15/2016
22. Measure of success
Working software is the primary measure of success
In Agile productivity is measured in rate at which teams can turn their client’s wishes into
working software.
Project plans, test plans, and analysis artifacts are all well and good but Agilists
understand they in themselves are of no value to the end customer.
Page 22 12/15/2016
23. Agile Manifesto
The Agile Manifesto, also called the Manifesto for Agile Software Development
It is a formal announcement of four key values and 12 principles to guide
an iterative and people-centric approach to software development.
Page 23 12/15/2016
24. Agile Core Values
The agile software development emphasizes on four core values.
1) Individual and team interactions over processes and tools
2) Working software over comprehensive documentation
3) Customer collaboration over contract negotiation
4) Responding to change over following a plan
Page 24 12/15/2016
25. Twelve Principles
1. Customer satisfaction through early and continuous software delivery – Customers are
happier when they receive working software at regular intervals, rather than waiting
extended periods of time between releases.
2. Accommodate changing requirements throughout the development process – The
ability to avoid delays when a requirement or feature request changes.
3. Frequent delivery of working software – Scrum accommodates this principle since the
team operates in software sprints or iterations that ensure regular delivery of working
software.
Page 25 12/15/2016
26. Twelve Principles (Cont.)
4. Collaboration between the business stakeholders and developers throughout the
project – Better decisions are made when the business and technical team are aligned.
5. Support, trust, and motivate the people involved – Motivated teams are more likely to
deliver their best work than unhappy teams.
6. Enable face-to-face interactions – Communication is more successful when development
teams are co-located.
Page 26 12/15/2016
27. Twelve Principles (Cont.)
7. Working software is the primary measure of progress – Delivering functional software to
the customer is the ultimate factor that measures progress.
8. Agile processes to support a consistent development pace – Teams establish a
repeatable and maintainable speed at which they can deliver working software, and they
repeat it with each release.
9. Attention to technical detail and design enhances agility – The right skills and good
design ensures the team can maintain the pace, constantly improve the product, and
sustain change.
10. Simplicity – Develop just enough to get the job done for right now.
Page 27 12/15/2016
28. Twelve Principles (Cont.)
11. Self-organizing teams encourage great architectures, requirements, and designs – Skilled
and motivated team members who have decision-making power, take ownership,
communicate regularly with other team members, and share ideas that deliver quality
products.
12. Regular reflections on how to become more effective – Self-improvement, process
improvement, advancing skills, and techniques help team members work more
efficiently.
Page 28 12/15/2016
30. Fundamental Assumptions
Traditional: Systems are fully specifiable, predictable, and can be built through thorough
and extensive planning.
Agile: High-quality, adaptive software can be developed by small teams using the
principles of continuous design improvement and testing based on rapid feedback and
change.
Control
Traditional: Process-centric
Agile: People-centric
Management Style
Traditional: Command-and-control
Agile: Leadership-and-collaboration
Role Assignment
Traditional: Individual—favors specialization
Agile: Self-organizing teams—encourages role interchangeability
Agile vs. Waterfall
Page 30 12/15/2016
31. Agile vs. Waterfall (Cont.)
Communication
Traditional: Formal
Agile: Informal
Customer’s Role
Traditional: Important
Agile: Critical
Project Cycle
Traditional: Guided by tasks or activities
Agile: Guided by product features
Development Model
Traditional: Life cycle model (Waterfall, Spiral, or some variation)
Agile: The evolutionary-delivery model
Technology
Traditional: No restriction
Agile: Favors object-oriented technology
Page 31 12/15/2016
