Agile session presented at the Universidade Portucalense to Bsc Students. This session was followed by a happy lego based simulation!

1. Agile Software
Development
1

2. Who I am…
2
Rui Barreira
Senior Delivery Manager/Agile Coach
@ VORTAL
Agile Enthusiast since 2008
Experienced Software Architect and
Product Manager
pt.linkedin.com/in/ruimbarreira/
rui.barreira@vortal.biz

3. What is NOT!
3

4. 4
Agile is NOT! – Reduced Team Capacity

5. 5
Agile is NOT! – One Big Story

6. 6
Agile is NOT! – No Process

7. 7
Agile is NOT!
“letting the programming team do whatever they need to with
no project management, and no architecture, allowing a
solution to emerge, the programmers will do all the testing
necessary with Unit Tests…”

8. Business Value
8

9. 9
What is Business Value?
• Value: is any desirable result for a stakeholder in a context;
• Stakeholder: are groups or individuals with a relationship to the
change or the solution;
• Needs: are problems, opportunities or constraints with potential of
value to a stakeholder;
• Changes: are any controlled transformations of an organization;
• Solutions: are specific ways to satisfy needs in a context;
• Contexts: are the part of the environment that encompasses a
change;

10. 10
What is Business Value?
“Price is what you pay, Value is What you get!”
Warren Buffet

11. 11
Types of Business Value?

12. 12
Delivering Business Value is difficult!
• Of the work executed: “Many (possibly most) organisations lose
as much as 45% of their total revenues due to costs associated
with low quality”
• On Failing: Some 75 percent of most large-scale J2EE projects
fail by missing both time and budget projections …”
• On Value: “64% of features actually delivered are either rarely
or never used”

13. 13
How to create Business Value!
WATERFALL (Royce)
Requirements, design
implementation,
verification &
maintenance
SPIRAL MODEL
(Barry Boehm)
V-MODEL (Anon)
Iterative
Aligns testing to
Waterfall development
AGILE e.g. XP
(Kent Beck)
RUP (Rational)
RAD
(James Martin)
Incremental, user
driven, low process
Object oriented,
iterative, time-boxed,
user driven
Prototyping, iterative,
time-boxed, user driven
1960 1970 1980 85 91
98 99
Waterfall V-Model
Spiral Model
RAD
RUP

14. Agile Philosophy
14

15. 15
The Philosophy
Agile methods are considered
Lightweight
People-based rather than Plan-based
Several agile methods
No single agile method
XP most popular
No single definition
Agile Manifesto closest to a definition
Set of principles
Developed by Agile Alliance

16. 16
The Agile Manifesto
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

17. 17
The Agile Manifesto
Individuals and interactions over processes and tools
Working software over comprehensive documentation
That is, while there is value in the items on
the right, we value the items on the left more.
Customer collaboration over contract negotiation
Responding to change over following a plan

18. 18
The 12 principles of Agile

19. 19
On Image Agile

20. Agile Methodologies
20

21. 21
All of them are Agile
Agile methods:
Scrum
Extreme Programming
Adaptive Software Development (ASD)
Dynamic System Development Method (DSDM)
Lean IT
…
Agile Alliance (www.agilealliance.org)
A non-profit organization promotes agile development

22. 22
Lets Talk About SCRUM

23. 23
Sequencing vs Overlapping
Requirements Design Code Test

24. 24
Scrum in 100 Words
Scrum is an agile process that allows us to focus on
delivering the highest business value in the shortest time.
It allows us to rapidly and repeatedly inspect actual
working software (every two weeks to one month).
The business sets the priorities. Our teams self-manage to
determine the best way to deliver the highest priority
features.
Every two weeks to a month anyone can see real working
software and decide to release it as is or continue to
enhance for another iteration.

25. 25
Scrum Characteristics
• Self-organizing teams
• Product progresses in a series of month-long “sprints”
• Requirements are captured as items in a list of
“product backlog”
• No specific engineering practices prescribed
• Uses generative rules to create an agile
environment for delivering projects
• One of the “agile processes”

26. 26
Scrum Framework
Roles
•Product owner
•ScrumMaster
•Team
Ceremonies
Artifacts
•Product backlog
•Sprint backlog
•Burndown charts
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting

27. 27
Scrum Roles – Product Owner
• Define the features of the product
• Decide on release date and content
• Be responsible for the profitability of the product (ROI)
• Prioritize features according to market value
• Adjust features and priority every iteration, as needed
• Accept or reject work results

28. 28
Scrum Roles – Scrum Master
• Represents management to the project
• Responsible for enacting Scrum values and practices
• Removes impediments
• Ensure that the team is fully functional and productive
• Enable close cooperation across all roles and functions
• Shield the team from external interferences

29. 29
Scrum Roles – The Team
• Typically 5-9 people
• Cross-functional:
• Programmers, testers, user experience designers, etc.
• Members should be full-time
• May be exceptions (e.g., database administrator)
• Teams are self-organizing
• Ideally, no titles but rarely a possibility
• Membership should change only between sprints

30. 30
Scrum Ceremonies - Planning Meeting
Sprint Planning
Meeting
Product Backlog
Team Capabilities
Business Conditions
Technology
Current Product
Sprint Goal
Sprint Backlog
Product Backlog

