The document discusses Agile project management and Scrum frameworks. It describes Agile as a collection of values and principles for software development that emphasize individuals, working software, customer collaboration, and responding to change. Scrum is presented as a framework that uses short iterations called sprints, daily stand-up meetings, and emphasizes self-organizing cross-functional teams to deliver working software increments for customer feedback. Effective Scrum teams are autonomous, strive for continuous improvement, and have members with diverse skills who collaborate well.

1. agile @ enterprise
Adnan Masood
Sr. Software Architect / Doctoral Candidate
scis.nova.edu/~adnan
adnan.masood@owasp.org

2. what is Agile?
2

3. What is Agile?
Agile is not a methodology.
It is a collection of 4 values and
12 principles that describe how
process, practices, and people
work together in Agile software
development.
3

4. These values and principles
are used as guidance for a
team or organization when
deciding how a situation
they are brought up
against should be
handled.
4

5. Agile values
• Individuals and interactions
– over processes and tools
• Working software
– over comprehensive documentation
• Customer collaboration
– over contract negotiation
• Responding to change
– over following a plan
5

6. Agile principles
• Customer satisfaction by rapid
delivery of useful software
• Welcome changing requirements,
even late in development
• Working software is delivered
frequently (weeks rather than
months)
6

7. Agile principles
• Working software is the principal
measure of progress
• Sustainable development, able to
maintain a constant pace
• Close, daily co-operation
between business people and
developers
7

8. Agile principles
• Face-to-face conversation is the
best form of communication (co-
location)
• Projects are built around
motivated individuals, who should
be trusted
• Continuous attention to technical
excellence and good design
8

9. Agile principles
• Simplicity- The art of maximizing
the amount of work not done - is
essential
• Self-organizing teams
• Regular adaptation to changing
circumstances
9

10. Agile Practices work
within an organization
to enable these values
and principles
10

11. Agile approaches shorten the
feedback cycle between
customers, development
team, and working software.
11

12. Agile teams manage their
development efforts to get
working software in the
hands of customers so they
can touch and feel it and
provide feedback.
12

13. Short iterations with feedback
from the customers increase
the possibility that the
software will align with
customer desires and
expectations.
13

14. Agile project
management
14

15. Scrum is a project
management
framework invented
by Jeff Sutherland at
Easel Corporation in
1993.
15

16. Scrum highlights the differences
between
defined (plan-driven)
and
empirical
process control models.
16

17. Defined process controls assume
that the work can be fully
understood up-front.
– But, software projects are more
complicated.
– They contain surprises throughout all
aspects of the development
process.
17

18. Empirical process controls use
an “inspect and adapt” progress
monitoring to manage
complexity in software
development.
18

19. In Scrum, there are three roles:
• Project Team
• Product Owner
• Scrum Master
19

20. Scrum
Scrum starts when a Product
Owner comes up with a
product vision.
The Product Owner then
generates the Product Backlog
that describes this product vision
in more detail.
20

21. Scrum
The list of items contained
in the Product Backlog is
prioritized in stack-rank
order and estimated by
the Project Team.
21

22. Sprint Planning Meeting
When the Product Backlog
contains enough work for the
Project Team to implement in a
single time-boxed iteration,
called a Sprint, then they
conduct a Sprint Planning
Meeting to decide what to work
on.
22

23. Sprint Planning Meeting
The Product Owner describes
highest priority Product Backlog
items to the Project Team.
The Project Team members ask
questions about the Product
Backlog items to gain clarity of
the feature requirements.
23

24. Sprint Planning Meeting
The Project Team focuses on
coming up with a plan on how
they will deliver those Product
Backlog items in their own Sprint
Backlog.
24

25. Sprint Planning Meeting
The Project Team
• Breaks down the Product Backlog items
into smaller Tasks
– Architecture
– Coding
– Integration
– Testing
– Documentation
– Etc.
• Commits to a Sprint Backlog after
tasking out a set of Product
Backlog items to work on.
25

26. The Sprint
After the Project Team commits
to a Sprint Backlog, they start
work.
It is common to conduct Sprints
in three, two, and even one-
week increments.
26

27. The Sprint
During the Sprint, the Project Team gets
together each day for a time-boxed
meeting called the Daily Scrum.
–They discuss
• what they have done since last
meeting,
• what they plan to do, and
• any impediments blocking their work.
27

