Agile Software and Systems Engineering Tutorial

Agile Software and Systems Engineering Tutorial

Systems and Software Technology ConferenceSalt Lake City, UT

Dr Suzette S Johnson

April 2010

John O Clark Dr. Suzette S. JohnsonAgile Engineering

Northrop GrummanBaltimore, MD

Suzette Johnson@ngc com

John O. ClarkChief EngineerNorthrop GrummanVirginia Beach, VA

Copyright 2010 Northrop Grumman Corporation

[email protected]

Agenda

• Defining an Agile Environment• Creating the Teamg• High-Level Agile Steps

– Capabilities Description and Release Planning– Iteration Planning– Iteration Execution– Iteration Demonstration and Retrospective– Iteration Demonstration and Retrospective– Delivery

• Some Final Notes• The Great Challenges• Agile Reading List

Copyright 2009 Northrop Grumman CorporationCopyright 2010 Northrop Grumman Corporation2

g g

Today’s Outcomes

• Develop an understanding of the major agile engineering practices

Pa ticipate in a planning and estimating scena io• Participate in a planning and estimating scenario

• Gain insight into agile testing practices from a couple practitioners

P ti i t i t t ti• Participate in a team retrospective

• Have fun working together!


Agenda





g g

The Need for ChangeT diti l V Ad ti B i M d lTraditional Versus Adaptive Business Model

I d t i l AI d t i l A K l d AK l d AIndustrial Age Industrial Age Inspect and Adapt

Knowledge Age Knowledge Age Repeatable and Predictable


The Knowledge Worker…

Copyright 2009 Northrop Grumman CorporationCopyright 2010 Northrop Grumman Corporation

Agile Engineering

What is Agile Engineering? Why Agile Practices?

• Includes the entire product life cycle

• Impacts the entire organization

• Quick reaction capabilities

• Adapt to change • Impacts the entire organization

• Inspects and adapts

• Focuses on the value stream

• Shortened product life cycle

• New technological advancementsFocuses on the value stream advancements

• Improved transparency of progress and end-to-end accountability and ownershipaccountability and ownership


Agile Methods

Agile is about how we believe people are best motivated to do work and about demonstrating high value on a regular basis particularly in

environments that face high requirement volatility and unpredictabilityenvironments that face high requirement volatility and unpredictability.

Agile Methods

Scrum

Dynamic Systems D l t M th d

Adaptive Software Design

Extreme Programming

Development Methods

Crystal Methods Agile Unified

Process

Feature Driven Development

Design


What is your level of experience?

Scale of 1 to 5


Agile Principles

Early and Continuous Delivery of Value

A Working System is the Primary Measure

of Progress

Welcome Changing Requirementsg

Deliver a Working Business People and Motivated and Deliver a Working System Frequently

pDevelopers Must Work

Together DailyEmpowered Individuals

Face-to-face Conversation

Promote Sustainable Development

Continuous Attention to Technical Excellence

Simplicity

The Best Architectures,

Requirements and

Regular Team Reflection on How to

Copyright 2009 Northrop Grumman CorporationCopyright 2010 Northrop Grumman Corporation10 10

Simplicity Requirements and Designs Emerge From Self-Organizing Teams

Become More Effective

http://agilemanifesto.org/

Agile Manifesto

Is valued more thanIndividuals and interactions Processes and tools

A working systems Comprehensive documentationIs valued more than

Customer collaboration Controlled negotiationIs valued more than

l dResponding to change Following a planIs valued more than

That is, while there is value in the items on the right,


we value the items on the left more http://agilemanifesto.org/

Agile Misconceptions

• There is no discipline within an Agile Process– False. A true Agile Process requires more discipline.

• Agile is only for software development• Agile is only for software development– False. Implementing Agile practices require culture change at all levels. Adapt to

and embrace change vs. trying to anticipate the future.

• The solution to any problem is more processThe solution to any problem is more process– False. Too much process stifles innovation and results in endless workarounds.

• Agile is only for small sized software efforts– False. Agile practices have been growing to the enterprise level. Project sizes ofFalse. Agile practices have been growing to the enterprise level. Project sizes of

200 – 600 people are common.

• Agile is “turn-key”– False. The transition from traditional to Agile will take timeg– An Agile process is agile and will continually change over time– The greatest challenge is culture and fear of change.


Agile Terminology

Term Definition

Iteration Fixed time-box in which development occurs

Product Backlog Requirements/User Stories to be completed

Product Burn Down Chart Progress for the release; Focuses on the remaining user storyProduct Burn Down Chart Progress for the release; Focuses on the remaining user story points

Product Owner Owns the product backlog, assigns priority to user stories

Release Usually a 2 – 6 month timeframe; formal committed delivery of product

Scrum Master Helps the agile team through the process and removes i diimpediments

The Team Cross functional team

User Story Similar to a requirement


User Story Similar to a requirement“As a user I want what so that purpose”

13

Introduction to Four Popular Agile Practices

• Agile Unified Process (AUP)– Scott Ambler, Craig Larman– http://www.ambysoft.com/

• Feature Driven Development (FDD)– Jeff De Luca, Jim Highsmith

• Extreme Programming (XP)– Kent Beck, Ward Cunningham, Ron Jeffries

