CHANGE: Planned & Unplanned
CHANGE: Planned & Unplanned
Volume 8: Quality Software Series
About the Book
Gerald M. Weinberg illustrates how to create a supportive environment for software engineering —an environment in which your organization can realize long-lasting gains in quality and productivity by learning how to manage change.
As the author argues, the history of software engineering is riddled with failed attempts to improve quality and productivity without first creating a supportive environment. Many managers spend their money on tools, methodologies, outsourcing, training, and application packages, but they rarely spend anything to improve or to remove the management that created those situations in the first place.
From systems thinking to project management to technology transfer to the interaction of culture and process, this volume analyzes transformation from a broad range of perspectives, providing a breadth of awareness essential for successful management of high-quality software development.
Topics include:
Meta-Planning: Information
Meta-Planning: Systems Thinking
Tactical Change Planning
Planning Like a Software Engineer
What Changes Have to Happen
Components of Stable Software Engineering
Process Principles
Culture and Process
Improving Process
Requirements Principles and Process
Changing the Requirements Process
The book also had five important appendices:
Appendix A: The Diagram of Effects
Appendix B: The Software Engineering Cultural Patterns
Appendix C. The Satir Interaction Model
Appendix D. Control Models
Appendix E. The Three Observer Positions
About the Author
Bundles that include this book
Table of Contents
-
Change: Planned and Unplanned
- Part I. Planning for the Future Organization
-
Chapter 1. Meta-Planning: Part I. Information
- 1.1 Start by Meta-Planning
-
1.2 Information Gathering
- 1.2.1 Omission of information
- 1.2.2 Unreliable sources
- 1.2.3 Wrong level of detail
- 1.3 Mechanics
- 1.4 Helpful Hints and Suggestions
- 1.5 Summary
- 1.6 Practice
-
Chapter 2. Meta-Planning: Part II. Systems Thinking
-
2.1 Problem solving
- 2.1.1 The Big Game
- 2.1.2 No systematic approach for decision making
-
2.2 Growth and Size
- 2.2.1 Growth produces bigness
- 2.2.2 Complexity restricts development
- 2.2.3 Size restricts freedom
- 2.2.4 Tools influence thought
- 2.2.5 Big isn’t the same as small
-
2.3 Risk and Reward
- 2.3.1 Always be first
- 2.3.2 Always be second
- 2.3.3 Don’t risk
- 2.3.4 Don’t even talk about risk
-
2.4 Trust
- 2.4.1 You go first
- 2.4.2 Management swooping
-
2.5 Moving Off a Dead Stop
- 2.5.1 Critical mass
- 2.5.2 Chicken-and-egg syndrome
- 2.5.3 Wrong cultural prescriptions
- 2.5.4 Hooked by resisters
- 2.6 Helpful Hints and Suggestions
- 2.7 Summary
- 2.8 Practice
-
2.1 Problem solving
-
Chapter 3. Tactical Change Planning
- 3.1 What Is Tactical Change Planning?
- 3.2 Open-Ended Change Planning
-
3.3 Plans Are Made Backward
- 3.3.1 Test: Is it clear?
- 3.3.2 Test: Is it specific?
- 3.3.3 Test: Is each component accountable and dependable?
- 3.4 Choosing a New, Realistic Goal
-
3.5 Congruence from Start to Finish
- 3.5.1 Self: Where are you now?
- 3.5.2 Others: Who will be affected?
- 3.5.3 Context: What should be preserved?
-
3.6 Selecting and Testing a Goal
- 3.6.1 Use a positive format.
- 3.6.2 Be sure it’s achievable
- 3.6.3 Be sure it’s observable
- 3.6.4 Make it specific
- 3.6.5 Be sure the goal is not too tight
- 3.6.6 Explore variations
- 3.6.7 Eliminate solution statements
-
3.7 What Stands in the Way of Achieving the Goal?
- 3.7.1 Check for obstacles
- 3.7.2 Look for stabilizing feedback loops
-
3.8 Models for Planning in the Face of Unpredictability
- 3.8.1 Check risks and resources using the PLASTIC model
- 3.8.2 Check resources against the MOI Model
- 3.8.3 Check human resources using emotional information
- 3.9 The Feedback Plan
- 3.10 Helpful Hints and Suggestions
- 3.11 Summary
- 3.12 Practice
-
Chapter 4. Planning Like a Software Engineer
-
4.1 What Engineering Control Means
- 4.1.1 Dynamic models, not magic formulas
- 4.1.2 Trading off
- 4.1.3 Juggling multiple variables
- 4.1.4 Handling new levels of technology
- 4.2 The Fundamental Graph of Engineering Management Action
-
4.3 Levels of Control
- 4.3.1 Multi-level stability
- 4.3.2 Placing decisions at the right level
- 4.3.3 Decisions at higher levels can control decisions at lower levels
- 4.3.4 Decisions at low levels can control decisions at higher levels
- 4.3.5 Amplification by position
- 4.4 Helpful Hints and Suggestions
- 4.4 Summary
- 4.5 Practice
-
4.1 What Engineering Control Means
-
Chapter 5. Components of Stable Software Engineering
- 5.1 Why Software Isn’t Different
-
5.2 Why Software Costs So Much
- 5.2.1 System size
- 5.2.2 People factors
- 5.2.3 Tool factors
- 5.2.4 Poor management
- 5.3 Where Improvement Can Be Found
- 5.4 Why Software Projects Fail
-
5.5 Information Failures
- 5.5.1. Not knowing what product is wanted
- 5.5.2. Not understanding the nature of the processes
- 5.5.3 Having no visible evidence of progress
- 5.5.4 Lacking sufficient stability for meaningful measurements
- 5.5.5 Lacking or losing design integrity
-
5.6 Evolving Solutions to Information Failures
- 5.6.1. A requirements process to identify what product is wanted
- 5.6.2 Process models to explain the nature of software development
- 5.6.3 Processes that provide visible evidence on progress
- 5.6.4 Systems to provide stability for meaningful measurements
- 5.6.5 Tools and techniques to maintain design integrity
- 5.7 Action Failures
- 5.8 Helpful Hints and Suggestions
- 5.9 Summary
- 5.10 Practice
-
Chapter 6. Process Principles
- 6.1 The Millionaire Test
-
6.2 The Stability Principle
- 6.2.1 Phrases to listen for
- 6.2.2 Actions to take
-
6.3 The Visibility Principle
- 6.3.1 Phrases to listen for
- 6.3.2 Actions to take
-
6.4 The Measurability Principle
- 6.4.1 Phrases to listen for
- 6.4.2 Actions to take
-
6.5 The Product Principle
- 6.5.1 Phrases to listen for
- 6.5.2 Actions to take
- 6.6 Helpful Hints and Suggestions
- 6.7 Summary
- 6.8 Practice
-
Chapter 7. Culture and Process
- 7.1 The Culture/Process Principle
-
7.2 Examples of the Interaction of Culture and Process
- 7.2.1 Don’t kill anyone and don’t go to jail
- 7.2.2 Bring ‘em back alive
- 7.2.3 Quick results
- 7.2.4 Don’t make a wrong decision
- 7.2.5 Number of customers
-
7.3 Three Meanings of Process
- 7.3.1 Supervisory level: Making the product
- 7.3.2 Middle management level: Creating process models
- 7.3.3 Top management level: Creating a culture
- 7.4 What Creates the Culture?
- 7.5 Helpful Hints and Suggestions
- 7.6 Summary
- 7.7 Practice
-
Chapter 8. Improving Process
- 8.1 Three Levels of Process Improvement
-
8.2 An Example of Process Improvement
- 8.2.1 Document the actual process
- 8.2.2 Discover the root cause of the problem
- 8.2.3 Modify the process to reduce variation
- 8.2.4 Test the process improvements
- 8.3 Seeing the Invisible
- 8.4 Preventing Future Occurrences
- 8.5 Lessons
- 8.6 Sure, But We’re Different
- 8.7 But It Costs Too Much
- 8.7 Helpful Hints and Suggestions
- 8.8 Summary
- 8.9 Practice
-
Chapter 9. Requirements Principles and Process
- 9.1 The Assumption of Fixed Requirements
-
9.2 The Zeroth Law
- 9.2.1 Phrases to listen for
- 9.2.2 Actions to take
- 9.3 Process Models of Requirements
- 9.4 The Twin Processes
- 9.5 Upward Flow of Requirements
- 9.6 Management’s Attitude Toward the Requirements Process
- 9.7 Helpful Hints and Suggestions
- 9.8 Summary
- 9.9 Practice
-
Chapter 10. Changing the Requirements Process
-
10.1 Measure the True Cost and Value of Requirements
- 10.1.1 Faults caught early or not created at all
- 10.1.2 Redundant work eliminated
- 10.1.3 Better reception by customers
- 10.1.4 Faster, more manageable, development
- 10.1.5 Improved maintenance
-
10.2 Gain Control of the Requirements Inputs
- 10.2.1 Identify and plug all leaks
- 10.2.2 Replace leaks with explicit negotiation
-
10.3 Gain Control of Requirements Outputs
- 10.3.1 Visibility
- 10.3.2 Stability
- 10.3.3 Controllability
-
10.4 Gain Control of the Requirements Process Itself
- 10.4.1 Resource support
- 10.4.2 Process support
- 10.5 Helpful Hints and Suggestions
- 10.6 Summary
- 10.7 Practice
-
10.1 Measure the True Cost and Value of Requirements
- Appendix A: The Diagram of Effects
-
Appendix B: The Software Engineering Cultural Patterns
- Pattern 0. Oblivious Process
- Pattern 1: Variable Process
- Pattern 2: Routine Process
- Pattern 3: Steering Process
- Pattern 4: Anticipating Process
- Pattern 5: Congruent Process
-
Appendix C. The Satir Interaction Model
- Intake.
- Meaning.
- Significance.
- Response.
-
Appendix D. Control Models
- D.1. The Aggregate Control Model
-
D.2. Cybernetic Control Models
- D.2.1 The system to be controlled (the focus of Patterns 0 and 1)
- D.2.2 The controller (the focus of Pattern 2)
- D.2.3 Feedback control (the focus of Pattern 3)
- Appendix E. The Three Observer Positions
- What Next?
Other books by this author
The Leanpub 60 Day 100% Happiness Guarantee
Within 60 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks.
Now, this is technically risky for us, since you'll have the book or course files either way. But we're so confident in our products and services, and in our authors and readers, that we're happy to offer a full money back guarantee for everything we sell.
You can only find out how good something is by trying it, and because of our 100% money back guarantee there's literally no risk to do so!
So, there's no reason not to click the Add to Cart button, is there?
See full terms...
Earn $8 on a $10 Purchase, and $16 on a $20 Purchase
We pay 80% royalties on purchases of $7.99 or more, and 80% royalties minus a 50 cent flat fee on purchases between $0.99 and $7.98. You earn $8 on a $10 sale, and $16 on a $20 sale. So, if we sell 5000 non-refunded copies of your book for $20, you'll earn $80,000.
(Yes, some authors have already earned much more than that on Leanpub.)
In fact, authors have earnedover $13 millionwriting, publishing and selling on Leanpub.
Learn more about writing on Leanpub
Free Updates. DRM Free.
If you buy a Leanpub book, you get free updates for as long as the author updates the book! Many authors use Leanpub to publish their books in-progress, while they are writing them. All readers get free updates, regardless of when they bought the book or how much they paid (including free).
Most Leanpub books are available in PDF (for computers) and EPUB (for phones, tablets and Kindle). The formats that a book includes are shown at the top right corner of this page.
Finally, Leanpub books don't have any DRM copy-protection nonsense, so you can easily read them on any supported device.
Learn more about Leanpub's ebook formats and where to read them