28. The Sprint
The focus of the Daily Scrum is not
giving status but rather for the
Project Team to figure out if they
are still on track to deliver on their
commitments for this Sprint.
If they are not on track then action can
be taken immediately.
28

29. Product Owner Demo
At the end of the Sprint, the Project
Team demos the software created.
The demonstration is to the
Product Owner and any other
interested stakeholders that attend
the Sprint Review Meeting.
29

30. Product Owner Demo
The team is expected to have
created a Potentially Shippable
Product Increment that
• Contains all of the quality that a
shippable product would include
• Gives the Product Owner the
opportunity to decide to deploy
the software to the users.
30

31. Sprint Retrospective
After the Potentially Shippable
Product Increment is reviewed,
the Project Team conducts a
Sprint Retrospective where they
look at the process used this
Sprint looking for ways to
improve.
31

32. Sprint Retrospective
The Sprint Retrospective results
in a list of improvements the
Project Team will take on the
next Sprint, which starts the next
day with a Sprint Planning
Meeting.
32

33. Scrum
33

34. Scrum
Applying this simple
framework has shown
to be incredibly difficult
for many organizations.
34

35. Scrum
Some organizations try to apply
Scrum “by the book”
–but don’t comprehend the
focus on “inspect and adapt”.
35

36. Scrum
Others incorporate a subset of the
Scrum framework and call it “Scrum”.
This is referred to as “Scrum but”, as in:
– “we do Scrum but we don’t meet for
a Sprint Retrospective”.
– “we do Scrum but we do coding in
one Sprint and then do testing in the
next Sprint”.
36

37. Scrum
Effective use of Scrum enables project
teams to deliver increments of
software that are potentially
shippable in 30 days or less.
The Product Owner then decides if
there is sufficient value in what has
been delivered for deployment to
the software’s users.
37

38. Scrum
It’s common for Product
Owners to find early release
opportunities.
These early releases minimize
the amount of investment
needed to give additional
value to the users.
38

39. Agile Teams
39

40. Six characteristics
of
product development teams
at
highly innovative
and
successful companies:
40

41. Characteristics of Highly Innovative Teams
Built-in instability:
Management provides a
challenging goal to a team
and gives them extreme
freedom to implement a
product that meets the goal.
41

42. Characteristics of Highly Innovative Teams
Self-organizing project teams:
Teams are introduced to the
product goal and must
organize around this work
across functional disciplines.
42

43. Characteristics of Highly Innovative Teams
Overlapping development
phases:
• Optimizes functional phases of
product development
• Teams synchronize their delivery
• Forces interactivity between
functional roles to meet delivery
goals
– As opposed to the relay race or hand-off
approach
43

44. Characteristics of Highly Innovative Teams
“Multi-learning”:
Involves learning at multiple levels
• Individual
• Team
• Corporate
Team members
• interact closely with external entities and
within their team
• Acquire new knowledge and skill sets to assess
and use this new knowledge quickly.
44

45. Characteristics of Highly Innovative Teams
Subtle control:
• Emphasis is on a team’s
internal self-control.
• Management provides
checkpoints to minimize
instability, ambiguity, and
tension in pursuit of a
challenging goal.
45

46. Characteristics of Highly Innovative Teams
Organizational transfer of
learning
Teams work to transfer their
learning to others outside the
group.
46

47. “The best architectures,
requirements, and designs
emerge from self-
organizing teams”
–Principles behind the Agile Manifesto
47

48. Self Organizing Project Teams
Multiple functional roles are represented
on an Agile Scrum Project Team:
• Analysis
• Architecture
• Design
• Testing
• Programming
• User experience
• Database
• Other roles, depending on the project
48

49. Self Organizing Project Teams
Agile teams look for ways to
implement features that are
verified and validated each
iteration cycle.
This entails high degrees of
collaboration between people in
functional roles during the iteration.
49

50. Self Organizing Project Teams
If appropriate functional roles for the
project are not represented or
limited on the team, it will show in the
software delivery.
– Team members will either have to
cover the work conducted in this
functional area or let the work pile up
to be done later.
– When work is left for later it becomes
more complicated, overwhelming, and
error-prone.
50

51. Self Organizing Project Teams
In Scrum, the entire team,
including Product Owner and
Scrum Master, are a self-
contained unit.
Well-defined interfaces into the
team enable the Scrum team to
act as an autonomous unit.
51