• Scrum– Ken Schwaber, Jeff Sutherland– www.controlchaos.com– www.mountaingoatsoftware.com


ou ta goatso t a e co

What is “Scrum”?


Picture from www.ricerugbyclub.com

Scrum Core Practices

• 2 or 4 week Sprints (Iterations)• Self-directed and self-organizing

( / )

• Don’t add to iteration• Scrum master firewall

teams (7 +/- 2)• Cross functional teams • Daily Scrum meetings

• Time boxing• Impediments gone in one day• No specific engineering y g o spe e g ee g

practices defined• Product Backlog• Release and iteration planning• Release and iteration planning• Product Burndown• Demonstrations and

RetrospectiveRetrospective


Scrum Framework (Cohn, 2005)

Extreme Programming (XP) Core Practices

• Planning game• Small, frequent releases

• Pair programming• Team code ownership

• System metaphors• Simple design• Testing

• Continuous integration• Sustainable pace• Whole team together• Testing

• Frequent refactoring• Coding standards


XP Core Practices (Lindstrom & Jeffries, 2004, p. 46)

What Methods Are Being Used?

Method PercentageScrum 49.1%Scrum/XP Hybrid 22.3%Extreme Programming 8.0%Custom/Hybrid 5.3%Don't Know 3.7%Agile Unified Process 2.2%Other 2.2%

Feature Driven Development (FDD) 2.1%Lean Development 1.9%Dynamic Systems Development Method (DSDM) 1.4%OpenUP 0.6%Agile Modeling 0.6%Crystal 0.5%

Research Conducted by:VersionOne

Summer 2008


2,319 completed responses representing 80 countries

Agile System Development Lifecycle

(Stories)

Iteration review &

demonstration to

Release system(Sto es)

(Stories)stakeholders; Retrospectives

(Stories)


Reference: http://www.ddj.com/architect/207100381;jsessionid=R1I5M44B21UPGQSNDLPSKHSCJUNN2JVN?pgno=2

Dr. Dobb’s Journal/Scott Ambler

Iteration 0: Project Start up

• Start building the team.– Begin with at least one or two senior developers, the Scrum Master and Product

Owner and one or more stakeholder representativesOwner and one or more stakeholder representatives.– Training

• Modeling an initial architecture for the system.– You need to have at least a general idea of how you're going to build the system.– Identify an architectural strategy. Work through the design details later during future

iterations in model sessions. – Every iteration must deliver at least some piece of business functionalityEvery iteration must deliver at least some piece of business functionality

• Setting up the environment.– You need workstations, development tools, and a work areas. Start with just enough

to get the team going and continue to build on this in future releasesto get the team going and continue to build on this in future releases.

• Determine first release date and iteration length


Agenda





g g

The Agile Team Based on Scrum

• Product Owner, ScrumMaster, Team

• Systems Engineers

• Hardware EngineersHardware Engineers

• Integration and Test Team

• Program Management

• Stakeholders including customers

Create a workplace where people want to be, where people are valued, and are full contributors to f i d ti th di ti f th


forming and supporting the direction of the company

Product Owner

• Defines the features of the product

• Manages project features and release to optimize• Manages project features and release to optimize return on investment (ROI)

• Prioritizes features according to market value Product Prioritizes features according to market value

• Inspects increment and makes adaptations to project

Communicates project progress and status

Back-log

• Communicates project progress and status

• Accepts or rejects work results

Copyright 2009 Northrop Grumman CorporationCopyright 2010 Northrop Grumman Corporation23 Reference: www.mountaingoatsoftware.com

The ScrumMaster

• Represents management

• Responsible for enacting Scrum values and practices• Responsible for enacting Scrum values and practices

• Removes impediments

• Ensures that the team is fully functional and productive

• E bl l ti ll l d• Enables close cooperation across all roles and functions

• Shields the team from external interferences• Shields the team from external interferences

• Ensures that the process is followed


• Teaches Product Owner and Team how to fulfill their roles

Reference: www.mountaingoatsoftware.com

The Team

• Typically 5-9 people• Cross-functional:

• P ifi i d i• Programmers, verifiers, user experience designers, etc.

• Members should be full-time• T lf i i• Teams are self-organizing

• Ideally, no titles (but rarely a possibility)• Should change only between iterations

S l t th it ti l d ifi k lt• Selects the iteration goal and specifies work results• Commits to what it feels it can accomplish• Has authority to do everything within existing standards

d id li t h th it ti land guidelines to reach the iteration goal• Manages itself and its work• Collaborates with Product Owner to optimize value


• Demonstrates work results to the Product Owner

Reference: www.mountaingoatsoftware.com

Self-organizing, Self-managing Teams

• Team organizes around the work that needs to be done.

M t id th l ti f b h i th t• Management guides the evolution of behaviors that emerge from the interactions.

• Self organization does not mean people get to do whatever• Self-organization does not mean people get to do whatever they want.

• The team works to solve their own problems Management• The team works to solve their own problems. Management does not solve problems for the teams.


Expectations of Managers

• Focuses on resolving organizational problems and larger program issues

• Establishes check points

• Manages uncertainty via iterative development

• Manages complexity via empowered teams

• Creates and communicates visionCreates and communicates vision

• Enables communication

