SlideShare una empresa de Scribd logo
1 de 100
Descargar para leer sin conexión
agile @ enterprise
Adnan Masood
Sr. Software Architect / Doctoral Candidate
scis.nova.edu/~adnan
adnan.masood@owasp.org
what is Agile?
2
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
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
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
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
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
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
Agile principles
• Simplicity- The art of maximizing
the amount of work not done - is
essential
• Self-organizing teams
• Regular adaptation to changing
circumstances
9
Agile Practices work
within an organization
to enable these values
and principles
10
Agile approaches shorten the
feedback cycle between
customers, development
team, and working software.
11
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
Short iterations with feedback
from the customers increase
the possibility that the
software will align with
customer desires and
expectations.
13
Agile project
management
14
Scrum is a project
management
framework invented
by Jeff Sutherland at
Easel Corporation in
1993.
15
Scrum highlights the differences
between
defined (plan-driven)
and
empirical
process control models.
16
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
Empirical process controls use
an “inspect and adapt” progress
monitoring to manage
complexity in software
development.
18
In Scrum, there are three roles:
• Project Team
• Product Owner
• Scrum Master
19
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
Scrum
The list of items contained
in the Product Backlog is
prioritized in stack-rank
order and estimated by
the Project Team.
21
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
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
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
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
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
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
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
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
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
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
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
Scrum
33
Scrum
Applying this simple
framework has shown
to be incredibly difficult
for many organizations.
34
Scrum
Some organizations try to apply
Scrum “by the book”
–but don’t comprehend the
focus on “inspect and adapt”.
35
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
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
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
Agile Teams
39
Six characteristics
of
product development teams
at
highly innovative
and
successful companies:
40
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
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
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
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
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
Characteristics of Highly Innovative Teams
Organizational transfer of
learning
Teams work to transfer their
learning to others outside the
group.
46
“The best architectures,
requirements, and designs
emerge from self-
organizing teams”
–Principles behind the Agile Manifesto
47
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
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
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
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
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
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
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
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
Agile design practices
56
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
Consider:
The reason for
specifying business
requirements and
technical design before
construction is to
reduce risk.
58
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
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
Development teams often
interpret business requirements
incorrectly.
Business needs change frequently.
Requirement details specified
weeks or months prior are not
necessarily valuable today.
61
Creation of design
documentation has not
assured the development of
well-crafted software that
evolves in parallel with
changing business needs.
62
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
Instead of taking an
up front design
approach, Agile
teams design all the
time.
64
“Continuous attention to
technical excellence and
good design enhances
agility.”
- Manifesto for Agile Software Development
65
Filling out design
documentation, such as
detailed designs, has
become synonymous with
“good” design.
Yet most software is riddled
with defects and decay.
66
Agile methods identify
practices, process, and
tools to enable
evolutionary design.
This is not synonymous with undisciplined or
“cowboy” coding of software.
67
In Agile software
development teams, design
is continuously attended to
while implementing features.
There is less focus on
documentation and hand-
offs.
68
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
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
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
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
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
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
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
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
Agile architecture
practices
77
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
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
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
– 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
– 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
Agile Application Architecture
83
Agile technical
practices
84
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
Extreme Programming
Communication is important since
Most problems occur
because the right people
did not speak at the right
moment during a
project.
86
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
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
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
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
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
Extreme Programming
92
Extreme Programming
XP focuses on reducing the
cost of change during
feature development
through the use of twelve
practices.
93
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
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
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
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
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
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
References

Más contenido relacionado

La actualidad más candente

Agile project management using scrum
Agile project management using scrumAgile project management using scrum
Agile project management using scrumPrudentialSolutions
 
Agile software development development explained
Agile software development development explainedAgile software development development explained
Agile software development development explainedServan Huegen
 
Agile and CMMI: Yes, They Can Work Together
Agile and CMMI: Yes, They Can Work TogetherAgile and CMMI: Yes, They Can Work Together
Agile and CMMI: Yes, They Can Work TogetherTechWell
 