52. Self Organizing Project Teams
Autonomy
• External involvement is limited to
guidance, money, and moral
support.
• Top management rarely
intervenes in the team’s work.
• The team is able to set their own
direction on day-to-day activities.
52

53. Self Organizing Project Teams
Self-transcendence
• The team seems to be continually
striving for perfection.
• Teams set their own goals that
align with top management
objectives and devise ways to
change the status quo.
53

54. Self Organizing Project Teams
Cross-fertilization
• Teams have members with
different functional specializations,
thought processes, and behavior
patterns.
• These differences enhance the
product development once team
members start interacting
effectively.
54

55. Self Organizing Project Teams
The Scrum Project Team is
expected to make
incremental improvements
to transcend their existing
software delivery process
that result in better quality
and faster throughput of
feature delivery.
55

56. Agile design practices
56

57. A common misconception
about Agile teams is that they
do not perform design
activities.
This perception is a result of
associating design with
traditional design document
templates and “Big Design Up
Front”.
57

58. Consider:
The reason for
specifying business
requirements and
technical design before
construction is to
reduce risk.
58

59. But…
Customers don’t know all of the
requirements up front.
Requirements emerge during
implementation.
The people that create business
requirements and design specifications
are not easily accessible once
construction of the software begins.
59

60. The problems with Big Design
Up Front are a symptom of
feedback cycles that are too
long in duration.
The time needed to analyze, specify, and
design software before constructing it
allows requirements and designs to grow
stale before they are implemented.
60

61. Development teams often
interpret business requirements
incorrectly.
Business needs change frequently.
Requirement details specified
weeks or months prior are not
necessarily valuable today.
61

62. Creation of design
documentation has not
assured the development of
well-crafted software that
evolves in parallel with
changing business needs.
62

63. Also, writing design
documentation, and the
practice of evaluating the
soundness of these designs,
slows the development
process and delays essential
feedback from stakeholders
and users.
63

64. Instead of taking an
up front design
approach, Agile
teams design all the
time.
64

65. “Continuous attention to
technical excellence and
good design enhances
agility.”
- Manifesto for Agile Software Development
65

66. Filling out design
documentation, such as
detailed designs, has
become synonymous with
“good” design.
Yet most software is riddled
with defects and decay.
66

67. Agile methods identify
practices, process, and
tools to enable
evolutionary design.
This is not synonymous with undisciplined or
“cowboy” coding of software.
67

68. In Agile software
development teams, design
is continuously attended to
while implementing features.
There is less focus on
documentation and hand-
offs.
68

69. People who have
traditionally provided designs
are expected to work closer
with the teams during
iterations.
The best way to do this is be
part of the team.
69

70. When documentation is
necessary or supports the
continued maintenance of
the software, it is created
alongside the
implementation of features
that made visible the
need.
70

71. Agile teams do not always generate
“pretty” diagrams so that they can be
useful today and into the future.
Most diagrams
– are short-lived
– offer just enough information to
get a small group of people
aligned about how to move
forward
71

72. Agile teams think about how
the diagram will be used and
make decisions about how
formal an approach for
capturing it should be used.
72

73. Making diagrams “pretty” is a
wasted effort in most situations.
For short-lived diagrams, Agile teams use
transitory mediums
– Whiteboards
– pieces of paper
– the back of a napkin
These are sufficient to make the
diagram visible to the group.
73

74. The basic idea is to allow diagrams
that are transient in nature to be
erased, thrown away, or deleted
when you are finished with them.
If the diagram is not going to be used in
the future, then we can throw it away as
soon as it no longer adds value.
74

75. When diagrams are going to
be useful either for
communicating essential
models or for creating
executable artifacts it is good
to make them usable for
future reading and
maintenance.
75

76. When working with people in
remote locations, a virtual
whiteboard application or
sharing of applications across
the network could support
effective collaboration
around a diagram.
76

77. Agile architecture
practices
77

78. Agile teams are asked to think
broader than a single component
or application when planning,
implementing, and testing features.
It is important that they include any
integration with external
applications into their incremental
designs.
78

79. An Agile team looks for
ways to consolidate their
efforts into practical focus
areas that are
manageable from iteration
to iteration as the
application and its design
evolves.
79

80. Agile teams are also asked to
continually incorporate
enhancements to quality attributes
of the software:
– Suitability: Functionality is suitable to all end users
– Interoperability: Functionality interoperates with
other systems easily
– Compliance: Functionality is compliant with
applicable regulatory guidelines
80