• Promotes constant improvement

• Establishes governance teams

• Participates in agile “ceremonies”– Team planning sessions, Demonstrations, Retrospectives

• Builds trust

• Motivates and encourages

S th l d i di t


• Serves the people and removes impediments

• Manages contractual details

Expectations of the Customer

• Identifies needs/capabilities

Pa ticipates in setting p io ities• Participates in setting priorities– We ask “Is what we are doing useful to you in meeting your

goals?”

• Participates in demonstrations of functionality

• Provides feedback and engages in dialogue about requirements and t tiexpectations


Project Team Structure

Transition from functional grouping to cross functional teams

PM and Technical Lead

Chief EngineerChief Architect

Quality

Infrastructure T

Hardware T

Software T

Systems E i

Integration d T t

Configuration M t

Quality

Team Team Team Engineers and Test Management

Lead TM

TM TM

Lead TM

TM TM

Lead TM

TM TM

Lead TM

TM TM

Lead TM

TM TM

Lead TM

TM TM

Isolated progress with too many hand-offs and barriers


Isolated progress with too many hand offs and barriers


Chief EngineerChief ArchitectQuality

Progress against d t d


end-to-end capabilitiesCapabilities or

Threads

Cross Functional Team 1



Cross Functional Team n

Services

Network/ Systems Administration

Supports Cross Functional Teams

• Push accountability and ownership to the team


Configuration Mgt.An Example

plevel

• Everyone trained


Chief EngineerChief ArchitectQuality

Progress against d t d


end-to-end capabilitiesCapabilities or

Threads


ProductOwner

Scrum Master Developer


Cross Functional

Developer Integrator Configuration Management

Team 3

Cross Functional Team n

Tester Systems Engineer

Developer

Services

Network/ Systems Administration

Supports Cross Functional Teams

• Push accountability and ownership to the team


Configuration Mgt.An Example

plevel

• Everyone trained

Today’s Scenario: RestEZ

Online hotel reservation system for RestEZBased on customer needs your team has defined a logicalBased on customer needs, your team has defined a logical architecture for the online hotel reservation system. The system is a traditional 3 tier architecture:

a database layer (to persist reservations),

a business logic layer (to manage reservations),a business logic layer (to manage reservations),

and a browser-based user interface (to receive customer

input)input).


TekTalk: Roles and Responsibilities

• Reflecting on the section Creating the Team and the given scenario address the following:– With your team, identify the team members and roles. You will need a y , y

product owner, scrum master, and team members. Keep in mind the need for cross-functional teams

– Identify your responsibilities

• Team discussion: Whose responsibility?– The Product Owner is micromanaging the team making self-managing

impossible.The team is struggling to understand the priorities of the work– The team is struggling to understand the priorities of the work.

– A team member is constantly late for the daily standup.– The team is not able to deliver on their commitments.

• Create a team name


Time: 15 minutes

CheckPointCheckPoint• What we’ve covered so far

• Questions

H d i ?• How are we doing?


Time: 5 minutes

Agenda





g g

Levels of Planning

Vision, Product Roadmap, Release, Iteration, DailyVision, Product Roadmap, Release, Iteration, Daily

Iteration 1

Product Backlog(prioritized

requirements by

~2 - 6 months

~2 – 4 weeks fixed

Product

requirements by business value) Release 1 Story

Story

Task

Story

TaskTaskTaskGoals &User Stories

Daily Stand

Up

Vision

Roadmap

Iteration n

Iteration 3

Iteration 2

Customer NeedsIteration n…


High Level Agile Stages

Product Roadmap

Iteration Planning

Iteration Execution

VisionCustomer

Needs

Release Planning

Iteration Demo and

RetrospectiveDelivery


Product Roadmap

Release 1Room reservations

and paymentUser profiles for

future visitsRelease 2Conference

offeringsOnline chat

supportRelease 3Release 3

Special discountsLocal information

Release 4Google maps


38


Product Roadmap

Iteration Planning

Iteration Execution

VisionCustomer

Needs

Release Planning

Iteration Demo and



Agile Keywords & Phrases

- An Agile Program can consist of multiple, semi-independent Projects- Each Project consists of one or more Releases- Each Delivery (Release) consists of one or more Iterations

Each Iteration consists of one or more Stories

Iteration 11 … n

- Each Iteration consists of one or more Stories- Each Story consists of Tasks

Project

Release 1

Release 2

Iteration 2Iteration n

1 … nStory 1Story 2Story n

1 … n

Task 1

Task 2T k 3

1 … n

Release n-2-9 months-Cost AccountingHere

-2 or 4weeks- Fixed time-Could be

e.g., a Web service-Customer Capability-Measures work size

Task 3

-Technical reviews, implement-

-2 weeks for projects in O&M

delivered-Checkpoint with Customer

work size (points), risk-Progress = points / day = velocity

implementation, verification, document-ation, etc.


Deliver working functionality every iterationOriginal creator: David Mooney, NGIS

Define the Release and Iteration CycleProduct

RoadmapIteration Planning

Iteration Demo and

Retrospective

Iteration Execution

Delivery

VisionCustomer

Needs

Release Planning

3 Month Release Cycle3 Month Release Cycle

1/04/10 3/31/10Planning started in Dec.