Software Project management
Software Project managementSoftware Project management
Software Project managementsameer farooq
 
Introduction to Agile Software Development
Introduction to Agile Software DevelopmentIntroduction to Agile Software Development
Introduction to Agile Software Developmentaboulkheir
 
Lean as Agile methodology – A Study
Lean as Agile methodology – A StudyLean as Agile methodology – A Study
Lean as Agile methodology – A StudyEswar Publications
 
Building an Agile framework that fits your organisation
Building an Agile framework that fits your organisationBuilding an Agile framework that fits your organisation
Building an Agile framework that fits your organisationKurt Solarte
 
High Quality Software Development with Agile and Scrum
High Quality Software Development with Agile and ScrumHigh Quality Software Development with Agile and Scrum
High Quality Software Development with Agile and ScrumLemi Orhan Ergin
 
Agile Project Management for IT Projects
Agile Project Management for IT ProjectsAgile Project Management for IT Projects
Agile Project Management for IT Projectsrachna_nainani
 
Agile project management
Agile project management Agile project management
Agile project management Bimba Pawar
 
9 steps to agile adoption – a proposal
9 steps to agile adoption – a proposal9 steps to agile adoption – a proposal
9 steps to agile adoption – a proposalNaveen Indusekhar
 
Agile project management
Agile project managementAgile project management
Agile project managementeng100
 

La actualidad más candente (20)

Agile
AgileAgile
Agile
 
Agile project management using scrum
Agile project management using scrumAgile project management using scrum
Agile project management using scrum
 
Lect3
Lect3Lect3
Lect3
 
Agile software development development explained
Agile software development development explainedAgile software development development explained
Agile software development development explained
 
Agile and CMMI: Yes, They Can Work Together
Agile and CMMI: Yes, They Can Work TogetherAgile and CMMI: Yes, They Can Work Together
Agile and CMMI: Yes, They Can Work Together
 
Agile & Scrum Training
Agile & Scrum TrainingAgile & Scrum Training
Agile & Scrum Training
 
Software Project management
Software Project managementSoftware Project management
Software Project management
 
Introduction to Agile Software Development
Introduction to Agile Software DevelopmentIntroduction to Agile Software Development
Introduction to Agile Software Development
 
Lean as Agile methodology – A Study
Lean as Agile methodology – A StudyLean as Agile methodology – A Study
Lean as Agile methodology – A Study
 
Scrum intro conscires
Scrum intro   consciresScrum intro   conscires
Scrum intro conscires
 
Agile Project Management
Agile Project ManagementAgile Project Management
Agile Project Management
 
Scrum intro conscires - ocpm
Scrum intro   conscires - ocpmScrum intro   conscires - ocpm
Scrum intro conscires - ocpm
 
Webinar - Into to Scrum by Bachan Anand
Webinar - Into to Scrum by  Bachan AnandWebinar - Into to Scrum by  Bachan Anand
Webinar - Into to Scrum by Bachan Anand
 
Building an Agile framework that fits your organisation
Building an Agile framework that fits your organisationBuilding an Agile framework that fits your organisation
Building an Agile framework that fits your organisation
 
High Quality Software Development with Agile and Scrum
High Quality Software Development with Agile and ScrumHigh Quality Software Development with Agile and Scrum
High Quality Software Development with Agile and Scrum
 
Agile Project Management for IT Projects
Agile Project Management for IT ProjectsAgile Project Management for IT Projects
Agile Project Management for IT Projects
 
Agile project management
Agile project management Agile project management
Agile project management
 
9 steps to agile adoption – a proposal
9 steps to agile adoption – a proposal9 steps to agile adoption – a proposal
9 steps to agile adoption – a proposal
 
Agile project management
Agile project managementAgile project management
Agile project management
 
Metodologia scrum actualizada qa
Metodologia scrum actualizada qaMetodologia scrum actualizada qa
Metodologia scrum actualizada qa
 

Destacado

Destacado (7)

