Seminar Talk at UPT DEGI | 5th of Dec 2016 about Agile Software Development (Framework, Systems and Evolution)

1. Agile So)ware Development
(Framework, Systems and Evolu<on)
by Eduardo Ribeiro
V 2.0

3. Yes, these are ugly slides!

4. Everything starts with an Idea

5. What is Agile
“Agile is an “itera<ve” and “incremental”
so)ware development methodology were its
main focus is on client sa<sfac<on through
con<nuous 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 compe<<ve 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 effec<ve method of
conveying informa<on 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.
• Con<nuous aZen<on to technical excellence and
good design enhances agility.
• Simplicity the art of maximizing the amount of work
not done is essen<al.
• 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. Tradi<onal 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 produc<vity
• Reduced waste
• More produc<ve & happy
teams

11. What is Scrum?

12. Incremental != Itera<ve

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 informa<on radiators.
Adapta#on:
• Adapta<on happens as the Scrum Core Team and Stakeholders learn
through transparency and inspec<on and then adapt by making
improvements in the work they are doing.

15. Self-Organiza<on

16. Collabora<on

17. Value Base-Priori<za<on

18. Time-Boxing

19. Itera<ve Development

20. Values
• Focus - Because we focus on only a few things at a <me, 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 des<ny, we are more
commiZed 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 &
Retrospec<ve

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 Es<mate?

36. Poker Planning

37. DOD AND DOR
Scrum

38. Defini<on 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
submiZed to acceptance.

39. Defini<on of Ready aka DoR
• By analogy with the "Defini<on 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
itera<on.
• On a feature level, the acceptance
criteria should be agreed up front
BEFORE code is wriZen.

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

41. Examples

42. Kanban

43. Why should we have a WIP?

44. Evolu<on - Scrumban

45. Thank you! Any ques<on?