1© Life Cycle Engineering 2014© Life Cycle Engineering 2014
Agile Lunch and Learn Series
Introduction to Agility
2© Life Cycle Engineering 2014
• 4+ years adapting and
applying Agile and Scrum to
SPAWAR projects
• Scrum Alliance Certified
Scrum Master (CSM)
• Scrum Alliance Certified
Scrum Professional (CSP)
• PMI – Agile Certified
Practitioner (PMI-ACP)
jpetite@lce.com
@JustinPetite
JUSTIN PETITE
3© Life Cycle Engineering 2014
Agile.
We need to be Agile.
Why are we not doing Agile?
4© Life Cycle Engineering 2014
AGILE
An iterative and incremental (evolutionary) approach
to software development which is performed in a
highly collaborative manner by self-organizing teams
within an effective governance framework with “just
enough” ceremony that produces high quality
software in a cost effective and timely manner which
meets the changing needs of its stakeholders.
Scott Ambler
http://www.agilemodeling.com/essays/agileSoftwareDevelopment.htm
5© Life Cycle Engineering 2014
WHY AGILITY
• Need to more effectively respond to change
– Organizational needs
– Market demands
– Threats and opportunities
• Manage evolutionary change to culture,
products, and processes
• Frequently and incrementally deliver value to
reach a desired goal or outcome
6© Life Cycle Engineering 2014
AGILITY
Agility is the ability to both create and respond
to change in order to profit in a turbulent
business environment
Agility is the ability to balance flexibility
and stability
Jim Highsmith
Agile Project Management (2nd Edition, 2010)
7© Life Cycle Engineering 2014
BENEFITS
• Greater responsiveness
• Measured increase in productivity
• Lower costs
• Managed risk through greater visibility
• Increased customer satisfaction
• Better overall quality
• Improved team morale
8© Life Cycle Engineering 2014
AGILITY
9© Life Cycle Engineering 2014
MANIFESTO FOR AGILE
SOFTWARE DEVELOPMENT
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
10© Life Cycle Engineering 2014
AGILE PRINCIPLES
1. Our highest priority is to
satisfy the customer through
early and continuous delivery
of valuable software.
2. Welcome changing
requirements, even late in
development. Agile
processes harness change
for the customer's
competitive advantage.
3. Deliver working software
frequently, from a couple of
weeks to a couple of months,
with a preference to the
shorter timescale.
4. Business people and
developers must work
together daily throughout the
project.
5. Build projects around
motivated individuals. Give
them the environment and
support they need, and trust
them to get the job done.
6. The most efficient and
effective method of
conveying information to and
within a development team is
face-to-face conversation.
11© Life Cycle Engineering 2014
AGILE PRINCIPLES
7. Working software is the
primary measure of
progress.
8. Agile processes promote
sustainable development.
The sponsors,
developers, and users
should be able to
maintain a constant pace
indefinitely.
9. Continuous attention to
technical excellence and
good design enhances
agility.
10. Simplicity—the art of
maximizing the amount of
work not done—is
essential.
11. The best architectures,
requirements, and
designs emerge from self-
organizing teams.
12. At regular intervals, the
team reflects on how to
become more effective,
then tunes and adjusts its
behavior accordingly
12© Life Cycle Engineering 2014
AGILE PRACTICES
13© Life Cycle Engineering 2014
Accredited to Michael Sahota & Olaf Lewitz
14© Life Cycle Engineering 2014
ETHOS
Plan-driven
Focus on documenting &
predicting outcomes
Lauds deadlines & output
Longer product cycle time
Change is hard
Value-driven
Focus on understanding &
executing priorities
Lauds priorities & throughput
Shorter product cycle time
Embraces change
Traditional Agile
15© Life Cycle Engineering 2014
ETHOS
16© Life Cycle Engineering 2014
Value
(Releasable Product)
Quality
(Reliable, Adaptable Product)
Constraints
(Scope, Cost, Schedule)
AGILE TRIANGLE
Jim Highsmith
17© Life Cycle Engineering 2014
DO’S AND DON’TS
Agile methods do:
• Position us to be more responsive to changing
priorities
• Allow better predictability of output for the
foreseeable time horizon
• Improve accountability
• Make priorities and risk calculations more
transparent
18© Life Cycle Engineering 2014
DO’S AND DON’TS
Agile methods don’t:
• Make engineers write more lines of code per
day or designers create output faster
• Preclude the need to make good organizational
decisions about product, priorities, and
customer needs
• Allow the rest of the organization to assume
they think they know what lies months ahead
19© Life Cycle Engineering 2014
AGILE MYTHS
• “Agile is the silver bullet for our organization!”
• “Agile doesn’t scale, so it can’t work for our
organization!”
• “No more documentation or deadlines!”
• “Since we don’t do things upfront, we have no
design and poor architecture!”
• “With so much rework going on, nothing new, and
innovative gets worked on!”
• “Agile makes us faster!”
20© Life Cycle Engineering 2014
ORGANIZATIONAL AGILITY
• More than just “doing Agile”
• Discipline of managed change through continuous
inspection, evaluation, and adaptation
• Tailored to the organization
• Leverages Agile methods appropriately at each level:
– Individual
– Team
– Project
– Program/Portfolio
– Executive
21© Life Cycle Engineering 2014
22© Life Cycle Engineering 2014
ITERATIVE & INCREMENTAL
“Incrementing” builds a finished piece
Assumes the customer
has a fully formed idea
of what they need
Jeff Patton - 2008
http://www.agileproductdesign.com/blog/dont_
know_what_i_want.html
23© Life Cycle Engineering 2014
ITERATIVE & INCREMENTAL
Jeff Patton - 2008
http://www.agileproductdesign.com/blog/dont_
know_what_i_want.html
“Iterating” builds something imperfect to validate and refine
Iterating allows for less
developed ideas to
evolve and be refined
24© Life Cycle Engineering 2014
25© Life Cycle Engineering 2014
STORY MAPPING
26© Life Cycle Engineering 2014
USER STORY
• High-level requirement artifact:
– Incremental
– Negotiable
– Valuable
– Estimable
– Small
– Testable
• A conversation with the stakeholder:
– “As a” specific user or persona
– “I want” need, feature, or functionality
– “So (that)” purpose and value of delivery
27© Life Cycle Engineering 2014
ACCEPTANCE CRITERIA
• Flip the card over to record expectations:
–User
–Customer
–Product Owner
–Team
How has the customer defined success for this story?
28© Life Cycle Engineering 2014
PRODUCT BACKLOG
29© Life Cycle Engineering 2014
SCRUM
• Framework:
– Defined Roles
– Ritual Meetings
– Artifacts
– Terminology
• Emphasis:
– Value
– Delivery
– Open communication
– Team self-organization
– Stakeholder Participation
30© Life Cycle Engineering 2014
SCRUM ROLES
• Scrum Master
– Lead, promote, facilitate, organize, and coach Scrum
– Remove impediments for the team
• Product Owner
– Own, manage, and communicate the Product Backlog
– Advocate for the customer
• Scrum Team
– Turn work from the backlog into a “potentially
shippable” increment of working software
31© Life Cycle Engineering 2014
SCRUM TIMEBOXES
• Release Planning
• Sprint Planning
• The Sprint
• Daily Scrum
• Sprint Review & Demo
• Sprint Retrospective
32© Life Cycle Engineering 2014
PROJECT INITIATION
Decompose project requirements (scope) to
create the first iteration of the project
schedule, roadmap, and backlog
Form the cross-functional agile team(s) of
individuals with the roles and skills necessary to
deliver on the project’s requirements
Train the team, educate the customer,
and communicate expectations
Get started sprinting following the standard practices
to learn how to best adapt in the future
· Incorporate feedback from retrospectives
· Build “muscle memory” around good practices
· Establish common understanding of
Agile fundamentals
· Agree to a cadence
· Decide on initial technologies
· Identify and negotiate stakeholder
roles and responsibilities
· Agree to the metrics by which project
performance will be measured
· Establish the definition of done
· Set up visible progress indicators
Work
Breakdown
Structure
IMS /
Roadmap
Agile PM Tool
User StoriesUser Stories
Systems
Requirements
Document
(SRD)
Systems
Requirements
Document
(SRD)
PWS/CDRLPWS/CDRL
Product OwnerProduct Owner
TestersTestersDevelopersDevelopers
Scrum MasterScrum Master
33© Life Cycle Engineering 2014
KEEP THE AGILE CONVERSATION GOING
• Software engineering
practices
• Agile team dynamics
• Scaling up
• Contracting and
government
• Metrics
• Planning
• User story writing
• Testing/Quality
• Retrospectives
• Configuration management
• Release management
• Information assurance
• Fostering culture
• Organizational transition
• Change management
• Industry certifications
• Management and executive
sponsorship
• More than software
34© Life Cycle Engineering 2014
Agile Methodologies
35© Life Cycle Engineering 2014
36© Life Cycle Engineering 2014
THANK YOU!
Please let me know how I can do better next time!
jpetite@lce.com
@JustinPetite