Presentation - Rational Unified Process
Presentation - Rational Unified ProcessPresentation - Rational Unified Process
Presentation - Rational Unified Process
 
RUP
RUPRUP
RUP
 
RUP model
RUP modelRUP model
RUP model
 
Rational Unified Process
Rational Unified ProcessRational Unified Process
Rational Unified Process
 
Agile Methodology
Agile MethodologyAgile Methodology
Agile Methodology
 
Agile Software Development Overview
Agile Software Development OverviewAgile Software Development Overview
Agile Software Development Overview
 
Overview of Agile Methodology
Overview of Agile MethodologyOverview of Agile Methodology
Overview of Agile Methodology
 

Similar a Agile Software Development

SE18_Lec 05_Agile Software Development
SE18_Lec 05_Agile Software DevelopmentSE18_Lec 05_Agile Software Development
SE18_Lec 05_Agile Software DevelopmentAmr E. Mohamed
 
SE_Lec 04_Agile Software Development
SE_Lec 04_Agile Software DevelopmentSE_Lec 04_Agile Software Development
SE_Lec 04_Agile Software DevelopmentAmr E. Mohamed
 
Lecture 5 -6(CSC205).pptx jsksnxbbxjxksnsnz
Lecture 5 -6(CSC205).pptx jsksnxbbxjxksnsnzLecture 5 -6(CSC205).pptx jsksnxbbxjxksnsnz
Lecture 5 -6(CSC205).pptx jsksnxbbxjxksnsnzAhmadSajjad34
 
Agile - Basics.pptxjvjplhxitstistidara तिहोचपवपज्वो
Agile - Basics.pptxjvjplhxitstistidara तिहोचपवपज्वोAgile - Basics.pptxjvjplhxitstistidara तिहोचपवपज्वो
Agile - Basics.pptxjvjplhxitstistidara तिहोचपवपज्वोMnyMehr
 
Agile Project Management – SCRUM Methodology
Agile Project Management – SCRUM MethodologyAgile Project Management – SCRUM Methodology
Agile Project Management – SCRUM MethodologyMarios Evripidou
 
Chapter 1_Introduction sunorganisedASE_finalised.pptx
Chapter 1_Introduction sunorganisedASE_finalised.pptxChapter 1_Introduction sunorganisedASE_finalised.pptx
Chapter 1_Introduction sunorganisedASE_finalised.pptxBule Hora University
 
Agile Software Development Overview
Agile Software Development OverviewAgile Software Development Overview
Agile Software Development OverviewDUONG Trong Tan
 
Introduction to the Agile Methods
Introduction to the Agile MethodsIntroduction to the Agile Methods
Introduction to the Agile Methodssoftwareacademy
 
software engineering agile development notes.pptx
software engineering agile development notes.pptxsoftware engineering agile development notes.pptx
software engineering agile development notes.pptxAbhinay93499
 
Agile Framework based on PMBOK 6th Edition.pdf
Agile Framework based on PMBOK 6th Edition.pdfAgile Framework based on PMBOK 6th Edition.pdf
Agile Framework based on PMBOK 6th Edition.pdfAliAfrazAjmal
 
Chapter1 Advanced Software Engineering overview
Chapter1 Advanced Software Engineering overviewChapter1 Advanced Software Engineering overview
Chapter1 Advanced Software Engineering overviewBule Hora University
 
Agile Scrum Methodology - Introduction
Agile Scrum Methodology - IntroductionAgile Scrum Methodology - Introduction
Agile Scrum Methodology - IntroductionGeetha Madhuri
 
Agile Software Development with Scrum_ A Complete Guide to The Steps in Agile...
Agile Software Development with Scrum_ A Complete Guide to The Steps in Agile...Agile Software Development with Scrum_ A Complete Guide to The Steps in Agile...
Agile Software Development with Scrum_ A Complete Guide to The Steps in Agile...Fibonalabs
 

Similar a Agile Software Development (20)

SE18_Lec 05_Agile Software Development
SE18_Lec 05_Agile Software DevelopmentSE18_Lec 05_Agile Software Development
SE18_Lec 05_Agile Software Development
 
