Presentation from ScrumDay Twin Cities 2014

1. Individuals and Interactions
over Processes and Tools
Kelly Weyrauch
Agile Quality Systems LLC
2014
When Process Matters
Scrum Day 2014

2. Introductions
§ You – Process Perception Poll
§ Me
2 Agile Quality Systems 2014

3. From the Agile Manifesto
§ 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?
3 Agile Quality Systems 2014

4. Activities of a Software Process
IEC 62304 Software Lifecycle Process
Activities outside the scope of this standard
Customer needs Customer needs
SYSTEM development ACTIVITIES (including RISK MANAGEMENT)
satisfied
7 Software RISK MANAGEMENT
5.4
Software
detailed
design
Software integration
and integration
5.5
Software UNIT
implementation
8 Software configuration management
9 Software problem resolution
5.2
Software
requirements
analysis
5.1
Software
development
planning
5.8
Software release
5.7
Software SYSTEM
testing
5.3
Software
ARCHITECTURAL
design
5.6
testing
4 Agile Quality Systems 2014

5. The Systems Engineering Engine
System Development Processes
System Design Product Realization
Define
Stakeholder
Expectations
Validate
Define
Requirements Verify
Architect Integrate
Design
Implement
Technical Management
Processes
Technical Planning
Requirements Management
Interface Management
Risk Management
Configuration Management
Data Management
Adapted from: NASA Systems Engineering Handbook, NASA/SP-2007-6105
5 Agile Quality Systems 2014

6. Activities of System / Software
Development
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 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?”)
Proof of compliance with
specifications. Verification may be
determined by test, analysis,
demonstration, or inspection.
(“Did you build the thing right?”)
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)
Agile Quality Systems 2014 6

7. Process: Activities &
Deliverables
§ 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)
Define
Stakeholder
Expectations
Validate
Define
Requirements Verify
Architect Integrate
Design Implement
7 Agile Quality Systems 2014

8. What Kind of Software Do You
Create?
8 Agile Quality Systems 2014

9. Process at Each Level
Define
Stakeholder
Expectations
Define
Requirements Verify
Architect
Define
Validate
Test the Integration
Install / Deploy
Requirements Verify
Architect
Test the Integration
Build the Application
Design
Verify the Code
(Review, Unit
Test)
Write the Code
9 Agile Quality Systems 2014

10. How Agile Are You?
10 Agile Quality Systems 2014

11. Scaled Agile Framework™ Big
Picture

12. Agile & Process?
§ Oil and Water?
§ Hand in Glove?
§ Rye, yet Whole Wheat?
12 Agile Quality Systems 2014

13. Requirements & Stories
Validate
Requirements Verify
Test the Integration
Install / Deply
Define
Stakeholder
Expectations
Define
Architect
Requirements Verify
Test the Integration
Build the Application
BACKLOG
Story
Define
Architect
Design
Verify the Code
(Review, Unit
Test)
Write the Code
Story
Story
Story
Story
13 Agile Quality Systems 2014

14. Requirements & Stories
§ 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
14 Agile Quality Systems 2014

15. Delivering a Story
Validate
Requirements Verify
Test the Integration
Install / Deploy
Define
Stakeholder
Expectations
Define
Architect
Requirements Verify
Test the Integration
Build the Application
BACKLOG
Story
Define
Architect
Design
Verify the Code
(Review, Unit
Test)
Write the Code
Story
Story
Story
Story
15 Agile Quality Systems 2014

16. Delivering a Story –
Done means Done
§ 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
16 Agile Quality Systems 2014

17. Delivering a Story –
Done means Done
§ 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
17 Agile Quality Systems 2014

18. Technical Debt
§ 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
18 Agile Quality Systems 2014

19. Completing a Sprint
The Demo
BACKLOG
Story
Define
Stakeholder
Expectations
Define
Requirements Verify
Architect
Define
Validate
Test the Integration
Install / Deploy
Requirements Verify
Architect
Design
Test the Integration
Build the Application
Verify the Code
(Review, Unit
Test)
Write the Code
Story
Story
Story
Story
Sprint
19 Agile Quality Systems 2014

20. Potentially Shippable Increment
Validate
Requirements Verify
Test the Integration
Install / Deploy
Define
Stakeholder
Expectations
Define
Architect
Requirements Verify
Test the Integration
Build the Application
BACKLOG
Story
Define
Architect
Design
Verify the Code
(Review, Unit
Test)
Write the Code
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
20 Agile Quality Systems 2014

21. Sprint Planning, PSI Planning
§ 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
21 Agile Quality Systems 2014

22. Discussion Provoking Questions
§ 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?
22 Agile Quality Systems 2014

23. Want More Disussion?
Kelly Weyrauch
Agile Quality Systems
Kelly@AgileQualitySystems.com
763-688-0980
23 Agile Quality Systems 2014