Parallel Agile – faster delivery, fewer defects, lower cost

Foreword
Preface: Why Can’t We Develop Software in Parallel?
	There’s Gotta Be a Loophole
	We Learned a Few Things in Graduate School
	But This Will Never Integrate, Right?
	4 Days per Use Case × 47 Parallel Use Cases … Is 4 Days?
	Proof of Concept, MVP, Then Release 1 in 3 Months
	Surviving 100% Staff Turnover
	Who Needs Parallel Agile?
	What’s in the Rest of the Book?
Acknowledgments
Contents
Chapter 1: Parallel Agile Concepts
	1.1 Partitioning a System for Parallel Development
	1.2 Just Enough Planning
	1.3 Feedback-Driven Management, Model-Driven Design
	1.4 Risk Management
	1.5 Project Management
	1.6 Executable Domain Models
	1.7 Parallel Agile Process
	1.8 Scalability and Evolution of Parallel Agile from ICONIX Process
	1.9 Summary
	References
Chapter 2: Inside Parallel Agile
	2.1 Code First, Design Later
	2.2 Prototyping as Requirements Exploration
	2.3 Overview of the Parallel Agile Process
	2.4 Inception
		2.4.1 Evolving Database Schemas
		2.4.2 Enabling Integration Between Developers
	2.5 Parallel Development Proceeds in Three Phases After Inception
	2.6 Proof of Concept (Building the Right System)
	2.7 Minimum Viable Product (Building the System Right)
		2.7.1 Using MVC Decomposition to Make Your Use Cases Less Ambiguous
		2.7.2 Using Parts of Parallel Agile with Scrum
		2.7.3 Adding Controllers to the Scrum Backlog
		2.7.4 Tracking Agile Projects by Epic, User Story, and Task
	2.8 Optimization and Acceptance Testing
	2.9 Balancing Agility and Discipline
	2.10 Summary
	References
Chapter 3: CodeBots: From Domain Model to Executable Architecture
	3.1 Solving Problems to Enable Parallelism
		3.1.1 Parallel Agile Versus Agile/ICONIX
		3.1.2 Cost Benefits
		3.1.3 Origin of Executable Architectures
		3.1.4 Developer to Developer Integration
		3.1.5 Resilience to Staff Turnover
	3.2 Domain-Driven Prototyping
		3.2.1 Introducing CodeBot
		3.2.2 What Is Prototyping?
		3.2.3 CarmaCam Domain Modeling Workshop
			3.2.3.1 Extending the CarmaCam Domain Model to Support Machine Learning
			3.2.3.2 Running CodeBot Again
		3.2.4 The Prototyping Is Done—What’s Next?
	3.3 Using CodeBot During the MVP Phase
		3.3.1 What to Expect from Your UML Relationships
			3.3.1.1 Choosing a Different Relationship Type Affects What’s Generated
			3.3.1.2 Multiplicity Affects What’s Generated
	3.4 Deployment Architecture Blueprints (Preview)
	3.5 Summary
Chapter 4: Parallel Agile by Example: CarmaCam
	4.1 CarmaCam Architecture
	4.2 Sprint 1: Proof of Concept
		4.2.1 Executable Domain Model
		4.2.2 Use Cases and Storyboards
		4.2.3 Prototypes
			4.2.3.1 Upload Large Video Files to MongoDB
			4.2.3.2 Web App
			4.2.3.3 Mobile App Circular Video Buffer
			4.2.3.4 Mobile App Voice Command Activation
	4.3 Sprint 2: Minimum Viable Product
		4.3.1 MVC Decomposition
		4.3.2 State Transition Diagram
		4.3.3 Testing
			4.3.3.1 Acceptance Testing
			4.3.3.2 Mobile App Testing
			4.3.3.3 User Experience Testing
			4.3.3.4 Server Load Testing
		4.3.4 Server Migration to AWS
	4.4 Sprint 3: Optimization
		4.4.1 Web App
		4.4.2 Mobile App
		4.4.3 Emergency Alert Receiver App
		4.4.4 Server App
	4.5 What’s Next?
	4.6 Summary
Chapter 5: Taking the Scream Out of Scrum
	5.1 Agile Mindset
		5.1.1 General Agile Mindset Misconceptions
		5.1.2 The Sweet Spot of Parallel Agile in the Agile Mindset
		5.1.3 Scaled Agile Framework and Parallel Agile
	5.2 Scrum as It Should Be: A Quick Overview
		5.2.1 Misconceptions About Scrum Roles
			5.2.1.1 You Have Multiple Product Owners on Your Product
			5.2.1.2 The Scrum Master Manages the Team
			5.2.1.3 You Reform the Development Team Every Sprint
		5.2.2 Misconceptions About Scrum Events
			5.2.2.1 Sprint Timeboxes Are Used to Squeeze More Work Out of Developers
			5.2.2.2 The Length of Sprints Changes All the Time
			5.2.2.3 Sprints Are Long, So You Can Get More Work Done
			5.2.2.4 You Do All Estimating and Refinement During Sprint Planning
			5.2.2.5 During the Daily Standup, You Justify Your Existence
			5.2.2.6 The Sprint Ends with a Demo (aka Dog and Pony Show)
			5.2.2.7 Retrospective Time: Let’s Complain About What Went Wrong
		5.2.3 Misconceptions About Scrum Artifacts
			5.2.3.1 User Stories Are the Only Thing You Can Put in a Product Backlog, or User Stories Are Required to Be Agile
			5.2.3.2 The Product Backlog Is Ordered by Priority . . . and We Have 50 Priority 1 PBIs
			5.2.3.3 Detail Your Product Backlog Completely (or as Much as Possible)
			5.2.3.4 Preplan Sprints Before the Sprint Planning Meeting
			5.2.3.5 Every Sprint Release Is an Increment to Production
	5.3 Example: Parallel Agile with Backlogs and a Small Team
		5.3.1 From Product Vision to Product Delivery
		5.3.2 Preparing the Product Backlog
		5.3.3 Sprint Planning
		5.3.4 Sprint
		5.3.5 Sprint Review
	5.4 Summary
	References
