Software Development Rhythms: Harmonizing Agile Practices For Synergy

An accessible, innovative perspective on using the flexibility of agile practices to increase software quality and profitability
When agile approaches in your organization don't work as expected or you feel caught in the choice between agility and discipline, it is time to stop and think about software development rhythms!
Agile software development is a popular development process that continues to reshape philosophies on the connections between disciplined processes and agile practices. In Software Development Rhythms, authors Lui and Chan explain how adopting one practice and combining it with another builds upon the flexibility of agile practices to create a type of "synergy" defined as software development rhythms. The authors demonstrate how these rhythms can be harmonized to achieve synergies, making them stronger together than they would be apart. Software Development Rhythms provides programmers with a powerful metaphor for resolving some classic software management controversies and dealing with some common difficulties in agile software management.
Software Development Rhythms is divided into two parts and covers:
Essentials — provides an introduction to software development rhythms; explores the programmer's unconscious mind at work on software methodology; discusses the characteristics of the iterative cycle and open source software development; and introduces the topic of agile values and agile practices
Rhythms — compares plagiarism programming with cut-paste programming; provides an in-depth discussion of different ways to approach collaborative programming; demonstrates how to combine and harmonize these practices so they can be applied to common software management problems such as motivating programmers, discovering solution patterns, managing software teams, and rescuing troubled IT projects; and takes a comprehensive look at Scrum, CMMI, Just-In-Time, Lean Software Development, and Test-Driven Development from a software development rhythm perspective
Abundantly illustrated with informative graphics and amusing cartoons, Software Development Rhythms is a comprehensive and thought-provoking introduction to some of the most advanced concepts in current software management. Written in a refreshingly easy-to-read style and filled with interesting anecdotes, simulation exercises, and case studies, Software Development Rhythms is suitable for the practitioner and graduate student alike. It offers readers practical guidance on how to take the themes and concepts presented in this book back to their own projects to harmonize their software practices and release the synergies of their own teams.

Kim Man Lui, PhD, is an Independent Consultant and a Visiting Assistant Professor in the Department of Computing at the Hong Kong Polytechnic University. Dr Lui is a Certified Database Administrator, a Certified Oracle Database Administrator, and a Sun Certified Java Programmer. He is also the author of two books.
Keith C.C. Chan, PhD, is Professor and Head of the Department of Computing at the Hong Kong Polytechnic University. Previously, he was a senior analyst at the IBM Canada Laboratory, Toronto.

