This document provides an overview of agile methodology and several agile frameworks. It begins with a brief history of the traditional waterfall model and its limitations. It then introduces the agile manifesto and some core agile principles. Several agile frameworks are described at a high level, including scrum, kanban, extreme programming, and others. Key practices of scrum and extreme programming like iterations, user stories, stand-up meetings, and test-driven development are defined. The document aims to give the reader a broad understanding of agile concepts and some of the most commonly used agile frameworks and practices.

1. Overview of
Agile Methodology
By
Komal Khetlani

2. Software development processes
A [really] short history of

3. traditional approach
to software development
REQUIREMENTS
DESIGN
DEVELOPMENT
TESTING
MAINTENANCE
Waterfall Development is
another name for the more
Waterfall Development

4. Waterfall Development (contd..)
You complete one phase (e.g. design) before moving
on to the next phase (e.g. development)
You rarely aim to re-visit a ‘phase’ once it’s
completed. That means, you better get whatever
you’re doing right the first time!

5. This approach is highly risky, often more costly and
generally less efficient than Agileapproaches
REQUIREMENTS
DESIGN
DEVELOPMENT
TESTING
MAINTENANCE
Takes too long
Changes
Skipped
You don’t realize any value until
the end of the project
You leave the testing until the end
You don’t seek approval from the
stakeholders until late in the day
But…

6. AGILEIterative
AdaptableRapid
Cooperative
Quality-driven
Not a process, it's a philosophy or set of values

7. Individuals and interactions over
processes and tools
Working software over comprehensive
documentation
Customer collaboration over
contract negotiation
Responding to change over
following a plan
Agile Manifesto

8. Agile Umbrella
Agile
Crystal
XPScrum
DSDM
FDD
Kanban RUP
RUP (120+)
XP (13)
Scrum (9)
Kanban (3)
Do Whatever!! (0)
More Prescriptive
More Adaptive
and few more…
* Check wikipedia for list of all Agile methods
RUP has over 30 roles, over 20
activities, and over 70 artifacts
more rules to follow
fewer rules to follow

9. Agile Methodologies
• eXtreme Programming (XP)
• Scrum
• Crystal family of methodologies
• Feature-Driven Development (FDD)
• Adaptive Software Development (ASD)
• Dynamic System Development Model (DSDM)
• Agile Unified Process (AUP)

10. ScrumA light-weight agile process tool
Split your organization
into small, cross-functional, self-
organizing teams.
Split your work into a list of small, concrete deliverables.
Sort the list by priority and estimate the relative effort of each
item.
Scrum Team
Scrum Master
Product/ Project
Owner

11. Split time into short fixed-length iterations/ sprints (usually 2 – 4
weeks), with potentially shippable code demonstrated after each
iteration.
Scrum (contd..)
January May
Optimize the release plan and update priorities in
collaboration with the customer, based on insights gained by
inspecting the release after each iteration.
Optimize the process by having a retrospective after each
iteration.

12. Scrum vs. Waterfall
REQUIREMENTS
DESIGN
DEVELOPMENT
TESTING
MAINTENANCE

13. Iterative Scrum

14. Things we do in Scrum
The project/ product is described as a list of features: the backlog.
The features are described in terms of user stories.
The scrum team estimates the work associated with each story.
Features in the backlog are ranked in order of importance.
Result: a ranked and weighted list of product features, a
roadmap.
Daily scrum meeting to discuss What did you do y’day? What
will you do today? Any obstacles?
Scrum terminologies

15. Scrum Artifacts
Iteration/ Sprint 1 Iteration/ Sprint 2
Sample Userstory
Efforts
10hrsEfforts: 2hrs IA, 6hrs Development, 2hrs Testing
The total effort each iteration can
accommodate leads to number
of user story per iteration
One release may contains number of iterations
Release

16. Scrum planning example
Iteration cycle of 3 weeks
Working hours per day is 8 120hrs
Total hours of work iteration can
accommodate
8hrs x 5days x 3weeks =
Product backlog of 20 stories
Each story effort is 10 hrs
Iteration backlog or number of stories per iteration
12 user story

17. Scrum in a nutshell
So instead of a large group spending a long time building a
big thing, we have a small team spending a short time
building a small thing.
But integrating regularly to see the whole.

18. KANBANJust-in-time (JIT)
Visualize the
Work
Measure & Manage Flow
Signboard
Limit Work-In-Progress
Visual Card

19. KanbanLean approach to agile development
Similar to Scrum in the sense that you focus on features as
opposed to groups of features – however Lean takes this
one step further again.
You select, plan, develop, test and deploy one
feature (in its simplest form) before you select, plan,
develop, test and deploy the next feature.
Aim is to eliminate ‘waste’ wherever possible…