Iteration Iteration Iteration Iteration Iteration Iteration

in Dec.

1 2 3 4 5 6Formal

release/Delivery

Day 1Day 1A.M. = Release Planning MtgP.M. = Iteration1 Planning Mtg

End of Each End of Each IterationIteration

RetrospectiveDemonstration and

ReviewPotentially releasable

Day 1 of Each Day 1 of Each IterationIteration

Iteration Planning Meeting

2-4 hours


Potentially releasable

Create the Product Backlog

• A list of all desired work on the project

• Ideally expressed such that each item has value to the users or customers of

Product Roadmap

Iteration Planning

Iteration Demo and

Retrospective

Iteration Execution

Delivery

VisionCustomer

Needs

Release Planning

has value to the users or customers of the product

• Prioritized by the product owner

80 A ti I t t h

Business value

Product VisionProduct VisionCustomer Customer NeedsNeeds 80 As a vacationer, I want to search room

availability…

70 As a vacationer, I want to change my reservation

NeedsNeeds

reservation…

60 As a vacationer, I want to cancel my reservation…

50 A i I i h di


50 As a vacationer, I want to pay with a credit card…

Release Planning

Planning for the ReleaseRelease Planning

High-Level Requirements

High Level Design, Use CasesD fi d d bili

Begin prior to the start of the release

Systems architecture

VisionProduct Roadmap

Mission Needs(Government)

Identify Capabilities from the Product Backlog

GovernmentGovernment Systems EngineersSystems Engineers

Define end-to-end capability tests Systems engineering

High level requirements mapped to end-to-end

capabilities and stories.

(Government)

User StoriesWritten at a level that the team can

complete in one iterationOwned by the Product OwnerProduct Owner

Release Planning Meeting

Six two-week iterations

Owned by the Product OwnerProduct OwnerUser Story updatesAcceptance Criteria

EstimatesCommit

The Release PlanWhole TeamWhole Team

Select stories for the iteration

The Team defines the tasks for each story and the estimated hours for completion based upon a

definition of done

Supported by the Scrum Master


Formal System of Systems definition of done

Design – Code/Build – Unit Verification –Integration and Component Verification

yIntegration

and Verification at

the end of each iteration

SE tasks are included as a task in a given story Not a

handoff


Iteration Demonstration and Retrospective (e.g., DT&E)

handoff

Planning the Release

Product: Hotel Website for RestEZ

Use Case Flow: Make Room Reservations

Product Roadmap

Iteration Planning

Iteration Demo and

Retrospective

Iteration Execution

Delivery

VisionCustomer

Needs

Release Planning

Story Points

Business Value

User Stories

80 As a vacationer, I want to search room availability…

Test

Objective

12

70 As a vacationer, I Test 8The Release PlanWh t i l it ?want to save my

request… Objective


• Test with Visa

• Test with AmEx

16

What is our velocity?How many story points can we commit to?

credit card…

• Test 3…..

Owned by the Project Manager with the

i


opportunity to reprioritize each

iteration

Velocity (Based on history)

• Velocity is the amount of work a development team completes in an iteration (story points completed)

Product Roadmap

Iteration Planning

Iteration Demo and

Retrospective

Iteration Execution

Delivery

VisionCustomer

Needs

Release Planning

completed)

• Velocity is a range; Look for the high, the low, and the mean.

Velocity for Team A Project Velocity

25

30

35

40

45

Velocity for Team A

80

100

120

140

160

S P i

Project Velocity

0

5

10

15

20

1 2 3 4 5 6 7

Iteration

0

20

40

60

80Story Points

1 2 3 4 5 6 7

Project Velocity per Iteration

Team A Velocity

High: 45 story points

Low: 30 story points


High: 155 story points

Low: 120 story points


Mean: 37 story points Mean: 137 story points

Release Planning Meeting

• Meeting is time-boxed

• Usually 1 day depending on length of the release

Product Roadmap

Iteration Planning

Iteration Demo and

Retrospective

Iteration Execution

Delivery

VisionCustomer

Needs

Release Planning

of the release

• Occurs with the entire project team

INPUTStories with

OUTPUT

Release

Planning

Product Backlog

Business Value

Technology

Stories with Relative Effort

Stories with Acceptance g

MeetingCurrent Product

Velocity

Criteria

Stories Accepted for the Release


Commit to the Release Plan

• Capabilities/Goals identified

• High level requirements and initial user stories d

Product Roadmap

Iteration Planning

Iteration Demo and

Retrospective

Iteration Execution

Delivery

VisionCustomer

Needs

Release Planning

mapped

• User stories (functional and non-functional requirements)

Ex : Project Teams average about 137 user 35

40

45

Velocity for Team A

– Ex.: Project Teams average about 137 user story points per iteration; for a release with 6 iterations this is about 900 story points. The scope is 720-930 user story points of work.

f0

5

10

15

20

25

30

35

– Total number of user stories planned (125)

• Dependencies identified

• Known or assumed velocity by development team

01 2 3 4 5 6 7

Iteration

Project Velocity y y pand project team

• Total number of user stories planned

• Planned hours (WBS element)60

80

100

120

140

160

Story Points


• Planned hours (WBS element)0

20

40

1 2 3 4 5 6 7


