Seminar Talk at UPT DEGI | Nov, 2015 about Agile Software Development (Scrum Framework)

1. Agile So)ware Development
(Scrum Framework)
by Eduardo Ribeiro
V 1.0

3. Again…
Noooo!
Same
jokes, ugly
draws and
slides!

4. Overview
• What is Agile?
• Agile Manifesto
• 12 Principles behind the Agile
Manifesto
• TradiQonal vs. Agile
• Agile Umbrella
• Why we use (or should use) it?
• What is Scrum?
– Incremental != IteraQve
– Scrum Principles and Values
– Scrum Team & Roles
– Scrum Ceremonies
– Scrum Framework
– Scrum ArQfacts
– User Stories Context
– INVEST Acronym
– Why we esQmate?
– Poker Planning
– DoD and DoR
– Visibility of Progress

5. What is Agile
“Agile is an “iteraQve” and “incremental”
so)ware development methodology were its
main focus is on client saQsfacQon through
conQnuous delivery.”

6. Agile Manifesto

7. 12 Principles behind the Agile
Manifesto
• Our highest priority is to sa#sfy the customer
through early and con#nuous delivery of valuable
so)ware.
• Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's compeQQve advantage.
• Deliver working so)ware frequently, from a couple
of weeks to a couple of months, with a preference
to the shorter #mescale.
• Business people and developers must work
together daily throughout the project.
• Build projects around mo#vated individuals. Give
them the environment and support they need, and
trust them to get the job done.
• The most efficient and effecQve method of
conveying informaQon to and within a development
team is face-to-face conversa#on.
• Working so:ware is the primary measure of
progress.
• Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
• ConQnuous a`enQon to technical excellence and
good design enhances agility.
• Simplicity the art of maximizing the amount of work
not done is essenQal.
• The best architectures, requirements, and designs
emerge from self-organizing teams.
• At regular intervals, the team reflects on how to
become more effec#ve, then tunes and adjusts its
behavior accordingly.

8. TradiQonal vs. Agile

9. Agile Umbrella
Crystal Clear
Feature Driven Development (FDD)
Dynamic System Development Method (DSDM)
Lean So:ware Development
Kanban
Scrum
Extreme Programming (XP)
Adap#ve So:ware Development (ASD)
Behavior Driven Development (BDD)

10. Why we use (or should use) it?
• Reduced risk
• Earlier ROI/ value
• Increased visibility of progress
• Increased predictability
• Increased producQvity
• Reduced waste
• More producQve & happy
teams

11. What is Scrum?

12. Incremental != IteraQve

13. PRINCIPLES AND VALUES
Scrum

14. Empirical Process Control
Transparency:
• Transparency allows all facets of any Scrum process to be observed by
anyone.
Inspec#on:
• Use of a common Scrum Board and other informaQon radiators.
Adapta#on:
• AdaptaQon happens as the Scrum Core Team and Stakeholders learn
through transparency and inspecQon and then adapt by making
improvements in the work they are doing.

15. Self-OrganizaQon

16. CollaboraQon

17. Value Base-PrioriQzaQon

18. Time-Boxing

19. IteraQve Development

20. Values
• Focus - Because we focus on only a few things at a Qme, we work well together and produce
excellent work. We deliver valuable items sooner.
• Courage - Because we work as a team, we feel supported and have more resources at our
disposal. This gives us the courage to undertake greater challenges.
• Openness - As we work together, we express how we're doing, what's in our way, and our
concerns so they can be addressed.
• Commitment - Because we have great control over our own desQny, we are more
commi`ed to success.
• Respect - As we work together, sharing successes and failures, we come to respect each other
and to help each other become worthy of respect.

21. TEAM & ROLES
Scrum

22. Scrum Team

23. Scrum Master

24. Product Owner

25. CEREMONIES
Scrum

26. Grooming the Product Backlog

27. Sprint Planning

28. Daily Stand Up

29. Sprint Review or Demo &
RetrospecQve

30. PROCESS
Scrum

31. Scrum Framework

32. ARTIFACTS
Scrum

33. User Stories Context
As a … (user of the system)
I want … (feature or problem to
be solved)
So that … (benefit of story being
completed)
The “so that” part is incredibly
valuable as it focuses people on
the real reason behind this story.

34. INVEST Acronym

35. Why we EsQmate?

36. Poker Planning

37. DOD AND DOR
Scrum

38. DefiniQon of Done aka DoD
• The team agrees on, and displays
prominently somewhere in the
team room, a list of criteria which
must be met before a product
increment "o)en a user story" is
considered "done".
• On a feature level, the acceptance
criteria should be agreed up front
BEFORE the User Story is
submi`ed to acceptance.

39. DefiniQon of Ready aka DoR
• By analogy with the "DefiniQon of
Done", the team makes explicit
and visible the criteria (generally
based on the INVEST matrix) that
a user story must meet prior to
being accepted into the upcoming
iteraQon.
• On a feature level, the acceptance
criteria should be agreed up front
BEFORE code is wri`en.

40. Visibility of Progress
• Team has a duty to radiate
informaQon outwards!
• It also helps reduce interrupQons!
– Scrum and Kanban Physical Boards
– Big visible charts (Ex: CFS’s, Burn
Down, Etc)
– On-line Tools (Ex: Rally Dev)
– Daily reporQng

41. Examples

42. Thank you! Any quesQon?