81. – Security: System is secure: confidentiality,
integrity, availability, accountability and
assurance
– Maturity: System components are proven stable
by others
– Fault Tolerance: System continues operating
properly in the event of failure by one or more of
its components
– Recoverability: System recovers from failures in
surrounding environment
– Operability: Ability to keep a system in a functioning
and operating condition
– Performance: Perceived response is immediate
– Scalability: Able to handle increased usage on the
appropriate amount of resources
81

82. – Understandability: Able to use system with little
training
– Learnability: Supports learning of system functionality
with little external interfacing
– Analyzability: Ability to figure out how the system
functions
– Changeability: Ability to change the system
components to meet new business needs
– Testability: Ability to create repeatable and specific
tests of the system and potential for some to be
automated
– Adaptability: Ability to change out system
component functionality quickly
– Installability: Ease of installation and reinstallation
– Conformance: Conformance to industry and
operational standards
– Replaceability: Ability to replace system
82

83. Agile Application Architecture
83

84. Agile technical
practices
84

85. Extreme Programming
eXtreme Programming (XP) is a
development process based on
values of communication,
simplicity, feedback, and
courage.
Invented by Kent Beck, Ron Jeffries, and Ward
Cunningham during the Chrysler Comprehensive
Compensation (C3) System project around 1997.
85

86. Extreme Programming
Communication is important since
Most problems occur
because the right people
did not speak at the right
moment during a
project.
86

87. Extreme Programming
Communication:
Teams should sit together in close proximity
so they can communicate quickly about
issues.
The customer should also remain close to
the team so they can answer questions
early in the delivery.
– This reduces the amount of churn a team goes
through deciding on how the customer wants
the functionality to behave.
87

88. Extreme Programming
Simplicity is doing the “simplest thing
that could possibly work”.
• This is difficult because traditional
development methods tell us to
analyze and design a solution before
implementing it.
• In XP, disciplined use of practices help
reduce complexity in software
development.
88

89. Extreme Programming
Feedback is an essential element of XP.
• Within seconds during a pair
programming session you get
feedback about the code being
written.
• Within minutes we are executing
test cases successfully for new
functionality.
89

90. Extreme Programming
Feedback is an essential element of XP.
• Within days we are getting
feedback from users about new
features put into the software.
• Within weeks we are deploying to
production and getting feedback on
how it works for the end users in their
daily lives.
90

91. Extreme Programming
Courage to do what is right during a software
release cycle can be difficult for teams.
• Having the courage to throw it out or
rewrite it.
• Trying out a new design with just
enough discussion to start coding
and proving its ability to solve an issue
through code.
91

92. Extreme Programming
92

93. Extreme Programming
XP focuses on reducing the
cost of change during
feature development
through the use of twelve
practices.
93

94. Extreme Programming
The Planning Game
– Figure out the features that go into the next
release, through prioritization and group
estimation.
Small releases
– Release the minimum amount of valuable
features to production and then follow up with
subsequent releases.
Metaphor
– Provide a shared story about the software under
development.
94

95. Extreme Programming
Simple design
– Design the system for simplicity and
– Remove complexity when identified.
Testing
– Team members and customers execute tests to
validate the software is in good health and features
are working.
Refactoring
– Modify the software’s structure through small
and frequent changes that result in better
design without affecting the way it functions.
95

96. Extreme Programming
Pair programming
– Two programmers often work together on
production artifacts.
Collective ownership
– Any team member can change any part of the
software anytime.
Continuous integration
– Build, integrate, and execute automated tests
after each task is finished.
– This happens many times a day.
96

97. Extreme Programming
Sustainable Pace
– Don’t put in overtime hours two weeks in a row.
On-site customer
– An actual user of the system is available full-time
to the team to answer questions and validate
features.
Coding standards
– Programmers establish guidelines for writing all
code to help communication through the
software artifacts.
97

98. Extreme Programming
Most teams who say they do XP are only
practicing a portion of the twelve
practices.
Most of the XP practices take a
significant change in mindset to be
done effectively by software
development teams.
98

99. Extreme Programming
When XP is implemented effectively it
has been shown to significantly reduce
entropy as software ages.
When scaling to teams larger than ten
members, many of the XP technical
practices are used within the Scrum
project management framework.
99

100. References