Introduction to Agile Software Development

  • 1.
    1© Life CycleEngineering 2014© Life Cycle Engineering 2014 Agile Lunch and Learn Series Introduction to Agility
  • 2.
    2© Life CycleEngineering 2014 • 4+ years adapting and applying Agile and Scrum to SPAWAR projects • Scrum Alliance Certified Scrum Master (CSM) • Scrum Alliance Certified Scrum Professional (CSP) • PMI – Agile Certified Practitioner (PMI-ACP) jpetite@lce.com @JustinPetite JUSTIN PETITE
  • 3.
    3© Life CycleEngineering 2014 Agile. We need to be Agile. Why are we not doing Agile?
  • 4.
    4© Life CycleEngineering 2014 AGILE An iterative and incremental (evolutionary) approach to software development which is performed in a highly collaborative manner by self-organizing teams within an effective governance framework with “just enough” ceremony that produces high quality software in a cost effective and timely manner which meets the changing needs of its stakeholders. Scott Ambler http://www.agilemodeling.com/essays/agileSoftwareDevelopment.htm
  • 5.
    5© Life CycleEngineering 2014 WHY AGILITY • Need to more effectively respond to change – Organizational needs – Market demands – Threats and opportunities • Manage evolutionary change to culture, products, and processes • Frequently and incrementally deliver value to reach a desired goal or outcome
  • 6.
    6© Life CycleEngineering 2014 AGILITY Agility is the ability to both create and respond to change in order to profit in a turbulent business environment Agility is the ability to balance flexibility and stability Jim Highsmith Agile Project Management (2nd Edition, 2010)
  • 7.
    7© Life CycleEngineering 2014 BENEFITS • Greater responsiveness • Measured increase in productivity • Lower costs • Managed risk through greater visibility • Increased customer satisfaction • Better overall quality • Improved team morale
  • 8.
    8© Life CycleEngineering 2014 AGILITY
  • 9.
    9© Life CycleEngineering 2014 MANIFESTO FOR AGILE SOFTWARE DEVELOPMENT We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.
  • 10.
    10© Life CycleEngineering 2014 AGILE PRINCIPLES 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  • 11.
    11© Life CycleEngineering 2014 AGILE PRINCIPLES 7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicity—the art of maximizing the amount of work not done—is essential. 11. The best architectures, requirements, and designs emerge from self- organizing teams. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly
  • 12.
    12© Life CycleEngineering 2014 AGILE PRACTICES
  • 13.
    13© Life CycleEngineering 2014 Accredited to Michael Sahota & Olaf Lewitz
  • 14.
    14© Life CycleEngineering 2014 ETHOS Plan-driven Focus on documenting & predicting outcomes Lauds deadlines & output Longer product cycle time Change is hard Value-driven Focus on understanding & executing priorities Lauds priorities & throughput Shorter product cycle time Embraces change Traditional Agile
  • 15.
    15© Life CycleEngineering 2014 ETHOS
  • 16.
    16© Life CycleEngineering 2014 Value (Releasable Product) Quality (Reliable, Adaptable Product) Constraints (Scope, Cost, Schedule) AGILE TRIANGLE Jim Highsmith
  • 17.
    17© Life CycleEngineering 2014 DO’S AND DON’TS Agile methods do: • Position us to be more responsive to changing priorities • Allow better predictability of output for the foreseeable time horizon • Improve accountability • Make priorities and risk calculations more transparent
  • 18.
    18© Life CycleEngineering 2014 DO’S AND DON’TS Agile methods don’t: • Make engineers write more lines of code per day or designers create output faster • Preclude the need to make good organizational decisions about product, priorities, and customer needs • Allow the rest of the organization to assume they think they know what lies months ahead
  • 19.
    19© Life CycleEngineering 2014 AGILE MYTHS • “Agile is the silver bullet for our organization!” • “Agile doesn’t scale, so it can’t work for our organization!” • “No more documentation or deadlines!” • “Since we don’t do things upfront, we have no design and poor architecture!” • “With so much rework going on, nothing new, and innovative gets worked on!” • “Agile makes us faster!”
  • 20.
    20© Life CycleEngineering 2014 ORGANIZATIONAL AGILITY • More than just “doing Agile” • Discipline of managed change through continuous inspection, evaluation, and adaptation • Tailored to the organization • Leverages Agile methods appropriately at each level: – Individual – Team – Project – Program/Portfolio – Executive
  • 21.
    21© Life CycleEngineering 2014
  • 22.
    22© Life CycleEngineering 2014 ITERATIVE & INCREMENTAL “Incrementing” builds a finished piece Assumes the customer has a fully formed idea of what they need Jeff Patton - 2008 http://www.agileproductdesign.com/blog/dont_ know_what_i_want.html
  • 23.
    23© Life CycleEngineering 2014 ITERATIVE & INCREMENTAL Jeff Patton - 2008 http://www.agileproductdesign.com/blog/dont_ know_what_i_want.html “Iterating” builds something imperfect to validate and refine Iterating allows for less developed ideas to evolve and be refined
  • 24.
    24© Life CycleEngineering 2014
  • 25.
    25© Life CycleEngineering 2014 STORY MAPPING
  • 26.
    26© Life CycleEngineering 2014 USER STORY • High-level requirement artifact: – Incremental – Negotiable – Valuable – Estimable – Small – Testable • A conversation with the stakeholder: – “As a” specific user or persona – “I want” need, feature, or functionality – “So (that)” purpose and value of delivery
  • 27.
    27© Life CycleEngineering 2014 ACCEPTANCE CRITERIA • Flip the card over to record expectations: –User –Customer –Product Owner –Team How has the customer defined success for this story?
  • 28.
    28© Life CycleEngineering 2014 PRODUCT BACKLOG
  • 29.
    29© Life CycleEngineering 2014 SCRUM • Framework: – Defined Roles – Ritual Meetings – Artifacts – Terminology • Emphasis: – Value – Delivery – Open communication – Team self-organization – Stakeholder Participation
  • 30.
    30© Life CycleEngineering 2014 SCRUM ROLES • Scrum Master – Lead, promote, facilitate, organize, and coach Scrum – Remove impediments for the team • Product Owner – Own, manage, and communicate the Product Backlog – Advocate for the customer • Scrum Team – Turn work from the backlog into a “potentially shippable” increment of working software
  • 31.
    31© Life CycleEngineering 2014 SCRUM TIMEBOXES • Release Planning • Sprint Planning • The Sprint • Daily Scrum • Sprint Review & Demo • Sprint Retrospective
  • 32.
    32© Life CycleEngineering 2014 PROJECT INITIATION Decompose project requirements (scope) to create the first iteration of the project schedule, roadmap, and backlog Form the cross-functional agile team(s) of individuals with the roles and skills necessary to deliver on the project’s requirements Train the team, educate the customer, and communicate expectations Get started sprinting following the standard practices to learn how to best adapt in the future · Incorporate feedback from retrospectives · Build “muscle memory” around good practices · Establish common understanding of Agile fundamentals · Agree to a cadence · Decide on initial technologies · Identify and negotiate stakeholder roles and responsibilities · Agree to the metrics by which project performance will be measured · Establish the definition of done · Set up visible progress indicators Work Breakdown Structure IMS / Roadmap Agile PM Tool User StoriesUser Stories Systems Requirements Document (SRD) Systems Requirements Document (SRD) PWS/CDRLPWS/CDRL Product OwnerProduct Owner TestersTestersDevelopersDevelopers Scrum MasterScrum Master
  • 33.
    33© Life CycleEngineering 2014 KEEP THE AGILE CONVERSATION GOING • Software engineering practices • Agile team dynamics • Scaling up • Contracting and government • Metrics • Planning • User story writing • Testing/Quality • Retrospectives • Configuration management • Release management • Information assurance • Fostering culture • Organizational transition • Change management • Industry certifications • Management and executive sponsorship • More than software
  • 34.
    34© Life CycleEngineering 2014 Agile Methodologies
  • 35.
    35© Life CycleEngineering 2014
  • 36.
    36© Life CycleEngineering 2014 THANK YOU! Please let me know how I can do better next time! jpetite@lce.com @JustinPetite