The document discusses the differences between Agile and Waterfall methodologies in software development, emphasizing the Agile Manifesto's principles that prioritize individuals and interactions, working software, customer collaboration, and responsiveness to change. It outlines how Agile methods, such as Scrum, advocate for iterative development, continuous integration, and incorporating testing throughout the process. Additionally, the document critiques certain limitations of Agile methods, highlighting the potential neglect of comprehensive planning and architectural considerations.

1. Ivano Malavolta
Agile development
VRIJE
UNIVERSITEIT
AMSTERDAM

2. Waterfall vs agile: poor visibility

3. Waterfall vs agile: poor quality

4. Waterfall vs agile: too risky

5. Waterfall vs agile: can’t handle
change

6. The agile approach

7. Risks and features
http://www.testingthefuture.net/wp-
content/uploads/2011/12/waterfall_versus_agile_development.png

8. 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.
http://www.agilemanifesto.org

9. How does it work in practice?
You make a list You start executing
You estimate You update the plan
“@run-time”
You set priorities

10. Agile iterations

11. Technical tools: unit tests
Snippet of test code for exercising some functionality of the
product à codified requirements
We will have a dedicated course on testing

12. Technical tools: test-driven
development
Write tests first
Refactoring is less risky now

13. Technical tools: continuous
integration
Merging all the developers’ working copies many times a day
à it allows to make sure that all the code integrates, all the
unit tests pass, and a warning if anything goes wrong
image from http://newmedialabs.com/

14. An implementation: SCRUM
AAA

15. An implementation: SCRUM
http://www.flickr.com/photos/magia3e/6233729753/

16. An implementation: SCRUM
Burndown chart = how much work is left
Scope changes
• The engineering team
missed features in the UI
mockups when we
created the release
backlog
• Integrations into other
AdWords features were
overlooked
• The rate of change in
AdWords APIs is very
high.

17. Critical evaluation of the agile
method
+ Acceptance of change à less risky
+ Frequent and short iterations
+ Emphasis on working code
+ Associating a test with every piece of functionality
+ tests are a key resource within the project
+ Continuous integration (and delivery)
+ Planned
– Tests as a replacement for specifications
– Feature-based development & ignorance of
dependencies
– No quality plan
– Dismissal of a priori architecture work
– actually, dismissal of everything which is non-shippable

18. References

19. Suggested readings
1. Striebeck, M., "Ssh! We are adding a process... [agile practices],"
Agile Conference, 2006 , vol., no., pp.9 pp.,193, 23-28 July 2006
2. Nicolò Paternoster, Carmine Giardino, Michael Unterkalmsteiner,
Tony Gorschek, Pekka Abrahamsson, Software development in
startup companies: A systematic mapping study, Information and
Software Technology, Volume 56, Issue 10, October 2014, Pages
1200-1218, ISSN 0950-5849
3. Alfonso Fuggetta and Elisabetta Di Nitto. 2014. Software process. In
Proceedings of the on Future of Software Engineering (FOSE 2014).
ACM, New York, NY, USA, 1-12.

20. Contact
Ivano Malavolta |
Assistant professor
Vrije Universiteit Amsterdam
iivanoo
i.malavolta@vu.nl
www.ivanomalavolta.com