20. Kanban (contd…)
Visualize the workflow
Limit WIP (work in progress)
Split the work into pieces, write each
item on a card and put on the wall
Use named columns to illustrate where
each item is in the workflow
Assign explicit limits to how many items may be in progress at each stage
Measure the lead time (average time to complete one item,
sometimes called “cycle time”)
Optimize the process to make lead time as small and predictable as possible

21. Kanban Board Illustration - I

22. Kanban Board Illustration - II

23. Extreme Programming
• Most prominent Agile Software development
method
• Prescribes a set of daily stakeholder practices
• “Extreme” levels of practicing leads to more
responsive software.
• Changes are more realistic, natural,
inescapable.

24. eXtreme
Programming

25. The XP Guru: Kent Beck
• eXtreme Programming
– The most prominent agile development
methodology

27. The 12 Key Practices
• The Planning Game
• Small Releases
• Metaphor
• Simple Design
• Test-Driven Development
• Refactoring
• Pair Programming
• Collective Ownership
• Continuous Integration
• 40-Hour Workweek
• On-site Customer
• Coding Standards

28. 1. Metaphor
• Guide all development and conversations with a
simple shared story of how the whole system
works
– Gives the team a whole picture of describing the
system, where new parts fit, etc.
• Words used to identify technical entities should be
chosen from the metaphor
• The default metaphor is the business domain, and
it’s usually just fine

29. How It Works for Me?
• Metaphors are good idea
• People should know the business needs and how
their work fits in the project

30. 2. Release Planning
• Requirements via User Stories
– Short cards with natural language description of
what a customer wants
– Prioritized by customer
• Resource and risk estimated by developers
– Via “The Planning Game”
• Play the Planning Game after each increment

31. User Stories

32. How It Works for Me?
• Requirements specification (SRS) is better than
user stories
– Written documentation works well for large
projects
• I prefer prototyping the user interface as source
of documentation
• Sometimes its is hard to estimate the required
resources
• Small releases have less risk

33. 3. Testing
• Test-Driven Development (TDD)
– Write tests before code
– Tests are automated
– Often use xUnit framework
– Must run at 100% before proceeding
• Acceptance Tests
– Written with the customer
– Acts as “contract”
– Measure of progress

34. Test-Driven Development
• Developers write unit tests before coding
• Motivates coding
– Improves design
– Provides regression tests
– Provides specification by example
public void TestMultiplication() {
Dollar five = Money.dollar(5);
AssertEqual(new Dollar(10), five.times(2));
AssertEqual(new Dollar(15), five.times(3));
}

35. How It Works for Me?
• TDD is good for most projects, not for all
– The real world is different: you always need the
functionality "for tomorrow"!
• I use unit testing for complex logic only
– Testing simple logic is overhead

36. 4. Pair Programming
• Two software engineers work on one task at
one computer
– The driver has control of the keyboard and mouse
and creates the implementation
– The navigator watches the driver’s implementation
• Identifies defects and participates in on-demand
brainstorming
– The roles of driver and observer are periodically
rotated

37. Pair Programming
• Pairs produce higher quality code
• Pairs complete their tasks faster
• Pairs enjoy their work more
• Pairs feel more confident in their work

38. How It Works for Me?
• Pair programming is great for complex and critical
logic
– When developers need good concentration
– Where quality is really important
– Especially during design
– Reduces time wasting
• Trivial tasks can be done alone
• Peer reviews instead pair programming is often
alternative

39. 5. Refactoring
• Improve the design of existing code without
changing its functionality
– Relies on unit testing to ensure the code is not
broken
• Bad smells in code:
– Long method / class
– Duplicate code
– Methods does several different things (bad
cohesion)
– Too much dependencies (bad coupling)
– Complex / unreadable code

40. How It Works for Me?
• Delivering working software faster is important!
– You can write the code to run somehow
• With simple design
• With less effort
– Later you can refactor the code if necessary
• Refactoring is not a reason to intentionally write
bad code!
– Good coding style is always important!

41. 6. Simple Design
• No Big Design Up Front (BDUF)
– Reduces the overhead
– Ship working functionality faster and get feedback
early
• “Do The Simplest Thing That Could Possibly
Work”
– Later use refactoring to change it
• Not too much formal documentation

42. How It Works for Me?
• Simple design does not mean "no design"
–It is about establishing priorities
–It's a set of tradeoffs you make
–If something is important for this release
and for the whole system, it should be
designed well
–Don't lose time to design something you
will not use soon!

43. 7. Collective Code Ownership
• Code to belongs to the project, not to an
individual engineer!
• Any engineer can modify any code
• Better quality of the code
• Engineers are not required to work around
deficiencies in code they do not own
– Faster progress
– No need to wait for someone else to fix
something

