Family of methodologies that advocate “lightweight” and “human” software development processes

1. What is Agile?
Introduction to Agile Software Development

2. How Projects Really Work

3. How the customer explained it

4. How the project leader understood it

5. How the analyst designed it

6. How the programmer wrote it

7. How the business consultant described it

8. How the project was documented

9. How much the project cost

10. What the customer really needed

11. Agenda
What is Agile?
Agile Manifesto
Benefits
Values
Selected Practices
Agile at Orange & Bronze

12. What is Agile?
Family of methodologies that
advocate “lightweight” and
“human” software development
processes
Extreme Programming (XP),
Scrum, Kanban, Lean, Crystal,
Agile Unified Process...
Coined in 2001 by the creators
of similar methodologies
reacting to “heavyweight”
methodologies
“heavyweight”: too much work

13. What is Agile?
Emphasis on...
Customer satisfaction
Job satisfaction
Remove things that do not contribute to above
Culture
Values and attitude of people involved are just as
important as processes

14. The Agile Manifesto
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.

15. Benefits
Studies show...
Improved customer satisfaction
Higher quality
Better predictability
Improved employee retention
Higher job satisfaction
Mainstream acceptance
Your clients are probably adopting agile

16. Values
Communication
Simplicity
Feedback
Courage
Respect

17. Communication
Goal is shared view
Documentation should have a purpose
Face-to-face is preferred
Common work area
Cubicles discouraged

18. Simplicity
YAGNI – You Ain't Gonna Need It
Don't overcomplicate with what might be needed in the
future. Things may will change.
Use simplest possible solution
Design, code, documentation, tools, etc
Improves communication

19. Feedback
From System
Automated tests and continuous integration
From Customer
Acceptance tests and frequent interactions
From Team
Team communicates estimates and issues with
customer and among themselves
Feedback becomes input to project leading to
continuous improvement

20. Courage
Find and discuss problems early
Especially with client
Say when you need help
Change and experiment to continuously improve
New requirements
Refactoring
New processes and practices
New technologies and tools

21. Respect
Don't commit broken code
Keep automated tests running
Don't delay the work of others
Maintain quality and communication
Keep teammates motivated

22. Selected Practices
To be discussed: Others:
Whole Team Continuous Integration
Customer/Developer Stand-Up Meetings
Roles Self-Managed Teams
Short Iterations Pair Programming
Test-Driven Refactoring
Development
User Stories
Planning
Planning Boards
Tracking
Burn-Down Charts
Sustainable Pace
Retrospectives
Collective Code

23. Whole Team
Everyone involved should feel part of one team,
including customer
Often requires educating customer
Everyone should be easily accessible for questions
and other impromptu communication
Common work area where possible, frequent
meetings where not
Shared access to resources
Common repository, issue tracker, etc
Focus
People ideally should have only one project at a time

24. Customer/Developer Roles
Customer
Developer Developer
Customer

25. Short Iterations
What's the problem with
“Waterfall”?
Mistakes are hard to
find in early stages
Difficult to validate
Change becomes more
expensive in later
stages

26. Short Iterations
Reality...
Customers don't know
what they want until
they see it
Developers don't know
how hard a problem is
until they start
Business needs change

27. Short Iterations
Evolutionary approach
Each iteration is complete development cycle
Analysis, Design, Implementation, Testing, and
sometimes incremental Deployment
Output is working, usable software!
Demo session held with customer at end of iteration
gain feedback
adjust plans for succeeding iterations
1 – 3 weeks

28. Test-Driven Development
Tests are central to development process
Types
Unit Tests: method and class level
Integration Tests: between classes, components and
other systems
Acceptance Tests: customer requirements defined as
tests
Tests are automated where possible
Unit, Integration – always

29. Test-Driven Development
Tests are unambiguous requirements specifications
Avoid misunderstandings by defining requirements as
acceptance tests!
Unit tests cut the time spent finding bugs
Fixing a bug is usually easy, finding it is a nightmare!
Unit tests shape design
Components are decoupled, interfaces well-thought
Tests are written before and during implementation

30. Planning
1. Customers define and prioritize requirements
Often as “user stories” - lightweight use cases
2. Dev team collectively estimates cost of each
requirement
Assign “points” to each
3. Customers review requirements against cost and
may re-prioritize
4. Dev team distributes requirements across iterations,
according to estimated team “velocity”
Higher priority requirements go to earlier iterations

31. Tracking
Dev team tracks progress each day, usually via
“burn down chart”

32. Tracking
If dev team sees that iteration schedule will not be
met, they inform customer immediately
Too much work – inform customer which requirements
will not be delivered at iteration ind
Too little work – request more work from customer or
pull from “backlog”
Iteration end date does not move. Only workload
changes.

33. Sustainable Pace
Studies show that productivity drops when
developers work long hours for extended periods
Overtime should be controlled and avoided where
possible
Communication and courage with customer is
important
Track velocity and inform customer early if expected
schedules will not be met
Use experience as input for future schedules, ask
customer to review and re-prioritize requirements

34. Agile at Orange & Bronze
Been doing Agile since its foundation in 2005
Before it became mainstream
We've tried different methodologies and practices
XP, Scrum, Kanban
Not all practices work in all conditions
The first to offer training in Agile methodologies and
practices
Scrum, TDD, Agile Business Analysis, Agile QA, etc
Trainers are seasoned practictioners

35. Open Workspaces

36. Planning Board

37. Online Charts

38. Domain Design

39. Agile Training (internal)

40. For our Agile and Java training courses, go to:
http://orangeandbronze.com/course-offerings