User Stories

What is a User Story?

• Functional stories

Product Roadmap

Iteration Planning

Iteration Demo and

Retrospective

Iteration Execution

Delivery

VisionCustomer

Needs

Release Planning

u c o a s o es– often based off a scenario of a

use case– On large projects a user can be

another system

Estimation (2 options)

• Story Pointsanother system

• Non-functional stories

• Definition of Done

– Bigness of the task– Considers: complexity, uncertainty,

effortDefinition of Done– Design, Write tests, code, unit

tests, documentation, etc.

• No credit for partial work –

– Estimated by the team– Relative values

No credit for partial work either done or not done

As vacationer, I want to search for available


rooms.

User Stories to Convey Meaning

• Requirements might sayThe product shall have a gas engine

Product Roadmap

Iteration Planning

Iteration Demo and

Retrospective

Iteration Execution

Delivery

VisionCustomer

Needs

Release Planning

– The product shall have a gas engine– The product shall have four wheels

• The product shall have a rubber tire mounted toThe product shall have a rubber tire mounted to each wheel

– The product shall have a steering wheel– The product shall have a steel body


Source Mike Cohn:

www.mountaingoatsoftware.com

User Stories to Convey MeaningProduct


Iteration Demo and

Retrospective

Iteration Execution

Delivery

VisionCustomer

Needs

Release Planning

As a <lawn service provider> I want to mow lawns quickly and easily.

As a <lawn service provider> I want to sit p

comfortably while mowing lawns.

Copyright 2009 Northrop Grumman CorporationCopyright 2010 Northrop Grumman Corporation50 Reference: Mike Cohn, mountaingoatsoftware.com

Requirements to User Stories

The system shall provide the capability for ki h t l ti

Product Roadmap

Iteration Planning

Iteration Demo and

Retrospective

Iteration Execution

Delivery

VisionCustomer

Needs

Release Planning

making hotel reservations.

As a premiere member, I want to search for available discounted rooms

As vacationer, I want to search for available

discounted rooms. rooms.

As vacationer, I want to save my selections.


a y o

Non-Functional Requirements?Product


Iteration Demo and

Retrospective

Iteration Execution

Delivery

VisionCustomer

Needs

Release Planning

As a vacationer and user of the hotel website, I want the system to be available

As vacationer, I want web pages to download the system to be available

99.99% of the time… in <4 seconds…

As the hotel website owner, I want 10,000 concurrent users to be Stories forStories for DescribesDescribesable to access the site at the same time with no impact to performance…

Stories for Stories for nonnon--functional functional requirementsrequirements

Describes Describes system system

behavior or behavior or h t i tih t i ti


characteristicscharacteristics

Reference: Mike Cohn, mountaingoatsoftware.com

A User Story is Comprised of…Product


Iteration Demo and

Retrospective

Iteration Execution

Delivery

VisionCustomer

Needs

Release Planning

• A written description of the story, used for planning and as a reminder

• Conversations about the story that serve to flesh out the details of the story

• Tests that convey and document details that can be used to determine when a story is complete

h // f / l /– http://www.mountaingoatsoftware.com/article_view/27


Writing User Stories

• Often written by the Product Owner or as a team

B i t t t id

Product Roadmap

Iteration Planning

Iteration Demo and

Retrospective

Iteration Execution

Delivery

VisionCustomer

Needs

Release Planning

• Brainstorm to generate ideas

• Some stories start out as epic stories; break them downdo

• Stories should be drafted and estimated prior to the release planning meeting

IndependentIndependent

Negotiable

Valuable

Estimatable

Sized


Testable

Estimating Technique: Planning Poker

• Estimating the user stories for a release. A release is one or more iterations.

• Going into the estimation phase, stories for the release

Product Roadmap

Iteration Planning

Iteration Demo and

Retrospective

Iteration Execution

Delivery

VisionCustomer

Needs

Release Planning

Going into the estimation phase, stories for the release have been identified and each has verification objectives; Stories have been discussed with the team.

