1. Software Development Landscape
From the well-known Standish CHAOS Report 1994
Software projects fail:
Cancelled - 31%;
Late or lacking of features – 53%
Industry has only delivered on-time and on-budget 16% of the time!
3 top reasons for failure
Lack of user (sponsor) involvement
No executive management support
Unclear, incomplete, & changing requirements
Typical software project experiences a % change in requirements
45% of features defined in early specs are never used

2. Bridge to Success
The Standish Group concluded that keys to success are:
Shorter time frames
Delivery of software components early and often
Iterative process
“Growing" software vs. "developing" software
Engage the user earlier
Clear statement and set of objectives for components
Keep it simple! - Complexity = confusion and cost

3. Values of Agile Development
individuals and interactions
over
processes and tools
working software
comprehensive documentation
customer collaboration
contract negotiation
responding to change
following a plan
While there is value in the items on the right,
we value the items on the left more.

4. Scrum Process Key Practices Self-directed; self-organizing teams
what did you do yesterday?
what will you do today?
what got in your way?
Key Practices
Self-directed; self-organizing teams
15 minute daily stand up meeting with 3 special questions
30-calendar day iterations
Each iteration begins with adaptive planning
Stakeholder demo at end of each iteration
Team measures progress daily
Each iteration delivers tested, fully-functional software
Never more than 30-days from potential production release

5. Benefits and Challenges of Scrum
Increased productivity through teamwork and focus
Increased satisfaction through transparency and involvement
Increased ROI through early delivery of high value functionality
High quality throughout the development cycle using Test-First
High energy, exciting process
People know the importance of their work
Opportunity to improve every 30 days
Challenges
Leading the change
Good news, you know where you are. Bad news, you know where you are…
Identifies all areas of improvement for engineering practices
Change in culture
Hard work
Estimatiin

6. De-Cubiclization 2004

7. Origins of Agile

8. Extreme Programming Values: Practices: Communication Simplicity
Feedback
Courage
Respect
Practices:
Pair Programming
Planning Game
Iteration Planning
Test Driven Development
Whole Team
Continuous Integration
Coding Standards
Collective Code Ownership
Simple Design
Refactoring
On-site Customer
Open Workspace
Acceptance Tests (Customer Tests)

9. Common Practices Short iterations (1 week to 1 month)
Continuous communication & integration
Designs driven by testability
User Stories
Don’t over-design (YAGNI), refactoring when needed
“Travel Light”

10. Short Iterations Usually 1 week (eg, XP or Evo) to 1 month (eg, Scrum)
During an iteration, requirements are usually fixed
This enables developers to have stability while the business gets the ability to respond to change
The highest priority things are always worked on first
This means that at any point in time, you’re delivering the maximum possible business value
By extension, this also means that you avoid things that don’t have the highest business value
Estimating things much beyond a week is “iffy”

11. Continuous Communication & Integration
Follows the general “Principle of Least Surprise”
Teams are “self organizing”
Have the responsibility and ability to identify and remove roadblocks
Autonomous – sets its own policies and procedures within the context of the larger organization’s
Everyone on the team knows what everyone else is doing
Use “Big Visible Charts”

12. User Stories
Similar to “use cases” and “functional requirements documents”, but not… :-)
The basic idea is to quickly (a sentence – a paragraph) give description of what’s needed
The point is to encourage collaboration over contracts while still providing the written record of what is needed
Describe external behaviors of the system understood by the custmer

13. Test Driven Development
Write tests as early as possible
QA helps define/ensure functionality features
Use a tool to track the tests
PHPUnit, Selenium
Continuous Integration Environment
Automate integration testing
Cruise Control
Testing done all the time
No big “OMG, we have to test this thing now”

14. Sample Timeline Four week cycle
Lots of discussion before project is “approved” and started by dev team
Week one is overlap with previous cycle
Working out estimates, assignments, design
Week two-three heavy dev work
Week four – dry runs to launch, testing

15. What Are The 3 Questions?
1. What have you completed (relative to the Backlog) since the last Scrum meeting?
2. What got in your way of completing this work?
3. What will you do between now and the next Scrum meeting?

16. At the End of a Sprint? Status meeting with all stakeholders.
Increments are delivered.
Surprises are reported.
ANYTHING can be changed, work can be added, eliminated, re-prioritized.
New estimates and team assignments are made for the next Sprint.
The project can be cancelled.
“Experience from earlier increments allows better estimates and planning as project progresses.It's always easier to estimate shorter development periods”

17. Planning Iteration Collect all user stories
Pick one feel its easy and give it worth 1
Select all stories with same worth level 1
Select stories with twice work of worth 1 mark as worth 2
Repeat that to get stories with worth 4
Select stories with worth between 2 and 4 and mark it as worth 3
Create a card for each stories with its worth

18. Planning Iteration Count total stories point
Estimate one story with worth 1 (e.g. 5 man/days)
Total estimation for release = total point * (worth1 estimation)
Example total estimation = (17 point) * 5 = 85 man/days
If we have 2 developers then its should completed in 43 man/days

19. Planning Release Capacity Planning
Sprint (Iteration) = 2 weeks = 10 days
Sorties shouldn’t exceed our capacity
Capacity = 10 days / (estimation for worth 1 story=5) * number of developer (2) = 4 story point for one sprint
Customer should prioritize stories
Customer should select stories with total point no more than 4 points
E.g. story one & two = 3 points
After sprint completed in two weeks, developer still need 0.5 point to complete
Then team velocity is = 2.5 points per sprint instead of 4 points

20. Planning Release Now we have estimation for all release
17 (total points)/ 2.5 (velocity)= 7 sprints to complete all stories
Each sprint is 2 weeks
Then we have 2 * 7 = 14 week to complete release
If 14 weeks are not suitable (exceed deadline) then we have to tuning scope

21. Tuning Scope
If deadline will complete 12.5 story points and there is 4.5 story point out from this release
We have three approaches
Increase number of developer to meet deadline
Take out some stories from this release
Break down some stories worth by splitting card one for release 1, and one for next release