44. Collective Code Ownership?

45. How It Works for Me?
• Collective code ownership is absolutely
indispensable
– You need to fight the people who don't agree with
this!
– Fire people writing unreadable and unmaintainable
code
– Don't allow somebody to own some module and be
irreplaceable

46. 8. Continuous Integration
• Pair writes up unit test cases and code for a task
(part of a user story)
• Pair unit tests code to 100%
• Pair integrates
• Pair runs ALL unit test cases to 100%
• Pair moves on to next task with clean slate and
clear mind
• Should happen once or twice a day

47. How It Works for Me?
• Integrating often is really valuable
– Sometimes you cannot finish a task for one day and
integrate it
– For small projects with small teams integration is
not an issue
– For large and complex projects it's crucial
• Think of automated build environment

48. 9. On-Site Customer
• Customer available on site
– Clarify user stories
– Make critical business decisions
• Developers don’t make assumptions
• Developers don’t have to wait for decisions
• Face to face communication minimizes the
chances of misunderstanding

49. How It Works for Me?
• On-site customer actually does not work!
– Customers are busy
• Meetings every day is working better
– Customers are not competent!
• Customers always say "Yes, this is what I want"
and later say the opposite
• You need to think instead of them
• Use prototyping

50. 10. Small Releases
• Timeboxed
• As small as possible, but still delivering
business value
– No releases to ‘implement the database’
• Get customer feedback early and often
• Do the planning game after each iteration
– Do they want something different?
– Have their priorities changed?

51. How It Works for Me?
• Small releases are really valuable
– Manage the risk of delivering something wrong
– Helps the customer to define better requirements
• Release every few weeks
• Large projects are not so flexible
– Try to release something, even you know that it will
be changed

52. 11. Forty-Hour Work Week
• Kent Beck says, “ . . . fresh and eager every
morning, and tired and satisfied every night”
• Burning the midnight oil kills performance
• Tired developers make more mistakes
– Slows you down more in the long run
• If you mess with people’s personal lives (by taking
it over), in the long run the project will pay the
consequences

53. How It Works for Me?
• 40 hours a week or 40 hours without a sleep?
– Come back to the real world!
– Overtime is not recommendable but often can not
be avoided
• Better planning can help
• Highly skilled senior engineers always suffer of
overtime and high pressure
– That's how the business works!

54. 12. Coding Standards
• Use coding conventions
– Rules for naming, formatting, etc.
– Write readable and maintainable code
• Method commenting
– Self-documenting code
– Don't comment bad code, rewrite it!
• Refactor to improve the design
• Use code audit tools (FxCop, CheckStyle, TFS)

55. How It Works for Me?
• Coding standards are important
– Enforce good practices to whole the team – tools,
code reviews, etc.
• Standards should be simple
– Complex standards are not followed
– Standards should be more strict for larger teams
– Developers don't like utter rules like "comment any
class member"

56. The 13th Practice?
The Stand Up Meeting
• Start the day with 15-minute meeting
– Everyone stands up (so the meeting stays short) in
circle
– Going around the room everyone says specifically:
• What they did the day before
• What they plan to do today
• Any obstacles they are experiencing
– Can be the way pairs are formed

57. People Communicate Most Effectively Face-to-
Face
Richness of the communication channel
Communicationeffectiveness
2 people at
whiteboard
2 people
on phone
2 people
on email
Videotape
Paper

58. How XP Solve Some SE Problems
Problem Solution
Slipped schedule Short development cycles
Cancelled project Intensive customer presence
Cost of changes
Extensive, ongoing testing,
system always running
Defect rates Unit tests, customer tests
Misunderstand the
business
Customer part of the team
Business changes Changes are welcome
Staff turnover Intensive teamwork

59. So What does XP Apply to?
• Domains with changing requirements
• High-risk projects (including those with high
schedule risk)
• Small project team: 2 – 12 programmers
– Cannot be used with a large team
• Extended development team
– Developers, managers and customer
– Co-located
• Automated testability

60. Agile Unified Process
• AUP is a simplified version of RUP
Phases of AUP
 Inception
 Elaboration
 Construction
 Transition

61. Disciplines of AUP
 Model
 Implementation
 Test
 Deployment
 Configuration Management
 Project Management
 Environment

62. Resources
• Agile 101
http://agile101.net/2009/09/08/the-difference-between-waterfall-iterative-
waterfall-scrum-and-lean-in-pictures/
• Kanban and Scrum - making the most of both
http://www.infoq.com/minibooks/kanban-scrum-minibook
• Kanban kick-start example
http://www.limitedwipsociety.org/tag/kanban-board/

63. Thank You