• StepsE h ti t i i d k f d h d h lid b h (1– Each estimator is given a deck of cards, each card has a valid number such as (1, 2, 3, 5, 8, 13, 21, ?)

– The teams read the stories– An “average” story is selectedg y– The story is read to the team and discussed briefly– Each estimator selects a card to reveal his estimate – Cards are turned over so everyone can see them

1 2 3 5 8 13 21 ?

– Differences in estimates are discussed; especially outliers– Re-estimate until estimates converge


1 2 3 5 8 13 21 ?Reference: www.mountaingoatsoftware.com

TekTalk: Estimate This!

Backlog Item RelativeEstimate

Create a 50 slide presentation on agile practicesCreate a 50 slide presentation on agile practices

Read a James Patterson novel (500 pages)

Read a bedtime story to a child

l l fWrite a 6-8 page article on your latest software project and lessons learned


Time: 10 minutes


Product Roadmap

Iteration Planning

Iteration Execution

VisionCustomer

Needs

Release Planning

Iteration Demo and



Release Planning

Iteration Detailed PlanningProduct


Iteration Execution

VisionCustomer

Needs

Release Planning

Identify capabilities and high-level requirements(Capabilities Description Document)

Hi h L l d i U C d U St i

Begin prior to the start of the release

Initiate ProjectProduct Roadmap

Iteration Demo and


High Level design, Use Cases, and User StoriesDefine end-to-end capability tests

Create the Product Backlog

Systems architecture

Systems engineering

High level requirements mapped to end-to-end


ppcapabilities and stories.

Release Planning Meeting Detailed Planning

Select User Stories for the Iteration

The Team defines the tasks for each story and the estimated hours based upon a definition of doneSupported by the

Scrum Master


Formal System of Systems

Design –Build – Unit Verification – Integration and Component Verification

Scrum Master yIntegration

and Verification at

the end of each iteration

SE tasks are included as a task in a given story Not a

handoff


Iteration Demonstration and Retrospective

Example of “Done”

• Designed

• Design Review

Product Roadmap

Iteration Planning

Iteration Demo and

Retrospective

Iteration Execution

Delivery

VisionCustomer

Needs

Release Planning

Design Review

• Refactored

• Coded

• Code Review

• Unit Tested

• Functional Tested

• Integration Tested

• Regression Tested

• Security Tested


• User/Stakeholder Tested

• Documented

Release Plan to Iteration PlanE ample Hotel WebsiteExample: Hotel Website

Product Roadmap

Iteration Planning

Iteration Demo and

Retrospective

Iteration Execution

Delivery

VisionCustomer

Needs

Release Planning

Release Plan Iteration Plan (Stories with Tasks)

Story Points Hours

Business Value

80 As a vacationer, I want to search room availability…

21

70 As a vacationer I want to 8

Design Review 4

Write Tests 8

Code 2470 As a vacationer, I want to change my reservation…

8

60 As a vacationer, I want to cancel my reservation

8

Code 24

Automate Test 8

cancel my reservation…


3


Iteration Planning Meeting

Meeting is time-boxed

Usually ½ day depending on length of

Product Roadmap

Iteration Planning

Iteration Demo and

Retrospective

Iteration Execution

Delivery

VisionCustomer

Needs

Release Planning

the iteration

U t i ith

INPUT OUTPUT

Iteration

Planning

User stories with business value

User stories with estimates

Iteration Goals

Stories for the iterationg

Meeting

estimates

Team capacity

Team velocity

Tasks with hours for each user

story


Team Capacity

• Capacity is the team members’ available hours to work in an iteration

Product Roadmap

Iteration Planning

Iteration Demo and

Retrospective

Iteration Execution

Delivery

VisionCustomer

Needs

Release Planning

iteration

• Revisited each iteration

• Compare planned task hours to Example for a two-week iterationCompare planned task hours to capacity hours

Example for a two week iteration

Team Member

Hours per day

Total hours in the iteration

Bill 5 50Bill 5 50

Scott 5 50

Chris 8 80

Andy 7 70

Cindy 7 70

Mike 8 80


8 80

TEAM TOTAL 40 400

TekTalk: Planning and Estimation

• Scenario: Based on customer needs, your team has defined a logical architecture for an online hotel reservation system. The system is a traditional 3 tier architecture:The system is a traditional 3 tier architecture:

a database layer (to persist reservations), a business logic layer (to manage reservations), and a browser-based user interface (to receive customer input). ( p )

Your product owner started to create the product backlog and has provided 2 Epic stories for the first release.

• With your team complete the following:• With your team complete the following:Read through the stories. Write 2-3 additional stories for each epic story.Include acceptance (testing) criteriaInclude acceptance (testing) criteria.Using Planning Poker identify story points for each story (not epics).Question: How will the team decide how many stories it should assign to an iteration? How do you know which stories to select?


yTime: 30 minutes

CheckPointCheckPoint• What we’ve covered so far

• Questions

H d i ?• How are we doing?


Time: 5 minutes


Product Roadmap

Iteration Planning

Iteration Execution

VisionCustomer

Needs

Release Planning

Iteration Demo and



Iteration Execution: Design, Build, TestProduct


Iteration Demo and

Retrospective

Iteration Execution

Delivery

VisionCustomer

Needs

Release Planning

Release Plan

St A

Itera

Iterat

Story A

Design

Build

Test

Story D

Design

Build

Test

ItD

emand Re

Story AStory BStory CStory n

ation Plan

tion Design

Story C

Design

Build

Test

eration onstrationetrospectiv

Fixed time frame

•• Unit Testing/Component TestingUnit Testing/Component Testing

n n ve

Unit Testing/Component Testing Unit Testing/Component Testing •• Continuous IntegrationContinuous Integration•• Test AutomationTest Automation•• Peer/Code ReviewsPeer/Code Reviews


Reference: Hallett, D. (2006). An introduction to agile and iterative project management.

Managing the Iteration Backlog

• Any team member can add, delete or change the iteration backlog

Product Roadmap

Iteration Planning

Iteration Demo and

Retrospective

Iteration Execution

Delivery

VisionCustomer

Needs

Release Planning

• Individuals sign up for work of their own choosing− Work is never assigned

• Estimated work remaining is updated dailyEstimated work remaining is updated daily

• Work for the iteration emerges

• If work is unclear, define a iteration backlog item , gwith a larger amount of time and break it down later

• Update work remaining as more becomes known


A Team’s Iteration Burndown

Week1Iteration 0 Tasks Owner Status Mon Tues Wed Thur Fri Mon Tues Wed Thur

User Story: As a vacationer, I want to search room availability…Product


Iteration Demo and

Retrospective

Iteration Execution

Delivery

VisionCustomer

Needs

Release Planning

Design Review Scott Completed 4 4 4 3 2 0 0 0 0Install baseline Bill Completed 4 4 4 0 0 0 0 0 0ICD updates Scott Completed 8 8 6 3 3 2 0 0 0Acquire test data Bill Completed 8 5 0 0 0 0 0 0 0Code Scott Completed 24 20 16 14 10 10 3 0 0Develop tests Scott Completed 8 8 8 6 4 4 4 3 0Run Tests Scott Completed 8 8 8 8 5 3 4 2 0

1H

ours

The TeamThe Team

Manages its work and Manages its work and progressprogressprogressprogress

Meets daily to discuss Meets daily to discuss progress and commit to progress and commit to

planplan


Managed by the Teamplanplan

The Daily Standup

SCRUM Daily Standup

1 What did you do since the last stand up?

Product Roadmap

Iteration Planning

Iteration Demo and

Retrospective

Iteration Execution

Delivery

VisionCustomer

Needs

Release Planning

1. What did you do since the last stand up?

2. What will you do today? (Commitment)

3. Is anything in your way? Parameters

SCRUM of SCRUMS – Standup (usually two or three times per week)

– Daily– Attendance required and

critical– 15-minutes( y p )

1. What has your team done since we last met?

2. What will your team do before we meet

– Stand-up– Not for problem solving

ynext?

3. What’s in your team’s way?

4. What are you about to put in another


y pteam’s way?

Scaling Scrum Recommendations

Product Roadmap

Iteration Planning

Iteration Demo and

Retrospective

Iteration Execution

Delivery

VisionCustomer

Needs

Release Planning


Iteration Execution: Design, Build, TestProduct


Iteration Demo and

Retrospective

Iteration Execution

Delivery

VisionCustomer

Needs

Release Planning

Developer’s Environment Test and Release SoS EnvironmentQA

Field System

Code

Unit/Component Testing

Data Feed Testing

Integration Testing

End-to-End Product Testing

QIntegration Tests


Agile TestingProduct


Iteration Demo and

Retrospective

Iteration Execution

Delivery

VisionCustomer

Needs

Release Planning

Test Early Test Often AutomateTest Early Test Often Automate


Theory and Practice

• Agile testing is about people and communication

Product Roadmap

Iteration Planning

Iteration Demo and

Retrospective

Iteration Execution

Delivery

VisionCustomer

Needs

Release Planning

– Test documents are often incomplete, out-of-date, ambiguous

– Test results should be big, public, easy-to-read chartscharts

• Testers are embedded with coders– The reasons? Speed, accountability,

t t f f k l dtransparency, transfer of knowledge

• Automated testing is a must

E l Oft A t tE l Oft A t t


Early, Often, AutomateEarly, Often, Automate

Agile Story/Test High-Level FlowRequirementsRequirements

Provided

Develop Use Cases

Product Roadmap

Iteration Planning

Iteration Demo and

Retrospective

Iteration Execution

Delivery

VisionCustomer

Needs

Release Planning

Write user stories

Write test

Typically during release planning

te testobjectives/cases

Team develops

Individual user story tests verified

Integration

Demonstration

Test Case Testing Regression Testing Performance Testing


Test Pass?Enter defect report N Verified and ValidatedY

Check It Out!

• Agile Testing: Unit, Acceptance, and Regression Testing

Product Roadmap

Iteration Planning

Iteration Demo and

Retrospective

Iteration Execution

Delivery

VisionCustomer

Needs

Release Planning

g g , p , g g(#3)– 8 minutes

• http://www agilejournal com/media-center/educational-videos/1188-• http://www.agilejournal.com/media center/educational videos/1188borland-part1


Time: 10 minutes


Product Roadmap

Iteration Planning

Iteration Execution

VisionCustomer

Needs

Release Planning

Iteration Demo and



The Iteration Review

• Demonstrates new functionality• Transparency and information sharing• Informal

Product Roadmap

Iteration Planning

Iteration Demo and

Retrospective

Iteration Execution

Delivery

VisionCustomer

Needs

Release Planning

• Informal• Time-boxed• Everyone invited• What has been tested and what stories are accepted• What has been tested and what stories are accepted• Revisit the backlog


Iteration Retrospective

• Take a look at what is and is not working well

• Time-boxed

Product Roadmap

Iteration Planning

Iteration Demo and

Retrospective

Iteration Execution

Delivery

VisionCustomer

Needs

Release Planning

Time boxed

• Done after every iteration

• Facilitated by the Scrum Master

Worked well

Could be improved

Actions and Priorities

1.

• Focus is on process improvement

• Whole team participates• ScrumMaster

2.

3.

• Product owner

• Team

• Consider customers and others

Ways to focus the discussion

G l t t Consider customers and others Goal we want to accomplish


Monitoring Progress Focuses on the Points (Work)

Product Burndown for the Release

900

1000

Points (Work) Remaining

Product Roadmap

Iteration Planning

Iteration Execution

VisionCustomer

Needs

Release Planning

500

600

700

800

ry P

oint

s

PlannedCompleted

Iteration Demo and


100

200

300

400Stor

Product Burndown

14035

Product Burndown

140350

Iteration1 Iteration2 Iteration 3 Iteration 4 Iteration 5 Iteration 6 Iteration 7

20406080

100120140

Sto

ry P

oint

sStory points baseline

Burndown (PtsRemain)10

152025

3530

20406080

100120140

Sto

ry P

oint

sStory points baseline

Burndown (PtsRemain)10

152025

3530

A project team’s burndown

• Based on story points planned

• Updated and reviewed each iteration

• As stories are accepted and tests passed,

-200

20

iterat

ion 0

iterat

ion 1

iterat

ion 2

iterat

ion 3

iterat

ion 4

iterat

ion 5

S )5

-200

20

iterat

ion 0

iterat

ion 1

iterat

ion 2

iterat

ion 3

iterat

ion 4

iterat

ion 5

S )5(team of teams)