Chapter 6: Test Early, Test Often
	6.1 A Note About Software Quality
	6.2 Errors of Commission vs. Errors of Omission
	6.3 Acceptance Testing Fails When Edge Cases Are Missed
	6.4 CarmaCam Example
	6.5 Testing at Different Levels
	6.6 A Capsule Summary of Domain Oriented Testing
	6.7 Drive Unit Tests from the Code
	6.8 Drive Component Tests from the Use Case Scenarios
		6.8.1 When Should Component Tests Be Written?
	6.9 Drive Acceptance Tests from the User Stories and Use Case Scenarios
		6.9.1 Who Is Responsible for the Acceptance Tests?
		6.9.2 Manual vs. Automated Acceptance Tests
		6.9.3 Acceptance Test Early and Often
		6.9.4 Creating a Manual Acceptance Test Script
		6.9.5 Creating an Automated Acceptance Test with BDD and Cucumber
		6.9.6 Creating an Automated Acceptance Test with DDT
			6.9.6.1 Scenario Testing
			6.9.6.2 Comprehensive Requirements Testing
		6.9.7 Prototype to Discover Requirements, Review Them Carefully, and Test Each One
	6.10 Summary
	References
Chapter 7: Managing Parallelism: Faster Delivery, Fewer Defects, Lower Cost
	7.1 Believe in Parallelism: Resistance Is Futile
		7.1.1 Multicore CPUs
		7.1.2 Elastic Cloud of Developers
		7.1.3 You Want It WHEN?
	7.2 Managing Parallelism: Instant Tactical Assessment
		7.2.1 Task Estimation from Sprint Plans
		7.2.2 Rapid and Adaptive Planning
		7.2.3 Seizing the Initiative
		7.2.4 Analyzing Use Case Complexity
		7.2.5 Redeploying Resources as the Situation Evolves
		7.2.6 Accelerating a Late Project by Adding Developers
	7.3 Improving Quality While Going Faster
		7.3.1 Generating Database Access Code
		7.3.2 Generating Acceptance Tests from Use Cases
		7.3.3 Testing in Parallel with Developing
		7.3.4 Hurry, but Don’t Rush
	7.4 Lowering Development Cost
		7.4.1 Doing “Just Enough” Design Reduces Costs
		7.4.2 Combining Planning with Feedback
	7.5 Summary
	References
Chapter 8: Large-Scale Parallel Development
	8.1 Parallel Agile and the Incremental Commitment Spiral Model
		8.1.1 ICSM Phases Map to Proof of Concept, Minimum Viable Product, and Optimization
		8.1.2 ICSM Spiral Includes Prototyping, Design, and Acceptance Testing
		8.1.3 ICSM Principles Were Developed on Very Large Projects
	8.2 Parallel Agile Critical Success Factors
	8.3 TRW-USAF/ESC CCPDS-R Parallel Development
		8.3.1 CCPDS-R Evidence-Based Decision Milestones
		8.3.2 CCPDS-R Parallel Development
	8.4 Parallel Development of Even Larger TRW Defense Software Systems
	8.5 Comparing the Parallel Agile Approach and CSFs and Other Successful Scalable Agile Approaches
		8.5.1 The Speed, Data, and Ecosystems Approach
		8.5.2 The Scaled Agile Framework (SAFe) Approach
	8.6 Conclusions and Latest Parallel Agile Scalability Experience
	8.7 Summary
	References
Chapter 9: Parallel Agile for Machine Learning
	9.1 Phase 1: Proof of Concept and Initial Sprint Plan
		9.1.1 CarmaCam Incident Reports
		9.1.2 CarmaCam Emergency Alert Videos
		9.1.3 Identifying Multiple Lane Changes at High Speed
		9.1.4 Training Machine Learning Models from CarmaCam Videos
		9.1.5 Training Machine Learning Models Using Video Games
		9.1.6 Phase 1 Results and Summary
	9.2 Phase 2: Minimum Viable Product – Detecting a Likely DUI from Video
	9.3 Summary
	Reference
Appendix A: The Scream Guide
	Purpose of the Scream Guide
		Definition of Scream
		How to Use the Scream Guide
	Uses of Scream
	Scream Theory
		Obfuscation
		Asymmetric Information
		Moving Targets
		Metrics and Reports
	Scream Values
	The Scream Team
		The Product Owner
		The Development Team
			Development Team Size
		The Scream Master
			Scream Master Abuse of the Product Owner
			Scream Master Abuse of the Development Team
			Scream Master Abuse by the Organization
	Scream Events
		The Sprint
			Cancelling a Sprint
		Sprint Planning
			Topic One: What Must Be Done this Sprint?
			Topic Two: How Will the Chosen Work Get Done?
			Sprint Goal
		Daily Scream
		Sprint Review
		Sprint Retrospective
	Scream Artifacts
		Product Backlog
			Monitoring Progress of the Team
		Sprint Backlog
			Monitoring Sprint Progress
		Increment
	Artificial Transparency
	Definition of “Done” (Quote-Unquote)
	End Note
	Acknowledgments
		People
		Creator
Appendix B: Architecture Blueprints
	Basic Prototype
	Typical REST-Based Architecture
	Microservice Architecture
	Principled Monolith Architecture
		Monolith or Microservices: A Warring Pack of M&Ms
		About the Principled Monolith
	Special Mention: Reactive Microservices Architecture
References
Index