PART I: ESSENTIALS.
Chapter 1: No Programmer Dies.
1.1 Developing Software vs. Building a Tunnel.
1.1.1 The good old days?
1.1.2 The more things change the more they stay the same?
1.1.3 Behind Software Products.
1.1.4 Deal or not deal.
1.2 Do-Re-Mi Do-Re-Mi.
1.2.1 Iterative Models.
1.2.2 Code and Fix.
1.2.3 Chaos.
1.2.4 Methodology that matters.
1.3 Software Development Rhythms.
1.3.1 Stave Chart by Example.
1.3.2 Game Theory.
1.3.3 IN-OUT Diagram.
1.3.4 Master-Coach Diagram.
1.3.5 No Mathematics.
1.3.6 Where to Explore Rhythms.
Chapter 2: Understanding Programmers.
2.1 Personality and Intelligence.
2.1.1 Virtuosi.
2.1.2 Meeting your team.
2.1.3 Recruiting Programmers.
2.2 Outsourced Programmers.
2.2.1 Programmers in Their Environments.
2.2.2 Programmers, Cultures, and Teams.
2.3 Experienced Management.
2.3.1 Being Casual about Causal Relationships.
2.3.2 Not Learning From Experience.
2.3.3 Doing things right right now.
Chapter 3: Start with Open Source.
3.1 Process and Practice.
3.1.1 The 4Ps of Projects.
3.1.2 Agile Values.
3.1.3 Zero-point collaboration.
3.2 OSS Development.
3.2.1 Software Cloning.
3.2.2 Software Quality.
3.2.3 Starting Processes.
3.2.4 Open Source Development Community.
3.2.5 Ugrammers.
3.2.6 Participant Roles.
3.2.7 Rapid Release.
3.2.8 Black-box Programming.
3.2.9 Open Source Software Practices.
3.3 OOS-Like Development.
3.3.1 Agile Practices.
3.3.2 Communication Proximity.
3.3.3 Loose and Tight Couple.
3.3.4 Co-located OSS Development.
PART II: RHYTHMS.
Chapter 4: Plagiarism Programming.
4.1 Plagiarism.
4.1.1 Existing Code.
4.1.2 Social Network Analysis.
4.1.3 Being Plagiarized.
4.1.4 Turn everyone into a programmer.
4.1.5 Pattern Language.
4.1.6 Software Team Capability.
4.1.7 Rough-Cut Design.
4.1.8 Training is not a solution.
4.2 Nothing Faster than Plagiarism.
4.2.1 Immorality.
4.2.2 Unprecedented Code.
4.2.3 People Network.
4.2.4 Rhythm for Plagiarism.
4.2.5 Plagiarism at Work.
4.3 Business and Rhythm for Plagiarism.
4.3.1 15 Minute Business Presentation.
4.3.2 Marketing Research.
4.3.3 Chatting Robot.
4.3.4 Old Song New Singer.
Chapter 5: Pair Programming.
5.1 Art and Science.
5.1.1 The Right Partner.
5.1.2 Noisy Programming.
5.1.3 Just Training.
5.1.4 Pay to watch.
5.2 Two Worlds.
5.2.1 Moneyless World.
5.2.2 Money-led World.
5.2.3 Economics.
5.2.4 Mythical Quality-time.
5.2.5 Elapsed Time.
5.2.6 Critical Path Method.
5.2.7 Why two not three: Anti-Group.
5.2.8 Software Requirements are Puzzles.
5.3 Programming Task Demands.
5.3.1 2 and 4 is 6.
5.3.2 2 and 4 is 4.
5.3.3 2 and 4 is 3.
5.3.4 2 and 4 ≥ 2.
5.3.5 2 and 4 is unknown.
5.4 Pair programming is more than programming.
5.4.1 Design by Code.
5.4.2 Pair Design.
5.4.3 Rhythmic Pair Programming.
5.5 Pair programming Team Coached.
Chapter 6: Repeat Programming.
6.1 Controversies in Pair Programming.
6.1.1 Is Programming a Unique Work?
6.1.2 Are Three Minds Better Than Two?
6.1.3 Un-replicable Experiments.
6.2 Repeat Programming.
6.2.1 Variances.
6.2.2 Principles.
6.2.3 Triple Programming Unproductive.
6.3 Rhythm: Pair - Solo - Pair - Solo.
6.3.1 Persistence.
6.3.2 Connection.
6.3.3 Motivation.
6.4 An exception that proves Brooks’ Law.
6.4.1 Low Morale.
6.4.2 Communication Costs.
6.4.3 Rhythm for Late Projects.
Chapter 7: Agile Teaming.
7.1 Project Teams.
7.1.1 Self-organizing teams.
7.1.2 Teams in Team.
7.1.3 Project Team Composition.
7.1.4 Team Life Cycle vs. Learning Curve.
7.2 Productivity.
7.2.1 The Illusion of Productivity.
7.2.2 Collective Code Ownership.
7.2.3 Accountability, Responsibility and Transparency.
7.3 Problems and Problem Owners.
7.3.1 Rhythm: Trouble - Restructuring.
7.3.2 Teaming Principles.
7.4 Failing Projects Rescued.
7.4.1 Project Traffic Light.
7.4.2 A Business Case.
7.4.3 Steering Committee Meeting.
7.4.4 Agile Teaming in Action.
7.5 Beware of Iago.
Chapter 8: Incremental Design.
8.1 Modeling and Planning.
8.1.1 Agile Planning.
8.1.2 Design by Functional Modules.
8.1.3 Simple Design.
8.1.4 Total Cost Concept.
8.2 Rework or reuse.
8.2.1 Unpreventable Rework.
8.2.2 Improvisation.
8.2.3 Up-front Design.
8.3 Just-in-time Software Development.
8.3.1 The CMM Rhythm.
8.3.2 A Factory Tour.
8.3.3 Walking Worker.
8.3.4 Just-in-time Software Development.
8.3.5 Incremental Design.
8.4 Requirements Complexity.
8.4.1 Forgotten Requirements.
8.4.2 Conflicting Requirements.
8.4.3 Rapid Changing Requirements.
8.4.4 Requirements and Design.
8.5 Refactoring.
8.5.1 Refactoring Activities.
8.5.2 Refactoring by Challenging.
8.5.3 Refactoring for Design Patterns.
8.5.4 Making Deliberate Mistakes.
Chapter 9: Test-Driven Development.
9.1 Reverse Waterfall.
9.1.1 Design - Code - Test.
9.1.2 Test - Code - Design.
9.2 Test-First Programming.
9.2.1 Testing and Verification.
9.2.2 Break-point testing.
9.2.3 Supporting Practices.
9.3 Rhythm: Test - Code - Refactor.
9.3.1 Simple Example.
9.3.2 Automation.
9.3.3 Revolution in Consciousness!
9.3.4 Test Case for Collaboration.
9.4 Rapid Software Process Improvement.
9.4.1 Training Program.
9.4.2 Project Planning.
9.4.3 Project Tracking.
9.4.4 Software Quality.
9.4.5 Software Configuration.
9.4.6 People Discipline.
Epilogue: Medley.
Appendix I: Nammik.
References.