requirement progress is updatedA team’s product burndown

End of the Release

• Similar to end of iteration – every iteration is potentially releasable

Product Roadmap

Iteration Planning

Iteration Demo and

Retrospective

Iteration Execution

Delivery

VisionCustomer

Needs

Release Planning

• Hardening iteration

• Stories demonstrated and accepted

• Version description document updated

• Many disciplined agile teams have a parallel ff dtesting effort during construction iterations

where defects are found and feed back into the process. In addition, the working software becomes a working “system”becomes a working “system”

• QA testing or DT&E II


Agenda





g g

Starting the Transition

• Communicate the need

• Communicate how agile practices will affect the enterprise and the people

• Create an agile leadership team with a transition backlog

• Provide training

• Provide a way for people to ask questions and resolve issues

• Get input

• Identify the Product Owner, ScrumMaster, and team members

• Define agile related metrics and mechanisms for gathering and managing with themg g g g g

• Begin creating the Product Backlog

• Assess compensation policies to encourage teamwork

• Start working through Transition Product Backlog• Start working through Transition Product Backlog

• Set up brown bag sessions


Reference: Ken Schwaber, www.controlchaos.comCheck out: Fearless Change by Manns and Rising

Thoughts about tools

• Agile PM/Story Management– Excel spreadsheets– Wiki

