individuals and interactions over processes and tools

Kelly Weyrauch Agile Quality Systems LLC 2014

Individuals and Interactions over Processes and Tools

When Process Matters Scrum Day 2014

§ You – Process Perception Poll

§ Me

Introductions

2 Agile Quality Systems 2014

§  Individuals and interactions over processes and tools

§  While there is value in the items on the right, we value the items on the left more

§ How much do you value Process?

From the Agile Manifesto

3 Agile Quality Systems 2014

Activities of a Software Process IEC 62304 Software Lifecycle Process

4 Agile Quality Systems 2014

SYSTEM development ACTIVITIES (including RISK MANAGEMENT)

Customer needs Customer needs satisfied

7 Software RISK MANAGEMENT

8 Software configuration management

9 Software problem resolution

Activities outside the scope of this standard

5.2Software

requirements analysis

5.1Software

developmentplanning

5.8Software release

5.7Software SYSTEM

testing

5.3Software

ARCHITECTURALdesign

5.4Software detaileddesign

5.6Software integration

and integration testing

5.5Software UNIT

implementation

The Systems Engineering Engine

5 Agile Quality Systems 2014

Define Stakeholder Expectations

Validate

Define Requirements Verify

Architect Integrate

Design

System Development Processes

System Design Product Realization

Implement

Adapted from: NASA Systems Engineering Handbook, NASA/SP-2007-6105

Technical Management Processes

Technical Planning

Requirements Management

Interface Management

Risk Management

Configuration Management

Data Management

Define Stakeholder Expectations

Validate

Define Requirements Verify

Architect Integrate

Design Implement

A statement of needs, desires, capabilities, and wants that are not expressed as a requirement (not expressed as a “shall” statement)

The agreed-upon need, desire, want, capability…expressed as a “shall”

statement.

Proof of compliance with specifications. Verification may be

determined by test, analysis, demonstration, or inspection.

(“Did you build the thing right?”)

Proof that the product accomplishes the intended purpose. Validation

may be determined by a combination of test, analysis, and

demonstration. (“Did you build the right thing?”)

Integration = Build, assemble, connect, gather, etc.

Integration Test = Show it was built properly. (Examples: Compiler checks, Static Analysis, “Smoke Test”, Regression Tests.) Might overlap with “Verify” activities.

Physical Arch = The next-level subsystems/components

Functional Arch = Features, Functions, Organization of the requirements

Operational Arch = Allocate requirements to the next-level subsystems

Decisions about the solution to be implemented, which become requirements for the next-level subsystems/components. Example: Interface definition/specification.

Next-Level Design, Build, Buy, Re-Use

(Write the code Unit-Test the code)

Activities of System / Software Development

Agile Quality Systems 2014 6

§ Each Activity: § Consumes Inputs § Produces Outputs (documents,

work products, evidence) §  Is guided by Acceptance Criteria § Uses tools & techniques §  Is performed by somebody

(owner/author, reviewer/approver)

Process: Activities & Deliverables

7 Agile Quality Systems 2014

Define Stakeholder Expectations

Validate

Define Requirements Verify

Architect Integrate

Design Implement

What Kind of Software Do You Create?

8 Agile Quality Systems 2014

Process at Each Level

9 Agile Quality Systems 2014

Define Requirements Verify

Architect Build the Application

Design

Verify the Code (Review, Unit

Test)

Write the Code

Define Stakeholder Expectations

Validate

Define Requirements Verify

Architect

Test the Integration

Install / Deploy

Test the Integration

How Agile Are You?

10 Agile Quality Systems 2014

Scaled Agile Framework™ Big Picture

§ Oil and Water?

§ Hand in Glove?

§ Rye, yet Whole Wheat?

Agile & Process?

12 Agile Quality Systems 2014

Build the Application

Test the Integration

Install / Deply

Test the Integration

Requirements & Stories

13 Agile Quality Systems 2014

Story

Define Requirements Verify

Architect

Design

Verify the Code (Review, Unit

Test)

Write the Code

Define Stakeholder Expectations

Validate

Define Requirements Verify

Architect

BACKLOG

Story

Story

Story

Story

§ Stories, with their description and Acceptance Criteria come from: § Stakeholder Expectations § Requirements

§ But how “done” are they, should they be? § Thoughts? Written? Reviewed & Approved? § A whim to be proven? A solid idea that might change?

Locked down? § Answer is determined by business risk § Addressed when Story is written § Addressed again at Sprint Planning

Requirements & Stories

14 Agile Quality Systems 2014

Build the Application

Test the Integration

Install / Deploy

Test the Integration

Delivering a Story

15 Agile Quality Systems 2014

Story

Define Requirements Verify

Architect

Design

Verify the Code (Review, Unit

Test)

Write the Code

Define Stakeholder Expectations

Validate

Define Requirements Verify

Architect

BACKLOG

Story

Story

Story

Story

§ Process requirements have been satisfied §  Requirements §  Architecture §  Design §  Code §  Unit-level Verification §  Integration & Integration Test §  Software Verification

§ Applicability and done-ness determined in Story creation and Sprint Planning

Delivering a Story – Done means Done

16 Agile Quality Systems 2014

§ Change Management Records § As part of each Story’s Acceptance Criteria § Change Management Record documents the Story’s

Plan for what processes apply § Change Management Record completed as part of the

Story’s completion, with whatever evidence your process requires for demonstrating the process has been followed

Delivering a Story – Done means Done

17 Agile Quality Systems 2014

§  Incurred when you can’t (won’t?) complete all process activities for a Story § Examples?

§ Managed by: § Putting the Story (or a piece of it) back on the Backlog § Debt Reduction Stories

Technical Debt

18 Agile Quality Systems 2014

Completing a Sprint The Demo

19 Agile Quality Systems 2014

Story

Define Requirements Verify

Architect

Design

Verify the Code (Review, Unit

Test)

Write the Code

Define Stakeholder Expectations

Validate

Define Requirements Verify

Architect

BACKLOG

Story

Story

Story

Story

Sprint

Build the Application

Test the Integration

Install / Deploy

Test the Integration

Build the Application

Test the Integration

Install / Deploy

Test the Integration

Potentially Shippable Increment

20 Agile Quality Systems 2014

Story

Define Requirements Verify

Architect

Design

Verify the Code (Review, Unit

Test)

Write the Code

Define Stakeholder Expectations

Validate

Define Requirements Verify

Architect

BACKLOG

Story

Story

Story

Story

Sprint

Sprint

Release

§  “Sum-of-the-Parts” Reviews (Approvals)

§  “Formal Build” (as opposed to a fake one?)

§  “Formal Verification” (as opposed to informal?)

§  Regression Tests (if they weren’t already run)

§  Exploratory Testing §  Debt Reduction

§ Sprint & Increment Plans identify the process steps needed to be “done” §  “Sum-of-the-Parts” Reviews (Approvals) §  “Formal Build” (as opposed to a fake one?) §  “Formal Verification” (as opposed to informal?) § Regression Tests (if they weren’t already run) § Exploratory Testing § Debt Reduction

Sprint Planning, PSI Planning

21 Agile Quality Systems 2014

§ What’s the difference between a Story and a Bug?

§ What happens when the process is too burdensome?

§ Debt Management § Good debt? § What happens when debt is not managed?

Discussion Provoking Questions

22 Agile Quality Systems 2014

Kelly Weyrauch Agile Quality Systems Kelly@AgileQualitySystems.com 763-688-0980

Want More Disussion?

23 Agile Quality Systems 2014