Agile and Lean Program Management
$30.00
Minimum price
$35.00
Suggested price
Agile and Lean Program Management
Scaling Collaboration Across the Organization
About the Book
Scale collaboration, not process.
If you’re trying to use agile and lean at the program level, you’ve heard of several approaches, all about scaling processes. If you duplicate what one team does for several teams, you get bloat, not delivery. Instead of scaling the process, scale everyone's collaboration.
With autonomy, collaboration, and exploration, teams and program level people can decide how to apply agile and lean to their work.
Learn to collaborate around deliverables, not meetings. Learn which measurements to use and how to use those measures to help people deliver more of what you want (value) and less of what you don’t want (work in progress). Create an environment of servant leadership and small-world networks. Learn to enable autonomy, collaboration, and exploration across the organization and deliver your product.
Scale collaboration with agile and lean program management and deliver your product.
About the Author
Packages
The Book
PDF
EPUB
WEB
English
$30.00
Minimum price
$35.00
Suggested price
5-Pack of the Book, Agile and Lean Program Management
Buy a 5-pack for your team.
PDF
EPUB
WEB
English
$100.00
Minimum price
$150.00
Suggested price
Table of Contents
- Praise Quotes
- Acknowledgments
- Foreword
- Introduction
-
1. Defining Agile and Lean Program Management
- 1.1 Review the Twelve Principles of Agile Software Development
- 1.2 Review the Seven Lean Principles
- 1.3 Agile and Lean Together Create Adaptive Programs
- 1.4 A Program Is a Strategic Collection of Several Projects
- 1.5 Program Management Facilitates the Program to Release
- 1.6 Program Management Coordinates the Business Value
- 1.7 Agile Program Management Scales Collaboration
- 1.8 Agile and Lean Effect Change at the Program Level
- 1.9 What Program Managers Do
- 1.10 Take a Product Perspective
- 1.11 Principles of Agile and Lean Program Management
-
2. Consider Your Program Context
- 2.1 Cynefin Helps with Decisions
- 2.2 Understand Your Product’s Complexity
- 2.3 Know Which Program Teams You Need
- 2.4 The Core Team Provides Business Leadership and Value
- 2.5 Do You Need a Core Team?
- 2.6 Principles of Consider Your Program Context
-
3. Organize Your Program Teams
- 3.1 Create Your Core Team
- 3.2 Beware of Forgetting Core Team Members
- 3.3 The Product Owner Role Is Key to the Program’s Success
- 3.4 Organize the Software Program Team
- 3.5 Don’t Manage More than One Program Team Yourself
- 3.6 Principles of Organizing Your Program Teams
-
4. Start Your Program Right
- 4.1 A Program Charter Sets the Strategy
- 4.2 Develop the Program Charter with the Core Team
- 4.3 We Can’t Afford the Travel
- 4.4 Lead the Program Chartering Effort
- 4.5 Create Your Own Program Charter Template
- 4.6 Iterate on the Program Charter and Plans
- 4.7 Create the Agile Roadmap
- 4.8 Create the Big Picture Roadmap
- 4.9 Principles of Start Your Program Right
-
5. Use Continuous Planning
- 5.1 Differentiate Between Internal and External Releases
- 5.2 What Do You Want to Release This Month?
- 5.3 Create Minimum Releasables
- 5.4 Plan for External Releases
- 5.5 Deliverable and Rolling Wave Planning Helps
- 5.6 Small is Beautiful for Programs
- 5.7 How Often Can You Replan?
- 5.8 Separate the Product Roadmap from the Project Portfolio
- 5.9 Ways to Rank Items in the Roadmap or Backlogs
- 5.10 Decide How You Will Evaluate Value
- 5.11 Update the Roadmaps Often
- 5.12 Principles of Continuous Planning
-
6. Create an Environment of Delivery
- 6.1 Visualize Program Team Work
- 6.2 Keep the Program Team Work Small
- 6.3 How Features Flow Through Teams
- 6.4 How Often Can You Release Your Product?
- 6.5 Release Internally, Even with Hardware
- 6.6 Are You Integrating Chunks or Products From Others?
- 6.7 Manage the Risks of Integration from Other Vendors
- 6.8 Create a Culture of Delivery Throughout the Program
- 6.9 Principles of Create an Environment of Delivery
-
7. Encourage Autonomy, Collaboration, and Exploration
- 7.1 Software is Learning, Not Construction
- 7.2 Scaling Agile Means Scaling Collaborative Practices
- 7.3 Create Autonomous Feature Teams
- 7.4 Create Small-World Networks to Optimize Learning
- 7.5 Communities of Practice Create Connection and Collaboration
- 7.6 Avoid Hierarchical Titles
- 7.7 Continuous Integration and Testing Supports Collaboration
- 7.8 Beware of Technical Debt
- 7.9 Invite People to Experiment
- 7.10 Principles of Encourage Autonomy, Collaboration, and Exploration
-
8. Conduct Useful Meetings for Your Program
- 8.1 Explaining Status: Do Not Use Standups at the Program Level
- 8.2 Define a Rhythm for Your Program Team
- 8.3 Organize Your Program Team Meetings
- 8.4 Program Team Meetings Solve Problems
- 8.5 Retrospect at the Program Team Level
- 8.6 Principles for Conduct Useful Meetings for Your Program
-
9. Estimating Program Schedule or Cost
- 9.1 Does Your Organization Want Resilience or Prediction?
- 9.2 Ask These Questions Before Estimating
- 9.3 Targets Beat Estimates
- 9.4 Generate an Estimate with a Percentage Confidence
- 9.5 Present Your Estimate as a Prediction
- 9.6 Spiral in on an Estimate
- 9.7 Supply a Three-Date Estimate
- 9.8 Do You Really Need an Estimate?
- 9.9 Beware of These Program Estimation Traps
- 9.10 Estimation Do’s and Don’ts for Program Managers
- 9.11 Principles of Estimating Schedule or Cost
-
10. Useful Measurements in an Agile and Lean Program
- 10.1 What Measurements Will Mean Something to Your Program?
- 10.2 Never Use Team-Based Measurements for a Program
- 10.3 Measure by Features, Not by Teams
- 10.4 Measure Completed Features
- 10.5 Measure the Product Backlog Burnup
- 10.6 Measure the Time to Your Releasable Deliverable
- 10.7 Measure Release Frequency
- 10.8 Measure Build Time
- 10.9 Other Potential Measurements
- 10.10 Measure Performance or Reliability Release Criteria
- 10.11 How to Answer the “When Will You Be Done/How Much Will Your Program Cost” Question
- 10.12 Principles
-
11. Develop Your Servant Leadership
- 11.1 Program Managers No Longer “Drive” the Program
- 11.2 Consider Your Servant Leadership
- 11.3 How Servant Leaders Work
- 11.4 Some People Don’t Want Servant Leadership
- 11.5 Welcome Bad News
- 11.6 Use the Growth Mindset
- 11.7 Ask For the Results You Want
- 11.8 Principles of Develop Your Servant Leadership:
-
12. Shepherd the Agile Architecture
- 12.1 Architects Write Code
- 12.2 Many Developers Become Architects
- 12.3 Encourage Iterative and Incremental Architecture
- 12.4 Architects Can Help Expose Risks
- 12.5 What the Program Architect Accomplishes Daily
- 12.6 Architecture is a Social Activity
- 12.7 Problems You May Encounter With Architecture
- 12.8 Break the Architecture with Purpose
- 12.9 Principles of Shepherd the Agile Architecture
-
13. Solve Program Problems
- 13.1 Ask For the Problems or Impediments First
- 13.2 People on the Core Team Don’t Deliver What They Promise
- 13.3 Your Product Owners Have Feature-itis
- 13.4 People on Teams Are Multitasking
- 13.5 How to Start a Program With More People Than You Need
- 13.6 Principles of Solve Program Problems
-
14. Integrating Hardware Into Your Program
- 14.1 Hardware Risks Are Different Than Software Risks
- 14.2 Understand Cost and Value for Hardware
- 14.3 Understand Each Part’s Value
- 14.4 See the Work
- 14.5 Design Incrementally and Iteratively
- 14.6 Use Continuous Design Review
- 14.7 Integrate Hardware Often
- 14.8 Manage Hardware Risks
- 14.9 Develop the Software Before the Hardware Is Available
- 14.10 Principles of Integrating Hardware Into Your Program
-
15. Troubleshooting Agile Team Issues
- 15.1 The Teams Are Not Feature Teams
- 15.2 Teams Think They Are Agile, But They Are Not
- 15.3 The Teams Have Dependencies on Other Teams
- 15.4 Your Features Span Several Iterations
- 15.5 You Don’t Have Frequent-Enough Deliverables
- 15.6 Teams Don’t Finish When They Say They Are Done
- 15.7 Principles of Troubleshooting Agile Team Issues
-
16. Integrating Agile and Not-Agile Teams in Your Program
- 16.1 Waterfall Teams Are Part of Your Program
- 16.2 You Have Teams that Produce Incrementally, But Not in an Agile Way
- 16.3 You Have Teams that Prototype and Don’t Complete Features
- 16.4 Principles of Integrating Agile and Not-Agile Teams in Your Program
-
17. What to Do If Agile and Lean Are Not Right for You
- 17.1 Try an Incremental Life Cycle
- 17.2 Organize by Feature Team
- 17.3 Learn to Release Interim Deliverables
- 17.4 Learn How to Reduce Batch Size With a Large Program
- 17.5 Try Release Trains
- 17.6 Principles for What to Do if Agile and Lean Are Not Right for You
- Annotated Bibliography
- Glossary
- More from Johanna
About the Publisher
This book is published on Leanpub by Practical Ink
Johanna Rothman's books on leanpub. Practical, frank, and often humorous tips you can put to work right now.
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.
See full terms
80% Royalties. Earn $16 on a $20 book.
We pay 80% royalties. That's not a typo: you earn $16 on a $20 sale. If we sell 5000 non-refunded copies of your book or course for $20, you'll earn $80,000.
(Yes, some authors have already earned much more than that on Leanpub.)
In fact, authors have earnedover $12 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
