Youssef Chaker presented on agile development practices. He discussed failures of traditional waterfall projects like Ariane 5 and Therac-25 due to issues like inadequate testing. The presentation introduced the Agile Manifesto which values individuals, collaboration, working software, and responding to change over processes, tools, documentation, and plans. Scrum was explained as an agile framework using sprints, daily standups, and roles like Scrum Master and Product Owner. Best practices like test-driven development, pair programming, and continuous integration were also covered.

1. Be Agile, Be Happy
Youssef Chaker
NDU
May 21st 2010

2. Agenda
• Agenda
• My Background
• Things Gone Bad
• The Agile Manifesto
• Scrum
• Best Practices
• Questions
• Contact
• References

3. My Background
Born and raised in Lebanon
Bachelors of Science
Computer Engineering
THE University
May 2008
Thesis: Designing and Building an Energy
Responsible Data Center
Software Developer/Consultant
OpenSource Connections (OSC)
July 2008 - present

4. Things Gone Bad (1/3)
Ariane 5 Flight 501
Flight 501, which took place on June 4, 1996, was the first, and unsuccessful, test
flight of the European Ariane 5 expendable launch system. Due to an error in the
software design (inadequate protection from integer overflow),
the rocket veered off its flight path 37 seconds after launch and was destroyed by its
automated self-destruct system when high aerodynamic forces caused the core of the
vehicle to disintegrate. It is one of the most infamous computer bugs in history.
The breakup caused the loss of four Cluster mission spacecraft, resulting in a loss of
more than US$370 million

5. Things Gone Bad (2/3)
Therac-25
The Therac-25 was a radiation therapy machine produced by Atomic Energy of
Canada Limited (AECL) [...]. It was involved with at least six accidents between 1985
and 1987, in which patients were given massive overdoses of radiation, approximately
100 times the intended dose. Three of the six patients died as a direct consequence.
These accidents highlighted the dangers of software control of safety-critical systems,
and they have become a standard case study in health informatics and software
engineering.
[...]
A commission has concluded that the primary reason should be attributed to the bad
software design and development practices, and not explicitly to several coding errors
that were found. In particular, the software was designed so that it was relatively
impossible to test it in a clean automated way.

6. Things Gone Bad (3/3)
More online:
http://en.wikipedia.org/wiki/List_of_software_bugs

7. But weren’t these projects
following some sort of
development or management
process?

8. YES!

9. The
Waterfall
methodology

10. = DEVIL

11. = DEATH

12. = EPIC FAIL

13. WHY?

14. DOZENS of
requirements
documents at
THOUSANDS of
pages each

15. Turnaround
time no less
than 3 months

16. Change of mind
time?

17. GUESS?

18. 3 seconds!

19. Answer?

20. Better
Managers?

21. OK, Maybe not

22. Better Clients?

23. Definitely NOT!

24. Better Process

25. Now we’re
talking :)

26. Agile

27. Agile Manifesto

28. 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.

29. Thank You

30. Hunh... ?

31. wait... what?

32. manifesto who?

33. Lets take a
closer look

34. Working
software over
comprehensive
documentation

35. Responding
to change over
following a plan

36. HOW?

37. Scrum

39. iterative, incremental
framework for project
management and agile
software development.

41. 2 - 4 week
sprints

42. Some role
playing

43. “ScrumMaster”, who
maintains the processes
(typically in lieu of a project
manager)

44. “Product Owner”,
who represents the
stakeholders, represents
the business

45. “Team”, a cross-functional
group of about 7 people
who do the actual analysis,
design, implementation,
testing, etc.

46. A pig and a chicken are walking down a road.
The chicken looks at the pig and says,
“Hey, why don’t we open a restaurant?”
The pig looks back at the chicken and says,
“Good idea, what do you want to call it?”
The chicken thinks about it and says,
“Why don’t we call it ‘Ham and Eggs’?”
“I don’t think so,” says the pig, “I’d be
committed, but you’d only be involved.”

47. Scrum Planning Poker

48. Sprint Backlog

49. Sprint Burndown

50. Daily Standups

51. Short: less than
15 minutes

52. Answer 3 questions:
•What did I do yesterday?
•What am I doing today?
•Obstacles?

55. + more

56. Flexibility
(key)

57. OSC Specific
Implementations

58. OpenApproach to software development
Transition
Est Est
im
Ra atio im and
Pla
n nge n n Ra atio
s Pla nge n Document
s
test Adjust test
Iteration 0:
Backlog Iteration N
Goals
Iteration 1
Goals
integrat
Analysis,
integrat
Priorities,
de
3 weeks
de
Charter 3 weeks
co
co
Reassess
e
e
& Design
Risk
Ite Project
r o& e Ite
o& e
Lau ation em ectiv
D sp
r
Lau ation em ectiv
Retrospective
nc nc D sp
h tro h tro
Re Re
Setup CI
server, and Continuous Integration of source code and testing (CI server, unit testing, functional/browser testing)
test server
Constant C3: Constant Collaboration, Communication, and Customer involvement
(stand ups, burndowns, wiki, issue tracking)
Core Principles of the OpenApproach
• High customer visibility into project status • Strong interaction with customers • Best practices in development
• Full access to code repositories • Customers help set iteration goals • Automated testing
• Full access to issue tracking tools • Demo to customer & retrospective at the • Continuous code integration
• Full visibility into Scrum burndown charts end of each development iteration • Test driven development
• Customers participate in daily stand ups • Customers can adjust priority of features • Iterative deployments
• Risk factors managed with customer after each iteration • Refactoring
• Collaborative estimation process • Co-location when possible • Pair programming/training

60. Lightweight Documentation

61. emphasis ON
collaboration

62. Best Practices

63. Test Driven
Development
Behavior Driven
Development

64. Continuous
Integration

66. Pair
Programming

68. Source Control
SVN or Git

69. Git

70. I mean come on!
Have you
seen/used
GitHub.com?

71. The right tool for the job

72. Team Building

73. Hackathon

74. Rails Rumble

75. More example practices:
http://railsmaturitymodels.com/practices

76. Questions?
Comments?
Concerns?

77. Contact
www.o19s.com
www.youhhoo.com
ychaker@o19s.com
twitter.com/ychaker
linkedin.com/in/ychaker

78. References
• Fowler, Martin. The New Methodology: http://martinfowler.com/articles/newMethodology.html
• Wikipedia. Agile Software Development: http://en.wikipedia.org/wiki/
Agile_software_development
• Manifesto for Agile Software Development: http://agilemanifesto.org/
• Wikipedia. Scrum (development): http://en.wikipedia.org/wiki/Scrum_(development)
• Wikipedia. Ariane 5 Flight 501: http://en.wikipedia.org/wiki/Ariane_5_Flight_501
• Ariane 5 Failure, Full Report: http://sunnyday.mit.edu/accidents/Ariane5accidentreport.html
• Wikipedia. Tehrac-25: http://en.wikipedia.org/wiki/Therac-25
• Wikipedia. List of software bugs: http://en.wikipedia.org/wiki/List_of_software_bugs
• Rails Maturity Models: http://railsmaturitymodels.com/practices