SE_Lec 04_Agile Software Development
SE_Lec 04_Agile Software DevelopmentSE_Lec 04_Agile Software Development
SE_Lec 04_Agile Software Development
 
Lecture 5 -6(CSC205).pptx jsksnxbbxjxksnsnz
Lecture 5 -6(CSC205).pptx jsksnxbbxjxksnsnzLecture 5 -6(CSC205).pptx jsksnxbbxjxksnsnz
Lecture 5 -6(CSC205).pptx jsksnxbbxjxksnsnz
 
Agile - Basics.pptxjvjplhxitstistidara तिहोचपवपज्वो
Agile - Basics.pptxjvjplhxitstistidara तिहोचपवपज्वोAgile - Basics.pptxjvjplhxitstistidara तिहोचपवपज्वो
Agile - Basics.pptxjvjplhxitstistidara तिहोचपवपज्वो
 
Agile Project Management – SCRUM Methodology
Agile Project Management – SCRUM MethodologyAgile Project Management – SCRUM Methodology
Agile Project Management – SCRUM Methodology
 
Fundamental of Scrum
Fundamental of ScrumFundamental of Scrum
Fundamental of Scrum
 
Chapter 1_Introduction sunorganisedASE_finalised.pptx
Chapter 1_Introduction sunorganisedASE_finalised.pptxChapter 1_Introduction sunorganisedASE_finalised.pptx
Chapter 1_Introduction sunorganisedASE_finalised.pptx
 
Agile Software Development Overview
Agile Software Development OverviewAgile Software Development Overview
Agile Software Development Overview
 
Introduction to the Agile Methods
Introduction to the Agile MethodsIntroduction to the Agile Methods
Introduction to the Agile Methods
 
software engineering agile development notes.pptx
software engineering agile development notes.pptxsoftware engineering agile development notes.pptx
software engineering agile development notes.pptx
 
Agile methodology
Agile methodologyAgile methodology
Agile methodology
 
Agile Scrum CMMI
Agile Scrum CMMIAgile Scrum CMMI
Agile Scrum CMMI
 
Agile Framework based on PMBOK 6th Edition.pdf
Agile Framework based on PMBOK 6th Edition.pdfAgile Framework based on PMBOK 6th Edition.pdf
Agile Framework based on PMBOK 6th Edition.pdf
 
Chapter1 Advanced Software Engineering overview
Chapter1 Advanced Software Engineering overviewChapter1 Advanced Software Engineering overview
Chapter1 Advanced Software Engineering overview
 
Agile Scrum Methodology - Introduction
Agile Scrum Methodology - IntroductionAgile Scrum Methodology - Introduction
Agile Scrum Methodology - Introduction
 
Scrum
ScrumScrum
Scrum
 
Scrum Overview
Scrum OverviewScrum Overview
Scrum Overview
 
Agile Introduction
Agile IntroductionAgile Introduction
Agile Introduction
 
Agile Software Development with Scrum_ A Complete Guide to The Steps in Agile...
Agile Software Development with Scrum_ A Complete Guide to The Steps in Agile...Agile Software Development with Scrum_ A Complete Guide to The Steps in Agile...
Agile Software Development with Scrum_ A Complete Guide to The Steps in Agile...
 
4. ch 3-agile process
4. ch 3-agile process4. ch 3-agile process
4. ch 3-agile process
 

Más de Adnan Masood

Spark with Azure HDInsight - Tampa Bay Data Science - Adnan Masood, PhD
Spark with Azure HDInsight  - Tampa Bay Data Science - Adnan Masood, PhDSpark with Azure HDInsight  - Tampa Bay Data Science - Adnan Masood, PhD
Spark with Azure HDInsight - Tampa Bay Data Science - Adnan Masood, PhDAdnan Masood
 
Data science with Windows Azure - A Brief Introduction
Data science with Windows Azure - A Brief IntroductionData science with Windows Azure - A Brief Introduction
Data science with Windows Azure - A Brief IntroductionAdnan Masood
 