31. 31
Scrum Ceremonies - Planning Meeting
• Team selects items from the
product backlog they can commit
to completing
• Sprint backlog is created
• Tasks are identified and each is
estimated (1-16 hours)
• Collaboratively, not done alone
by the ScrumMaster
• High-level design is considered
Sprint
goal
Sprint
backlog

32. 32
Scrum Ceremonies – The Daily Scrum
• Parameters
• Daily
• 15-minutes
• Stand-up
• Not for problem solving
• Whole world is invited
• Only team members, ScrumMaster,
product owner, can talk
• Helps avoid other unnecessary
meetings

33. 33
Scrum Ceremonies – The Daily Scrum
What did you do yesterday?
1
What will you do today?
2
Is anything in your way?
3

34. 34
Scrum Ceremonies – The Sprint Review
• Team presents what it accomplished
during the sprint
• Typically takes the form of a demo of
new features or underlying architecture
• Informal
• 2-hour prep time rule
• No slides
• Whole team participates
• Invite the world

35. 35
Scrum Ceremonies – The Sprint Retrospective
• Periodically take a look at what is and is not working
• Typically 15–30 minutes
• Done after every sprint
• Whole team participates
• ScrumMaster
• Product owner
• Team
• Possibly customers and others

36. 36
Scrum Artifacts – The Product Backlog
• The requirements
• A list of all desired work
on the project
• Ideally expressed such
that each item has
value to the users or
customers of the
product
• Prioritized by the
product owner
• Reprioritized at the start
of each sprint

37. 37
Scrum Artifacts – The Sprint Backlog
• A subset of Product Backlog Items, which define the work for
a Sprint
• Is created ONLY by Team members
• Each Item has it’s own status
• Should be updated every day
• Individuals sign up for work of their own choosing
• Work is never assigned
• Estimated work remaining is updated daily

38. 38
Scrum Artifacts – The Sprint Backlog

39. 39
Scrum Artifacts – All Backlogs
Strategic
Roadmap
All the features of
product roadmap
Products’s Backlog
All the features of a
particular product
Sprint Backlog
Stories for the
sprint

40. 40
Scrum Artifacts – The Sprint Burndown Chart
• Depicts the total Sprint Backlog hours remaining per day
• Shows the estimated amount of time to release
• Ideally should burn down to zero to the end of the Sprint
• Actually is not a straight line
• Can bump UP

41. 41
Scrum Artifacts – The Sprint Burndown Chart

42. 42
Definition of Done
Code Commented
and Committed to
Line
Unit Tests
Developmen
t Finished
Report
Functional
Requirement
Document
Technical
Requirement
Document

43. Agile Practices
43

44. 44
For Though Tasks – Pair Programming

45. 45
For Though Tasks – Pair Programming
We help each other succeed. This practice comes
from XP.

46. 46
For Though Tasks – Pair Programming
Pair-Pressure
– Keep each other on task and focused
– Don’t want to let partner down
– “Embarrassed” to not follow the prescribed process
– Parkinson’s law “work expands to fill all available time.”
Pair-Think
– Distributed cognition: “searching through larger spaces of alternatives”
» Have shared goals and plans
» Bring different prior experiences to the task
» Different access to task relevant information
» Must negotiate a common shared of action
Pair-Relaying
– Each, in turn, contributes to the best of their knowledge and ability
– Then, sit back and think while their partner fights on

47. 47
For Though Tasks – Pair Programming
Pair-Reviews
– Continuous design and code reviews
– Ultimate in defect removal efficiency
– Removes programmers distaste for reviews
» 80% of all (solo) programmers don’t do them regularly or at all
Debug by describing
– Tell it to the Furby
Pair-Learning
– Continuous reviews learn from partners techniques, knowledge of
language, domain, etc.
– “Between the two of us, we knew it or could figure it out”
– Apprenticeship
– Defect prevention always more efficient than defect removal

48. 48
Roles – Pair Programming
The Driver
The person with control of the computer
Does the bulk of the typing
The Navigator
Actively follows along with the driver with comments
Can take over at any time

49. 49
For Quality – Continuous Integration
“ Continuous Integration is a software development practice
where members of a team integrate their work frequently, usually
each person integrates at least daily - leading to multiple
integrations per day. Each integration is verified by an automated
build (including test) to detect integration errors as quickly as
possible.“
http://martinfowler.com/articles/continuousIntegration.html

50. 50
For Quality – Continuous Integration
• The ultimate goal of continuous integration is to be able to
deploy all code.
• Although you won’t release in the middle of a sprint, the
point is to be technologically ready, even if you are not
functionally.
• With Continuous integration, you are integrating in short
cycle and thus have smaller changes to deal with as you
integrate.
• Continuous integration does not make sense unless it’s
automated, has a short turn around time (fast builds), and
everyone owns the concept of Green Builds.
• You need tests to fail or pass a build. Tests are the backbone
that give you a green or a red light to take a snapshot of
your build.

51. 51
Challenges – Continuous Integration
• Don’t force this. It requires everyone to buy-in.
• CI also requires some setup, if you don’t have one.
• Keeping build times short. This might require some serious
effort and might show you the deficiency of your builds.
• And you need a good version control system – VC systems
like subversion that allows atomic check-in.

52. 52
Start with the wheels – Interactive Design

53. 53
It’s Simulation Time!

54. Agile Values
54

55. 55
COMMITMENT

56. 56
COLLECTIVE
OWNERSHIP

57. 57
COMMUNICATION
COLLABORATION

58. 58
PEOPLE

59. Thank
You!
59