• Continuous Integration Tools– Hudson– CruiseControlWiki

– Jira/Greenhopper plug-in– Rally or VersionOne– Mingle

CruiseControl

• Testing– JUnit for Javag

– Others….

• Configuration Management and Build

– NUnit for C#• Both are very popular

and widely used frameworks for writingBuild

– Subversion, IBM ClearCase

• Design and Modeling

frameworks for writing and running tests (both unit and integration)

– Cobertura provides JUnit test t i

g g– Rhaposdy– Rational Systems Modeler

• Systems Engineering

coverage metrics– HP Quality Center– Rational Quality Center


• Systems Engineering– Requirements Database: ReqPro

Your Greatest Challenges

• Transitioning leadership and management roles (the paradigm shift from command and control to empowered teams)

• Culture change

• Distributed teams

• Scaling• Scaling

• Systems-of-systems level

• Earned value• Earned value

• Estimation

• Contracts

• Customer learning and frequent customer engagement

• CMMI/ISO 9000


• Buy-in from stakeholders

TekTalk: Retrospective

• Reflect on today’s session.– What worked well– Suggestions for improvement

• What do you think are the greatest challenges when transitioning to Agile practices?g g p

• What are three important take-aways from today?


Time: 15 minutes

Kaizen


Outcome Reflection

• Develop an understanding of the major agile engineering practices

Pa ticipate in a planning and estimating scena io• Participate in a planning and estimating scenario

• Gain insight into agile testing practices from a couple practitioners

P ti i t i t t ti• Participate in a team retrospective

• Have fun working together!


Final CheckPoint

• Agile is about creating an adaptive organization that is able to respond to the changing needs of customers and industries

• Agile is not just about software development

• Agile practices affect the entire organization

• There are several Agile methods under the umbrella of “Agile Practices”

• Agile development emphasizes the need for ongoing iterative development with completed, demonstrable functionality at the end of every iteration

• Agile methods emphasize the need for team and customer collaboration


Special Acknowledgments

• Many of the ideas in this presentation originated from:– My initial training by Ken Schwaber and Mike Cohn– The Agile Journal– Other contributions/research are noted throughout the presentation– My experiences with nearly 10 programs and projects across Northrop

GrummanGrumman


An Agile Reading List

• Adaptive Enterprise – by Steven Haeckel

• Agile and Iterative Development: A Manager’s Guide by Craig Larman

• Agile Estimating and Planning by Mike Cohn

• Succeeding with Agile by Mike Cohn• Succeeding with Agile by Mike Cohn

• Agile Project Management with Scrum by Ken Schwaber

• Agile Testing by Lisa Crispin and Janet Gregoryg g y p g y

• Scrum and The Enterprise by Ken Schwaber

• Weekly articles at www.scrumalliance.org

• www.mountaingoatsoftware.com by Mike Cohn


Agile Software and Systems Engineering Tutorial

Documents

Transcript of Agile Software and Systems Engineering Tutorial