Restructuring Technical Debt - A Software and System Quality Approach
Restructuring Technical Debt - A Software and System Quality ApproachRestructuring Technical Debt - A Software and System Quality Approach
Restructuring Technical Debt - A Software and System Quality ApproachAdnan Masood
 
System Quality Attributes for Software Architecture
System Quality Attributes for Software ArchitectureSystem Quality Attributes for Software Architecture
System Quality Attributes for Software ArchitectureAdnan Masood
 
Belief Networks & Bayesian Classification
Belief Networks & Bayesian ClassificationBelief Networks & Bayesian Classification
Belief Networks & Bayesian ClassificationAdnan Masood
 
Bayesian Networks and Association Analysis
Bayesian Networks and Association AnalysisBayesian Networks and Association Analysis
Bayesian Networks and Association AnalysisAdnan Masood
 
Probabilistic Interestingness Measures - An Introduction with Bayesian Belief...
Probabilistic Interestingness Measures - An Introduction with Bayesian Belief...Probabilistic Interestingness Measures - An Introduction with Bayesian Belief...
Probabilistic Interestingness Measures - An Introduction with Bayesian Belief...Adnan Masood
 
Bayesian Networks - A Brief Introduction
Bayesian Networks - A Brief IntroductionBayesian Networks - A Brief Introduction
Bayesian Networks - A Brief IntroductionAdnan Masood
 
Web API or WCF - An Architectural Comparison
Web API or WCF - An Architectural ComparisonWeb API or WCF - An Architectural Comparison
Web API or WCF - An Architectural ComparisonAdnan Masood
 
SOLID Principles of Refactoring Presentation - Inland Empire User Group
SOLID Principles of Refactoring Presentation - Inland Empire User GroupSOLID Principles of Refactoring Presentation - Inland Empire User Group
SOLID Principles of Refactoring Presentation - Inland Empire User GroupAdnan Masood
 
Brief bibliography of interestingness measure, bayesian belief network and ca...
Brief bibliography of interestingness measure, bayesian belief network and ca...Brief bibliography of interestingness measure, bayesian belief network and ca...
Brief bibliography of interestingness measure, bayesian belief network and ca...Adnan Masood
 

Más de Adnan Masood (11)

Spark with Azure HDInsight - Tampa Bay Data Science - Adnan Masood, PhD
Spark with Azure HDInsight  - Tampa Bay Data Science - Adnan Masood, PhDSpark with Azure HDInsight  - Tampa Bay Data Science - Adnan Masood, PhD
Spark with Azure HDInsight - Tampa Bay Data Science - Adnan Masood, PhD
 
Data science with Windows Azure - A Brief Introduction
Data science with Windows Azure - A Brief IntroductionData science with Windows Azure - A Brief Introduction
Data science with Windows Azure - A Brief Introduction
 
Restructuring Technical Debt - A Software and System Quality Approach
Restructuring Technical Debt - A Software and System Quality ApproachRestructuring Technical Debt - A Software and System Quality Approach
Restructuring Technical Debt - A Software and System Quality Approach
 
System Quality Attributes for Software Architecture
System Quality Attributes for Software ArchitectureSystem Quality Attributes for Software Architecture
System Quality Attributes for Software Architecture
 
Belief Networks & Bayesian Classification
Belief Networks & Bayesian ClassificationBelief Networks & Bayesian Classification
Belief Networks & Bayesian Classification
 
Bayesian Networks and Association Analysis
Bayesian Networks and Association AnalysisBayesian Networks and Association Analysis
Bayesian Networks and Association Analysis
 
Probabilistic Interestingness Measures - An Introduction with Bayesian Belief...
Probabilistic Interestingness Measures - An Introduction with Bayesian Belief...Probabilistic Interestingness Measures - An Introduction with Bayesian Belief...
Probabilistic Interestingness Measures - An Introduction with Bayesian Belief...
 
Bayesian Networks - A Brief Introduction
Bayesian Networks - A Brief IntroductionBayesian Networks - A Brief Introduction
Bayesian Networks - A Brief Introduction
 
Web API or WCF - An Architectural Comparison
Web API or WCF - An Architectural ComparisonWeb API or WCF - An Architectural Comparison
Web API or WCF - An Architectural Comparison
 
SOLID Principles of Refactoring Presentation - Inland Empire User Group
SOLID Principles of Refactoring Presentation - Inland Empire User GroupSOLID Principles of Refactoring Presentation - Inland Empire User Group
SOLID Principles of Refactoring Presentation - Inland Empire User Group
 
Brief bibliography of interestingness measure, bayesian belief network and ca...
Brief bibliography of interestingness measure, bayesian belief network and ca...Brief bibliography of interestingness measure, bayesian belief network and ca...
Brief bibliography of interestingness measure, bayesian belief network and ca...
 

Último

NIST Cybersecurity Framework (CSF) 2.0 Workshop
NIST Cybersecurity Framework (CSF) 2.0 WorkshopNIST Cybersecurity Framework (CSF) 2.0 Workshop
NIST Cybersecurity Framework (CSF) 2.0 WorkshopBachir Benyammi
 
COMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a WebsiteCOMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a Websitedgelyza
 
UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7DianaGray10
 
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IES VE
 
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve DecarbonizationUsing IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve DecarbonizationIES VE
 
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostKubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostMatt Ray
 
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...UbiTrack UK
 
UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6DianaGray10
 
Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.YounusS2
 
UiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPathCommunity
 
Machine Learning Model Validation (Aijun Zhang 2024).pdf
Machine Learning Model Validation (Aijun Zhang 2024).pdfMachine Learning Model Validation (Aijun Zhang 2024).pdf
Machine Learning Model Validation (Aijun Zhang 2024).pdfAijun Zhang
 
Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™Adtran
 
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdfIaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdfDaniel Santiago Silva Capera
 
Computer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsComputer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsSeth Reyes
 
Empowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership BlueprintEmpowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership BlueprintMahmoud Rabie
 
COMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online CollaborationCOMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online Collaborationbruanjhuli
 
UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1DianaGray10
 

Último (20)

201610817 - edge part1
201610817 - edge part1201610817 - edge part1
201610817 - edge part1
 
NIST Cybersecurity Framework (CSF) 2.0 Workshop
NIST Cybersecurity Framework (CSF) 2.0 WorkshopNIST Cybersecurity Framework (CSF) 2.0 Workshop
NIST Cybersecurity Framework (CSF) 2.0 Workshop
 
COMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a WebsiteCOMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a Website
 
UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7
 
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
 
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve DecarbonizationUsing IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
 
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostKubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
 
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
UWB Technology for Enhanced Indoor and Outdoor Positioning in Physiological M...
 
UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6UiPath Studio Web workshop series - Day 6
UiPath Studio Web workshop series - Day 6
 
20150722 - AGV
20150722 - AGV20150722 - AGV
20150722 - AGV
 
Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.
 
UiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation DevelopersUiPath Community: AI for UiPath Automation Developers
UiPath Community: AI for UiPath Automation Developers
 
Machine Learning Model Validation (Aijun Zhang 2024).pdf
Machine Learning Model Validation (Aijun Zhang 2024).pdfMachine Learning Model Validation (Aijun Zhang 2024).pdf
Machine Learning Model Validation (Aijun Zhang 2024).pdf
 
Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™
 
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdfIaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
 
Computer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsComputer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and Hazards
 
Empowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership BlueprintEmpowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership Blueprint
 
COMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online CollaborationCOMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online Collaboration
 
UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1
 
20230104 - machine vision
20230104 - machine vision20230104 - machine vision
20230104 - machine vision
 

Agile Software Development

  • 1. agile @ enterprise Adnan Masood Sr. Software Architect / Doctoral Candidate scis.nova.edu/~adnan adnan.masood@owasp.org
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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