Agile And Lean Program Management Scaling Collaboration Across The Organization Johanna Rothman

Agile And Lean Program Management Scaling
Collaboration Across The Organization Johanna
Rothman download
https://ebookbell.com/product/agile-and-lean-program-management-
scaling-collaboration-across-the-organization-johanna-
rothman-5322920
Explore and download more ebooks at ebookbell.com

Here are some recommended products that we believe you will be
interested in. You can click the link to download.
Scaling Scrum Across Modern Enterprises Implement Scrum And Leanagile
Techniques Across Complex Products Portfolios And Programs In Large
Organizations 1st Edition Cecil Rupp
https://ebookbell.com/product/scaling-scrum-across-modern-enterprises-
implement-scrum-and-leanagile-techniques-across-complex-products-
portfolios-and-programs-in-large-organizations-1st-edition-cecil-
rupp-11751066
Agile Software Requirements Lean Requirements Practices For Teams
Programs And The Enterprise Agile Software Development Series 1st
Edition Dean Leffingwell
https://ebookbell.com/product/agile-software-requirements-lean-
requirements-practices-for-teams-programs-and-the-enterprise-agile-
software-development-series-1st-edition-dean-leffingwell-2536626
Agile And Lean Serviceoriented Development Foundations Theory And
Practice 1st Edition Xiaofeng Wang
https://ebookbell.com/product/agile-and-lean-serviceoriented-
development-foundations-theory-and-practice-1st-edition-xiaofeng-
wang-4633574
Agile And Lean Concepts For Teaching And Learning Bringing
Methodologies From Industry To The Classroom 1st Ed David Parsons
https://ebookbell.com/product/agile-and-lean-concepts-for-teaching-
and-learning-bringing-methodologies-from-industry-to-the-
classroom-1st-ed-david-parsons-7329090

Lean And Agile Software Development 5th International Conference Lasd
2021 Virtual Event January 23 2021 Proceedings Adam Przybyek
https://ebookbell.com/product/lean-and-agile-software-development-5th-
international-conference-lasd-2021-virtual-event-
january-23-2021-proceedings-adam-przybyek-50334488
Lean And Agile Software Development 6th International Conference Lasd
2022 Virtual Event January 22 2022 Proceedings Adam Przybyek
https://ebookbell.com/product/lean-and-agile-software-development-6th-
international-conference-lasd-2022-virtual-event-
january-22-2022-proceedings-adam-przybyek-37765974
Lean And Agile Project Management How To Make Any Project Better
Faster And More Cost Effective 1st Edition Terra Vanzant Stern
https://ebookbell.com/product/lean-and-agile-project-management-how-
to-make-any-project-better-faster-and-more-cost-effective-1st-edition-
terra-vanzant-stern-5744106
Lean And Agile Project Management How To Make Any Project Better
Faster And More Cost Effective Second Edition Second Terra Vanzant
Stern
https://ebookbell.com/product/lean-and-agile-project-management-how-
to-make-any-project-better-faster-and-more-cost-effective-second-
edition-second-terra-vanzant-stern-11799938
Agile Readiness Four Spheres Of Lean And Agile Transformation New
Edition Thomas P Wise
https://ebookbell.com/product/agile-readiness-four-spheres-of-lean-
and-agile-transformation-new-edition-thomas-p-wise-5104616

Agile and Lean Program
Management
Scaling Collaboration Across the
Organization
Johanna Rothman
No part of this book may be reproduced or transmitted in any
form or by any means, electronic or mechanical, including
photocopying, recording or by any information storage and
retrieval system, without written permission from the author.
Every precaution was taken in the preparation of this book.
However, the author and publisher assumes no responsibility for
errors or omissions, or for damages that may result from the use of
information contained in this book.
Many of the designations used by manufacturers and sellers to
distinguish their products are claimed as trademarks. Where those
designations appear in this book, and Practical Ink was aware of a
trademark claim, the designations have been printed in initial

capital letters or in all capitals.
© 2016 Johanna Rothman

Tweet This Book!
Please help Johanna Rothman by spreading the word about this
book on Twitter!
The suggested hashtag for this book is #agileprogrammanagement.
Find out what other people are saying about the book by clicking
on this link to search for this hashtag on Twitter:
https://twitter.com/search?q=#agileprogrammanagement

For my family. Thank you for your support.

Contents
Praise Quotes . . . . . . . . . . . . . . . . . . . . . . . . . i
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . iv
Foreword . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . vii
1. Defining Agile and Lean Program Management . . . 1
1.1 Review the Twelve Principles of Agile Software
Development . . . . . . . . . . . . . . . . . . . . 3
1.2 Review the Seven Lean Principles . . . . . . . . . 4
1.3 Agile and Lean Together Create Adaptive Programs 4
1.4 A Program Is a Strategic Collection of Several
Projects . . . . . . . . . . . . . . . . . . . . . . . 5
1.5 Program Management Facilitates the Program to
Release . . . . . . . . . . . . . . . . . . . . . . . 6
1.6 Program Management Coordinates the Business
Value . . . . . . . . . . . . . . . . . . . . . . . . 6
1.7 Agile Program Management Scales Collaboration 7
1.8 Agile and Lean Effect Change at the Program Level 9
1.9 What Program Managers Do . . . . . . . . . . . . 9
1.10 Take a Product Perspective . . . . . . . . . . . . . 10
1.11 Principles of Agile and Lean Program Management 11
2. Consider Your Program Context . . . . . . . . . . . . 12

CONTENTS
2.1 Cynefin Helps with Decisions . . . . . . . . . . . 12
2.2 Understand Your Product’s Complexity . . . . . . 16
2.3 Know Which Program Teams You Need . . . . . . 18
2.4 The Core Team Provides Business Leadership and
Value . . . . . . . . . . . . . . . . . . . . . . . . 23
2.5 Do You Need a Core Team? . . . . . . . . . . . . 24
2.6 Principles of Consider Your Program Context . . . 25
3. Organize Your Program Teams . . . . . . . . . . . . . 26
3.1 Create Your Core Team . . . . . . . . . . . . . . . 26
3.2 Beware of Forgetting Core Team Members . . . . 28
3.3 The Product Owner Role Is Key to the Program’s
Success . . . . . . . . . . . . . . . . . . . . . . . 29
3.4 Organize the Software Program Team . . . . . . . 31
3.5 Don’t Manage More than One Program Team
Yourself . . . . . . . . . . . . . . . . . . . . . . . 33
3.6 Principles of Organizing Your Program Teams . . 34
4. Start Your Program Right . . . . . . . . . . . . . . . . 35
4.1 A Program Charter Sets the Strategy . . . . . . . 35
4.2 Develop the Program Charter with the Core Team 36
4.3 We Can’t Afford the Travel . . . . . . . . . . . . 37
4.4 Lead the Program Chartering Effort . . . . . . . . 38
4.5 Create Your Own Program Charter Template . . . 39
4.6 Iterate on the Program Charter and Plans . . . . . 45
4.7 Create the Agile Roadmap . . . . . . . . . . . . . 46
4.8 Create the Big Picture Roadmap . . . . . . . . . . 48
4.9 Principles of Start Your Program Right . . . . . . 50
5. Use Continuous Planning . . . . . . . . . . . . . . . . 52
5.1 Differentiate Between Internal and External Re-
leases . . . . . . . . . . . . . . . . . . . . . . . . 52
5.2 What Do You Want to Release This Month? . . . 53
5.3 Create Minimum Releasables . . . . . . . . . . . 54
5.4 Plan for External Releases . . . . . . . . . . . . . 56

CONTENTS
5.5 Deliverable and Rolling Wave Planning Helps . . 57
5.6 Small is Beautiful for Programs . . . . . . . . . . 58
5.7 How Often Can You Replan? . . . . . . . . . . . . 59
5.8 Separate the Product Roadmap from the Project
Portfolio . . . . . . . . . . . . . . . . . . . . . . . 61
5.9 Ways to Rank Items in the Roadmap or Backlogs . 62
5.10 Decide How You Will Evaluate Value . . . . . . . 67
5.11 Update the Roadmaps Often . . . . . . . . . . . . 68
5.12 Principles of Continuous Planning . . . . . . . . . 68
6. Create an Environment of Delivery . . . . . . . . . . 70
6.1 Visualize Program Team Work . . . . . . . . . . . 70
6.2 Keep the Program Team Work Small . . . . . . . 72
6.3 How Features Flow Through Teams . . . . . . . . 73
6.4 How Often Can You Release Your Product? . . . . 74
6.5 Release Internally, Even with Hardware . . . . . . 75
6.6 Are You Integrating Chunks or Products From
Others? . . . . . . . . . . . . . . . . . . . . . . . 77
6.7 Manage the Risks of Integration from Other Vendors 78
6.8 Create a Culture of Delivery Throughout the Pro-
gram . . . . . . . . . . . . . . . . . . . . . . . . . 80
6.9 Principles of Create an Environment of Delivery . 80
7. Encourage Autonomy, Collaboration, and Exploration 81
7.1 Software is Learning, Not Construction . . . . . . 81
7.2 Scaling Agile Means Scaling Collaborative Practices 82
7.3 Create Autonomous Feature Teams . . . . . . . . 84
7.4 Create Small-World Networks to Optimize Learning 85
7.5 Communities of Practice Create Connection and
Collaboration . . . . . . . . . . . . . . . . . . . . 87
7.6 Avoid Hierarchical Titles . . . . . . . . . . . . . . 88
7.7 Continuous Integration and Testing Supports Col-
laboration . . . . . . . . . . . . . . . . . . . . . . 90
7.8 Beware of Technical Debt . . . . . . . . . . . . . 92
7.9 Invite People to Experiment . . . . . . . . . . . . 93

CONTENTS
7.10 Principles of Encourage Autonomy, Collabora-
tion, and Exploration . . . . . . . . . . . . . . . . 93
8. Conduct Useful Meetings for Your Program . . . . . 95
8.1 Explaining Status: Do Not Use Standups at the
Program Level . . . . . . . . . . . . . . . . . . . 96
8.2 Define a Rhythm for Your Program Team . . . . . 97
8.3 Organize Your Program Team Meetings . . . . . . 101
8.4 Program Team Meetings Solve Problems . . . . . 103
8.5 Retrospect at the Program Team Level . . . . . . . 106
8.6 Principles for Conduct Useful Meetings for Your
Program . . . . . . . . . . . . . . . . . . . . . . . 107
9. Estimating Program Schedule or Cost . . . . . . . . . 108
9.1 Does Your Organization Want Resilience or Pre-
diction? . . . . . . . . . . . . . . . . . . . . . . . 109
9.2 Ask These Questions Before Estimating . . . . . . 110
9.3 Targets Beat Estimates . . . . . . . . . . . . . . . 111
9.4 Generate an Estimate with a Percentage Confidence 111
9.5 Present Your Estimate as a Prediction . . . . . . . 115
9.6 Spiral in on an Estimate . . . . . . . . . . . . . . 116
9.7 Supply a Three-Date Estimate . . . . . . . . . . . 117
9.8 Do You Really Need an Estimate? . . . . . . . . . 118
9.9 Beware of These Program Estimation Traps . . . . 118
9.10 Estimation Do’s and Don’ts for Program Managers 120
9.11 Principles of Estimating Schedule or Cost . . . . . 122
10. Useful Measurements in an Agile and Lean Program 123
10.1 What Measurements Will Mean Something to
Your Program? . . . . . . . . . . . . . . . . . . . 124
10.2 Never Use Team-Based Measurements for a Program 124
10.3 Measure by Features, Not by Teams . . . . . . . . 126
10.4 Measure Completed Features . . . . . . . . . . . . 128
10.5 Measure the Product Backlog Burnup . . . . . . . 129
10.6 Measure the Time to Your Releasable Deliverable 132

CONTENTS
10.7 Measure Release Frequency . . . . . . . . . . . . 132
10.8 Measure Build Time . . . . . . . . . . . . . . . . 133
10.9 Other Potential Measurements . . . . . . . . . . . 133
10.10 Measure Performance or Reliability Release Criteria 136
10.11 How to Answer the “When Will You Be Done/How
Much Will Your Program Cost” Question . . . . . 137
10.12 Principles . . . . . . . . . . . . . . . . . . . . . . 139
11. Develop Your Servant Leadership . . . . . . . . . . . 140
11.1 Program Managers No Longer “Drive” the Program 140
11.2 Consider Your Servant Leadership . . . . . . . . . 141
11.3 How Servant Leaders Work . . . . . . . . . . . . 142
11.4 Some People Don’t Want Servant Leadership . . . 143
11.5 Welcome Bad News . . . . . . . . . . . . . . . . . 145
11.6 Use the Growth Mindset . . . . . . . . . . . . . . 148
11.7 Ask For the Results You Want . . . . . . . . . . . 148
11.8 Principles of Develop Your Servant Leadership: . . 150
12. Shepherd the Agile Architecture . . . . . . . . . . . . 151
12.1 Architects Write Code . . . . . . . . . . . . . . . 152
12.2 Many Developers Become Architects . . . . . . . 155
12.3 Encourage Iterative and Incremental Architecture 155
12.4 Architects Can Help Expose Risks . . . . . . . . . 157
12.5 What the Program Architect Accomplishes Daily 158
12.6 Architecture is a Social Activity . . . . . . . . . . 160
12.7 Problems You May Encounter With Architecture . 161
12.8 Break the Architecture with Purpose . . . . . . . 163
12.9 Principles of Shepherd the Agile Architecture . . . 164
13. Solve Program Problems . . . . . . . . . . . . . . . . . 166
13.1 Ask For the Problems or Impediments First . . . . 166
13.2 People on the Core Team Don’t Deliver What
They Promise . . . . . . . . . . . . . . . . . . . . 168
13.3 Your Product Owners Have Feature-itis . . . . . . 168
13.4 People on Teams Are Multitasking . . . . . . . . . 170

CONTENTS
13.5 How to Start a Program With More People Than
You Need . . . . . . . . . . . . . . . . . . . . . . 171
13.6 Principles of Solve Program Problems . . . . . . . 173
14. Integrating Hardware Into Your Program . . . . . . . 175
14.1 Hardware Risks Are Different Than Software Risks 175
14.2 Understand Cost and Value for Hardware . . . . . 176
14.3 Understand Each Part’s Value . . . . . . . . . . . 178
14.4 See the Work . . . . . . . . . . . . . . . . . . . . 180
14.5 Design Incrementally and Iteratively . . . . . . . 183
14.6 Use Continuous Design Review . . . . . . . . . . 183
14.7 Integrate Hardware Often . . . . . . . . . . . . . 184
14.8 Manage Hardware Risks . . . . . . . . . . . . . . 185
14.9 Develop the Software Before the Hardware Is
Available . . . . . . . . . . . . . . . . . . . . . . 186
14.10 Principles of Integrating Hardware Into Your Pro-
gram . . . . . . . . . . . . . . . . . . . . . . . . . 189
15. Troubleshooting Agile Team Issues . . . . . . . . . . 190
15.1 The Teams Are Not Feature Teams . . . . . . . . 190
15.2 Teams Think They Are Agile, But They Are Not . 194
15.3 The Teams Have Dependencies on Other Teams . 200
15.4 Your Features Span Several Iterations . . . . . . . 203
15.5 You Don’t Have Frequent-Enough Deliverables . . 203
15.6 Teams Don’t Finish When They Say They Are Done 204
15.7 Principles of Troubleshooting Agile Team Issues . 206
16. Integrating Agile and Not-Agile Teams in Your Pro-
gram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
16.1 Waterfall Teams Are Part of Your Program . . . . 208
16.2 You Have Teams that Produce Incrementally, But
Not in an Agile Way . . . . . . . . . . . . . . . . 210
16.3 You Have Teams that Prototype and Don’t Com-
plete Features . . . . . . . . . . . . . . . . . . . . 210

CONTENTS
16.4 Principles of Integrating Agile and Not-Agile Teams
in Your Program . . . . . . . . . . . . . . . . . . 211
17. What to Do If Agile and Lean Are Not Right for You 212
17.1 Try an Incremental Life Cycle . . . . . . . . . . . 213
17.2 Organize by Feature Team . . . . . . . . . . . . . 216
17.3 Learn to Release Interim Deliverables . . . . . . . 217
17.4 Learn How to Reduce Batch Size With a Large
Program . . . . . . . . . . . . . . . . . . . . . . . 217
17.5 Try Release Trains . . . . . . . . . . . . . . . . . 218
17.6 Principles for What to Do if Agile and Lean Are
Not Right for You . . . . . . . . . . . . . . . . . . 221
Annotated Bibliography . . . . . . . . . . . . . . . . . . . 223
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
More from Johanna . . . . . . . . . . . . . . . . . . . . . . 231

Praise Quotes
What Readers Are Saying About
Agile and Lean Program Management: Scaling Collaboration
Across the Organization
“This is the book for everyone who is considering how to “scale”
their lean/agile processes to work in large programs. Johanna
provides straightforward and practical advice on how to go from
single project/simple product agile implementation to large, com-
plex programs while retaining the core of agility and lean thinking.
She takes us back to the fundamental principles of agile and lean
and shows how to use those principles as a foundation for true
organisational agility, building products that need multiple teams
with different interdependent streams of work while retaining the
adaptability and responsiveness that is at the core of lean and agile
thinking.”
—Shane Hastie, Chief Knowledge Engineer & Agile Practice Lead,
Software Education
“Johanna Rothman’s new book is the definitive guide to programme
management in the agile and lean world. I found it invaluable in
crystallising in my mind how to marry agile and lean principles to
programme management. It’s a book that you will turn to when
somebody asks you a tricky question that you know will be better
articulated by Johanna.”
—Owain Griffiths, Principal Consultant, ThoughtWorks
“In Agile and Lean Program Management, Johanna does a won-
derful job of blending tried and true concepts for modern software
program delivery with newer models and ideas. And, as always,
i

Praise Quotes ii
she does a great job providing practical, pragmatic approaches to
using the ideas she provides. A must-read for anyone who is either
responsible for or impacted by the planning or delivery of multi-
team software initiatives.”
—Matt Barcomb, Directing Principal, Tidal River Consulting
“Johanna has created an excellent guide to managing large (aka
enterprise) projects. By taking the large, often unwieldy, concepts
and placing them in an experienced agile/lean context, she makes
the information accessible and provides the roadmap you need to
keep your organization on track and effective.”
—Jared Richardson, Principal Consultant, Agile Artisans
“How do you scale Agile software practices (best suited for single
teams of 5-10 developers) to larger programmes spanning multiple
disciplines and multiple teams? This is the most useful description
I have seen: Johanna shows how you can apply the principles of
Lean and Agile software development with actionable, pragmatic
techniques to deliver the value your customers desire.”
—Ian Brockbank, Agile Architect and Program Manager, Cirrus
Logic, and blogger at www.badgertaming.net
“Agile and Lean Program Management provides the practical and
principled advice to make your large product efforts a success.
Johanna wisely avoids the confusion and misdirection of con-
temporary conversations around “scaling agile.” She also avoids
hierarchies, strict role definitions, and building a giant process
machine. This allows Agile and Lean Program Management to focus
on what’s really important for any large product effort: effective
communication, clear expectations, customer focus, collaboration,
and acting from principles. Johanna strikes an excellent balance
between the practical and the theoretical here—and achieves a
conversational tone even when diving into the latter. This book
feels like sitting down with a trusted colleague to chat and get some
guidance on ideas, patterns, and solutions.”

Praise Quotes iii
—Gary Pedretti, Agile Trainer and Owner, Sodoto Solutions
“Agile and Lean Program Management is a must-read for project
and program managers. Johanna weaves together deep personal
insights, pragmatic advice, and personal tips on how to influence
and motivate others towards agile program success. Concepts are
presented in a crisp, easy-to-read style that leaves you thinking
‘Of course! That is such a clear, simple approach!’ This is a book
which will surprise and inspire. And you will want to refer back to
it frequently as your agile program evolves.”
—Declan Whelan, Agile Coach, Leanintuit
“Read this book then gift it to your boss. Their boss will thank
you. Agile isn’t just about better programming, or better stand-
ups. There’s a whole lotta important stuff that goes on upfront,
before projects start executing, and it’s invisible to most people.
This beautifully written book shows how to do that work in an agile
way.”
—Clarke Ching, Author of Rolling Rocks Downhill, The Agile Busi-
ness Novel (that never mentions Agile)
“The real world presents uncomfortable challenges: non-agile teams
must be included in agile programs, features will have dependencies
across many teams and systems, people (even good people) will
fail to meet commitments, etc. This book provides a unique blend
of thought-provoking anecdotes and successful patterns for scaling
collaboration. This is a great read for program managers and leaders
in large organizations.”
—Catherine Swetel, Principal Consultant

Acknowledgments
I thank my Managing Product Development blog readers. Your
comments made my ideas better. I thank these people who read
and reviewed the book and provided me feedback: Matt Barcomb,
Arlo Belshee, Ian Brockbank, Clarke Ching, George Dinwiddie,
Paul Ellarby, Lior Friedman, Owain Griffiths, Matt Heusser, Gary
Pedretti, Catherine Swetel, Michael Vizdos, Rebecca Wirfs-Brock.
I thank my editors, Rebecca Airmet and Nancy Groth. I thank Karen
Billipp for the layout and Jean Jesensky for indexing the print book.
Cover art: © Csuzda | Dreamstime.com - Team Growth Photo
Cover: Lucky Bat Books.
iv

Foreword
I wish this book had been published the last time I ran a major
project; it is a pragmatic and action based, but in a way that is also
consistent with theory—something that is all too rare. The Agile
community, as a whole, is riddled with rigid methods imposed
with religious zeal to support training and certification programs.
In contrast this book understands that scaling Agile is about the
assembly of different tools, methods, and practices to achieve a
result within a specific context. It has a whole section on what to
do when Agile is not a cultural match for the organization. While it
is predicated on servant leadership, it recognizes that this does not
“mean you are a pushover.” Sometimes you have to remove team
members.
The early chapters do not mandate a process, and there are few
of the engineering-type diagrams that overprescribe and over-
structure what should be seen as a service delivery. Instead, they
ask a series of questions with a range of suggested responses de-
pending upon the answer. This is not a one-size-fits-all handbook,
but a many-things-might-work, think-before-you-act assembly ap-
proach. Critically, it does not run away from the idea that man-
agement is necessary. One of the early phrases I highlighted was:
“Some people call program management scaling agile. You could
call it that. The real name is program management.” Managing
a program is a mixture of strategic and tactical needs, and the
two need to co-exist and interact to create resilient and adaptive
solutions. By combining Lean and Agile with a basic understanding
of complexity (it uses my Cynefin framework), the book sets out
a roadmap by which a program can be a unique assembly of
appropriate methods and tools derived from multiple sources.
As the world requires shorter cycle delivery against increasingly
v

Foreword vi
poorly articulated needs, we need more of this deeply pragmatic
thinking. Scaling is not about grand frameworks geared to making
people comfortable and securing training revenues. It is about
sound advice, good questions, and adaptive and flexible manage-
ment. This book is a great contribution addressing that need and I
am grateful for the opportunity to write this Foreword.
Professor Dave Snowden
Chief Scientific Officer
Cognitive Edge

Introduction
We hear a lot of buzz about “scaling agile.”
Instead of “scaling agile,” consider “scale projects to a program.”
Program management is how we move from coordinating one
project’s work to coordinating the work of several projects in a
program. When your product requires you to collaborate across the
organization, you need agile and lean program management.
Program management is not a new idea. What might be new for
you is the application of servant leadership to the program manager
role. If you want to use agile and lean approaches, you, as a program
manager, serve the program. You trust people to do the right thing,
and manage by exception.
You use program management anytime you want to scale collabo-
rative teams across the organization. Here are some possibilities:
• You are a project manager, trying to corral a few teams
together, to release a product.
• You are a manager who needs several teams to collaborate on
one strategic objective.
• You need to have the hardware and software people work
together to release a product.
• You need Marketing or Sales or Training or some other
function(s) to work with the software people to release a
product.
You might have a difference circumstance for your program. All
programs have one thing in common—the people collaborate across
the organization to deliver the product. Whatever your product is,
you or your team alone can’t ensure that your product releases, no
matter how agile or lean you are, when your team says, “Done!”
vii

Introduction viii
Programs are strategic collections of projects with one business
objective. Program managers coordinate that one business objective
across the organization.
When you coordinate across the organization, you recognize the
need for the other teams—regardless of their function—to maintain
their autonomy in how they create their deliverables. For programs,
everyone comes together to serve the program’s needs. Everyone
optimizes for the program, not for their team.
Each program is unique. Some of you will have software-only
programs. Some of you will want to use this book for products
that include software, hardware, firmware, and mechanical com-
ponents. That’s why this book is based on principles, not mandates.
Principle-based agile and lean might also be new for you, too.
Remember, that if you duplicate what works in small projects to
larger programs, all you get is bloat. Bloat doesn’t deliver—at least,
not easily. Take the principles of agile and lean, and think, “How
can I apply these principles to my context?”
Whether you are a team member on a feature team, a core team
member, or the program manager, this book has something for you.
Why? Because the agile and lean program is a complex adaptive
system. Everyone has his or her own role to play. And, everyone in
the agile and lean program has to be aware of the entire rest of the
program. No one succeeds without everyone else succeeding.
This book will help you see how to use agile and lean approaches
to manage your program. Here’s to your success. Now, let’s start.

1. Defining Agile and Lean
Program Management
Imagine this scenario:
You’re the program manager for an entire product. You
arrive at work and check your email. You discover that
one of the feature teams found a Big Hairy problem,
but they fixed it with the help of another team. Did
you need to intervene? No. Neither did the software
program manager. Yes, your program is large enough—
18 feature teams—that you need a software program
manager also.
You’re meeting with the core team today. Ellie, the
Marketing Communications rep to the core team has
been working on her deliverables for a couple of weeks.
The feature teams know they have to provide per-
formance information so MarComm can finish their
glossies. MarComm knows their deliverables are key
to a successful product launch.
Once you explained how to set up a kanban in Mar-
Comm, they all got “kanban fever.” Well, it seems
that way. They love watching those stickies move
across the board. The core team understands how their
deliverables intersect with everyone else’s deliverables
now, and why it’s so critical that their parts are com-
plete and done when they commit to dates. Everyone
on the core team is talking about “done.” “We sound
just like the software teams,” they say.
1

Defining Agile and Lean Program Management 2
The program architect was concerned about the ar-
chitecture evolution just two months ago. He’d never
seen an architecture evolve. He’d always planned the
architecture in advance. Then the architecture evolved
anyway. You and the program product owner and the
software program manager all felt as if you talked him
“off the cliff.” He conceded, and was willing to try to
evolve the architecture.
Surprisingly enough, the product is simpler than he
thought—right now. He’s coding, for the first time in
years. He’s happy. So are the feature teams. They feel
as if they are part of the design thinking, not just taking
orders from some guy with his head in the clouds.
Senior management is happy with you, because every
month you demonstrate something real, even if it’s
small. It’s only been three months and you have a
release candidate. R&D has never been able to produce
something that fast. Three months into the program
and you have a working product that the company can
sell. Well, once MarComm finishes their deliverables.
Is this a fantasy? No. This is how agile and lean program manage-
ment works. In fact, with the exception of the kanban board, that is
how I worked in 1988 on a real product, in a real organization. Many
successful programs repeat these principles: build trust among the
teams on the program; deliver often to see feedback; build trust
across the organization.
Let’s review the agile and lean principles so you can consider how
to apply them to your program.

1.1 Review the Twelve Principles of Agile
Software Development
The list below paraphrases the twelve primary principles of agile
software development. See the source for the original principles at
the Agile Manifesto Principles.
1. Deliver early and often to satisfy the customer.
2. Welcome changing requirements.
3. Deliver working software frequently.
4. Business people and developers must work together.
5. Trust motivated people to do their jobs.
6. Face-to-face conversation is the most efficient and effective
method of conveying information.
7. Working software is the primary measure of progress.
8. Maintain a sustainable pace.
9. Continuous attention to technical excellence and good design
enhances agility.
10. Simplicity—the art of maximizing the amount of work not
done—is essential.
11. The best architectures, requirements, and designs emerge
from self-organizing teams.
12. Reflect and adjust at regular intervals.
The point of the agile principles is that you collaborate across the
organization, seeing working product as a way to work with the
customer and make sure you are on track. You work in a way that
enhances technical excellence so you can accommodate change. You
inspect and adapt as you proceed, on the product and the process,
so that you can fine-tune your team and product.

1.2 Review the Seven Lean Principles
In Lean Software Development: An Agile Toolkit, POP03, Mary and
Tom Poppendieck summarized their lean approach with these seven
principles.
1. Eliminate waste.
2. Amplify learning.
3. Decide as late as possible.
4. Deliver as fast as possible.
5. Empower the team.
6. Build integrity in.
7. See the whole.
Lean principles help you see the whole process (for a team or
a program or anything in-between). You consider when to make
decisions and learn as you proceed. Lean encourages you to see the
entire product.
Use the agile and lean principles as you manage risk and solve
problems in the program. Consider how you can apply them to your
program.
The principles help you understand how to use agile and lean on
your program.
1.3 Agile and Lean Together Create
Adaptive Programs
When you use agile and lean principles, you can create and steer an
adaptive, resilient program. When I use the word, “program,” from
now on, please think “agile and lean” or “adaptive.”

1.4 A Program Is a Strategic Collection of
Several Projects
A program is a collection of projects, where the value is in the
overall deliverable. Yes, each project may have a deliverable that’s
valuable. However, the value to the organization is when all the
projects get together and deliver their product. That is a concurrent
program. You may also have a serial program, such as delivering a
series of releases over a product’s lifetime.
Think of a smartphone as an example of a strategic collection of
several projects. One project might be the feature set that allows
the phone to make and answer a call. Another project could be the
feature set to access and leave voicemail. Another two feature sets
might be the accounting for the voice data and the download data.
The texting feature set would be another project. Do you see how
each set of features could be its own project?
Each of these projects might require one or more feature teams
working together. The teams work autonomously, however they
like, as long as they are agile or lean, delivering their completed
features often. Each project and team works in parallel. Each project
has its own rhythm and staff and backlog. The projects deliver a
working product as a program.
Beware of a collection of ranked backlogs with no strategic reason
behind the order. If there isn’t a larger business objective behind the
backlogs, it’s not a program. You might need to accomplish all that
work. And, if the ranked backlogs together don’t create a coherent
business value, where the entire product is more valuable than each
project, you don’t have a program.
Can you have waterfall teams with your agile and lean teams
and still have a successful program? It depends on whether the
waterfall teams have interdependencies with the agile and lean
teams. Make sure you read Integrating Agile and Not-Agile Teams
in Your Program.

Each program needs a coherent vision behind the program so you
can create a program charter. The charter helps the feature teams
take responsibility for their tradeoffs. We’ll talk more about this
in Start Your Program Right. With a program charter in place, the
feature teams won’t need to work up and then down a hierarchy.
Some people call program management “scaling agile.” You could
call it that. The real name is program management. In program
management, you scale agile and lean collaboration practices across
the entire program, so you can release a great product.
1.5 Program Management Facilitates
the Program to Release
Program management is the coordination and facilitation of all of
the work across the organization to release the product.
The job of the program manager is to coordinate the teams so they
understand enough about each other’s risks so they can deliver. The
program manager does not and cannot do this alone. The program
is all about collaboration.
Projects are tactical; they get the work done. The
program is strategic. It ties the projects together to
bring them to delivery.
1.6 Program Management Coordinates
the Business Value
I’ve seen—and I bet you have too—programs where the software
was all done except for one small piece. The product couldn’t release
because that piece was vital to the release. Or the software was

done but the marketing was not. Or the hardware was done, the
marketing was done, and the software was stuck.
If you employ agile approaches to programs, you get to see visible
progress (or lack thereof) at the end of each iteration or the end of
each feature in flow or as the teams create the product. You don’t
have to wait until the predicted or desired end of the program to
see the risk.
That’s one of the ways agile reduces technical and schedule risk.
The iterations or flow help you get to done across the entire
program. Each iteration helps you see how things fit together. The
demonstration at the end of an iteration (or at a milestone) shows
you where you have technical risk, which reduces schedule risk. In
general, incremental approaches reduce schedule risk and iterative
approaches reduce technical risk. Because agile combines both, you
reduce both kinds of risk. For more detail on life cycles, see Manage
It! Your Guide to Modern, Pragmatic Project Management, (ROT07).
If you use lean approaches to your program, you can reduce the
work in progress, which will allow you to maximize throughput.
A lean approach will enable you to see bottlenecks, reduce waste,
and see what is not getting done. You need both agile and lean for
a program.
You don’t have to release each iteration or feature to your cus-
tomers. You can decide when to release externally—that’s a business
decision. When you see completed work each feature or each
iteration is how you know you provide business value.
1.7 Agile Program Management Scales
Collaboration
In non-agile program management, project managers or functional
managers speak for their project teams or functional area. They
commit people, manage risks, and commit other resources, such

as money. Notice that there is no program-specific view of the
product or transparent coordination across the functional teams.
Those programs may not have a ranked product backlog.
In program management, there is no hierarchy. Everyone col-
laborates and coordinates across the cross-functional teams. This
collaboration avoids Coordination Chaos as in TIK14.
The program teams solve problems cross-functionally. That’s a huge
difference.
Instead of functional managers committing on behalf of functional
teams, feature teams commit to the program. The program team
has the responsibility for removing obstacles so that the program
delivers the business value of the program.
Lean thinking adds the holistic view to the program. When we
add lean, we empower teams and eliminate waste. We amplify
everyone’s learning to build integrity into the product by seeing
the work in progress, sharing decisions, and having a fine-grained
definition of done. This is critical, because the more people we have,
the more chances we have to learn and to make mistakes. If we take
a lean approach at the beginning, we start with principles that make
sense for building great products.
In the same way that good project management was never about
command-and-control, good program management is not com-
mand-and-control. Good program management is servant lead-
ership. Program management enables coordination: helping the
teams and projects to collaborate to deliver some specific business
objectives.
Once your program has more than two teams, or you need to
coordinate with multiple people across the organization, releasing
your product becomes much more difficult. Program management
helps you coordinate across the organization, so that everyone
focuses on the goal: releasing a great product that works.

1.8 Agile and Lean Effect Change at the
Program Level
Agile is about the ability to change by delivering running, tested
features that are valuable to the business and learning from that
work. Lean is about seeing the whole, the flow of your work,
building integrity into your work, and eliminating waste. If you
add the technical practices (which you must in a large program),
the program makes visible the values of simplicity, respect, and
courage. Everyone commits to their work. You create empowered
teams.
You will get increased speed as a byproduct if you have the ability
to change. You will get speed if you reduce your work in progress
(WIP) and waste.
No management can mandate agile and lean at the program level.
Feature teams who can adapt and work together with a product
focus create the agile and lean program.
As a result of transitioning to agile and lean in the teams, and using
adaptive program management, you will obtain better delivery-to-
market speed as a result.
1.9 What Program Managers Do
The program manager is the voice or the face of the program.
The program manager represents the program to the PMO (Project
Management Office) or to senior managers in the organization. As a
program manager, I reported to the Operations Committee, a team
of senior managers.
The program manager facilitates the collaboration across the orga-
nization. The program manager is a servant leader. Program man-
agement doesn’t drive anything to completion; program managers
enable the program participants to finish their work.

1.10 Take a Product Perspective
You may have noticed I have been talking about your “product.” You
might have applications that you refer to as “systems.” You might
integrate several systems from other vendors. Some of you might
have something else.
I take a product-centric view of things. I suggest you do, too. If you
think all the time, “Who is the customer for this?” you might have
some insights about how to use agile and lean to deliver.
“I Think ‘Product’ Now”
I used to think about systems or applications. I’ve been a
program manager doing in-house financial applications for
years.
When I started to think about “products” instead of “applica-
tions” a funny thing happened. Other people started talking
about product, too. The product owners on the program
started to talk about their customers differently. They started
to name their users, with specific personas. I did not expect
that to happen.
Our stories got smaller. Our feature teams produced more
value, because they got to done on smaller stories faster. All
because I started talking about “product,” not “application.”
—An experienced program manager
Okay. Now you know what an agile or lean program is. Let’s talk
about how you might organize your program.

1.11 Principles of Agile and Lean
Program Management
1. Take a product perspective. The principle is: “Business people
and developers must work together.”
2. Agile and lean approaches encourage a holistic approach
to the product where you can change more easily to meet
current needs. The principle is: “Welcome changing require-
ments. This is a competitive advantage.”
3. Program managers are servant leaders. The principles are:
“Build projects around motivated individuals,” “Trust them
to get the job done,” and “Empower the team.”

2. Consider Your Program
Context
You and all the members of your program will make multiple
decisions on a daily basis. The Cynefin Framework is a way of
thinking about your context with the intent of guiding your actions.
I use Cynefin to think about how I solve problems: Can we use
good practices that everyone else uses? Do we need to experiment
to know how to proceed? Do we have so many unknowns that we
don’t know where to start?
2.1 Cynefin Helps with Decisions
The Cynefin Framework (SNB07) is a sense-making framework you
can use to solve problems. Use it to guide your approach to your
program.
12

Consider Your Program Context 13
Cynefin Framework
Based on the fact you are working in a program, you are not in
the Obvious context. A program, by its very nature, is at least in
the Complicated context, because of the number of communication
paths.
If everyone is in a single physical location, you may be in the
Complicated context. In the Complicated context, you can see
straight cause-and-effect relationships among the different stresses
in your program. If all your teams are experienced agile or lean
teams, who know how to deliver small stories each day or so, you
might be in the Complicated context. You understand what your
unknowns are. You can use known and reasonable practices for
organizing and working on your agile program.
As soon as you and the people in your program are not in the same
location, you are no longer in the Complicated context. You have
moved into either the Complex or Chaotic context. That’s because
your communication will have delivery or communication lags and
other interferences. Problem causes or effects may be unclear and
even unknown, if only due to communication lags.

If people on your program are multitasking, or if you have people or
teams who can’t commit to the program, or if many of your feature
teams are new to agile, you are at least in the Complex context.
You may be in the Chaotic context. In either of these contexts, the
unknowns create many risks and potential problems.
In my experience, if you can say, “We have done work like this,
but never at this complexity or with this many teams, or never as
distributed as we are now,” you are in the Complex context. You
have many unknown unknowns. You will have to manage the risk
of those unknowns.
As you look at the Cynefin Framework, ask yourself: what context
reflects your reality? How will that context help you decide whether
you should sense, probe, or act as an experiment first?
If you are in the Complicated part of the framework, you need
experts to solve the problems in your program. I’m not talking
about experts that create bottlenecks by working alone. Instead,
develop a community of experts—maybe most of the people on your
program, working in their Communities of Practice—to help solve
the problems.
If you are in the Complex part of the framework, consider these
actions: What experiments will you use to probe, to discover your
unknowns? And, what problems can you solve to move the program
back to the Complicated part of the framework, where you can
know your challenges?
Cynefin is not a two-by-two matrix where you locate your program,
use that to make decisions, and never return to the framework.
Instead, especially with programs of nine teams or more, different
parts of the program will have different challenges. The more
unknowable the challenges, the more that part of the program is in
the Complex part of the framework. As the teams deliver features,
they learn more. That part of the program moves to the Complicated
part of the framework.

Sometimes, teams in the Complicated part of the framework finish
features. As they learn, they uncover a huge “gotcha.” That might
cause them to be in the Complex part of the framework until they
run some experiments to see what they can do.
As a program manager, how can you identify issues early when you
encounter Complex again? How can you help the program move
from Complex to Complicated?
There are no easy answers. There is no recipe. This is work. It’s the
reason why we need program management, to recognize and solve
problems across the organization.
The Cynefin Framework reveals why agile program management
can be difficult. As teams complete their features, the product
owners need to update the roadmap and the backlogs. It’s possible
the program will finish before expected. Completing—or not—other
projects or programs may affect the organization’s project portfolio.
Certainly, one team’s feature completion might affect the ability of
other teams to deliver.
Regardless of your context, a program is emergent. With emergent
projects, you can’t plan everything at the beginning. You can see a
roadmap, plan a little, and continue learning and adapting as you
proceed. You might want to keep the same vision of the product,
but teams (with their product owners) might select different work.
Or, as your customers/product owners see the product, they might
want to change the product direction.
If the teams don’t complete features on a short, regular basis, no one
can understand what the program status is. If the core team doesn’t
solve problems that allow the program to create a product, you have
plenty of risks, many of them unknown.
Manage by principles, not practices.

With your risks, consider principles for your program, not practices.
I could try to create a recipe for you, but that won’t work. Think and
recognize your context.
2.2 Understand Your Product’s
Complexity
Your program is unique. Your program may have complexity in a
variety of areas: architecture, pressure to release, where the people
sit in relationship to each other, the languages everyone uses, and
each team’s agility.
In my experience, the overall architecture of your product can drive
much of the complexity. The more complex the architecture and
the larger your program is, the more complexity you will have to
manage. Here are some program architectures I have seen.
Large Program, One Coherent Product
In this case, you have one large product. It’s not integrating other
products or systems. Your program creates the entire product. It’s
big with multiple feature teams, which is why you have complexity
in your program.
As an example, an operating system might look like one coherent

product. Maybe a large web-based store might look like one coher-
ent product.
Inter-related products are different. If you ever say, “Platform and
layered products,” you have an example of an inter-related product.
Inter-Related Product Program
In this case, you have a platform of common services with what feel
to the customer as separate products. The GUIs may have their own
look and feel, but the GUI is not common across your program’s
product.
As an example, a smartphone is an integrated system product. Each
app on the phone has its own GUI where you set the preferences
and use the app. Each app uses services from the phone’s operating
system.
Sometimes, inter-related products integrate other products into the
one product.
It’s more likely if you integrate other vendors’ products into your
own, that you have an integrated system program.

Integrated System Product Program
In this case, customers buy your entire product. The product still
has the platform of common services. However, you have one
coherent GUI that the products have to integrate with. You might
be integrating systems or hardware from vendors.
These programs tend to need programs of programs. Different
products will run on their own schedule. Unless your vendors are
also agile and lean, you may have to manage integration risks.
2.3 Know Which Program Teams You
Need
Every program needs the ability to work across the organization.
You might need a core team, the cross-functional business team that
has members from all around the organization. The core team helps
coordinate the efforts that make the entire product a successful
deliverable.

If you have more than two feature teams, you might also need a
software program team. The software program team helps deliver
the working software. The software program manager is a delegate
to the core program team. That means that the software program
manager must have a program team of his/her own. This is true for
a large program.
You, as a program manager, need to understand which program
teams you need. Does your program require both a core team and a
software program team? Do you need a core team program manager
and a software program team manager?
You can only manage one program team. One of the problems I
see in too many agile programs is that they have neither a core
team nor a software program team. They have many feature or
component teams. They might have Scrum-of-Scrum meetings, but
no real forum for solving the deep problems or managing the risks
that can occur across the organization.
Each program team has a responsibility to solve problems that the
teams it represents can’t solve by themselves. The program team,
whether it is a core team or a software program team, works across
the organization, solving problems and removing obstacles for the
program.

What Your Core Team Might Look Like
If you are coordinating and collaborating across the entire organi-
zation, you are managing or are a part of the core team. If you take
a look at the What Your Core Team Might Look Like, you can see
that there are plenty of potential participants on this program team.
Aside from the program manager, there is the software program
manager, the potential hardware program manager, the program
product owner, as well as the sales, deployment, legal, marketing,
finance, human resources, and investor relations project managers.
And those are only the people I could imagine. There might be other
or different people in your organization.
Do You Have A Process Program?
Sometimes, organizations run process improvement projects,
such as transitioning to agile, as if they are programs. That’s
fine. In this, your core team will look different. You might not
have feature teams in your program.

Know what kind of a program you have. Not all programs are
the same. Use a core team that makes sense for your program.
What Your Software Program Team Might Look Like
Take a look at What Your Software Program Team Might Look Like
to see a prototype composition.
Notice that the program product owner and the program architect
might work as a triad with the software program manager to make
risk decisions. Does this mean that the program product owner does
not work with the core program manager?
It depends. It depends on who needs the program product owner.
Maybe you need a product owner team, and the program product
owner works with the core team and the technical product owner
works with the software program owner. It depends on what your
program needs.
Look at the program architect. Your feature teams need their

own architects on their teams. Sally’s project—which is its own
program—needs its own architect. That architect better talk to
the program architect. And if there’s a hardware architect, that
architect better talk to the program architect. So you might need
a cross-functional community of practice architecture team, as
illustrated in the “communities of practice” architecture team.
If you are a program manager, first, are you on the core team?
If so, do you have everyone you need? Does that team have
responsibility for deployment? (I don’t care who has responsibility
for deployment, as long as someone does.)
If you are not on the core team, are you on the technical team that
works across the technology? Does this team have responsibility for
deployment? I’m being a little touchy about deployment because
I have consulted to programs where no one was responsible for
deployment and they only discovered it when I asked, “Who’s
responsible for deployment?” I thought I was being stupid because
I didn’t see it. No, no one had thought about it. Oops.
Why do you need all these program teams? The core team might
require a different rhythm than the software program team. Since
the core team often has senior managers or senior people on it, I
recommend the core team use kanban to reduce the WIP (work in
progress). The software program teams can use iterations if that
works for them. Maybe they also use kanban; it doesn’t matter. The
two program teams address different risks at different levels.
The core program team is much more strategic. Often program
managers at this level manage budgets and project portfolio issues.
They are the ones to say, “Wait a minute. The software program
can’t succeed. We need to merge these two products.” That’s a
project portfolio issue.
The software program team is more strategic than a given project,
but is not as likely to manage budget or a project portfolio issue.
Program management, especially for many teams (think more than

20 teams) is about making sure you have a product that delivers
the business value you want from all that effort. So the software
program will have its own risks and rhythm, which is separate from
the core team’s risks and rhythm.
If you are a program manager, make sure you know which team
you are trying to manage (coordinate and collaborate), so you can
be most effective. Remember, you can only manage one program
team. (See Don’t Manage More Than One Program Team Yourself
for more details.)
2.4 The Core Team Provides Business
Leadership and Value
The core team sets the agenda and the vision for the program. The
core team helps the feature teams when they need it, and stays out
of their way when they don’t need it. The feature teams provide
status to the core team, so that the core team can share status across
the organization. The core team can adapt their risk management,
including the program roadmap, if necessary.
Your core team delegates are essential to your program’s success.
Ask yourself—and maybe the people who could be on the core
team—these questions:
• Do you have the authority to commit to budget decisions for
this program? Can you approve spending?
• Do you have time to commit to this program?
• Are there people or project teams that you can commit to this
program?
• Can you commit other people or resources to this program?
• Can you commit to the success of this program?
When the core team members are committed to the program’s
success, they can solve problems more easily.

Here are the responsibilities of the core team before the program
starts:
• Write the program charter.
• Create the agile roadmap.
• Create the program backlog, the backlog of features.
This is what the core team does during the program:
• Iterate on the agile roadmap.
• Iterate on the program backlog, the backlog of features.
• Solve cross-functional business problems.
• Solve problems that escalate from the software program
team.
• Monitor product status and risks.
• Clear program obstacles for the teams.
• Decide when the product is ready to release.
The core team does all of this because they are responsible for the
business value of the program. Because the core team is cross-func-
tional, the people on the core team can help different departments
and projects understand how they are interdependent.
The core team embodies the principle of business people and
developers working together.
2.5 Do You Need a Core Team?
You might not need a core team if you have a small program. You
might need a software program team with a few cross-functional
people, such as the person who shepherds the product to release,
maybe called Deployment or Release.

Imagine you have a web-based product. Maybe you only have four
or five feature teams. Those feature teams want to know what
Marketing and Deployment are also doing—and they want to know
what all the software teams are doing, too. In that case, maybe you
can keep just one program team and have all the necessary people
on that team.
Try to keep the number of people on your program team to ten or
fewer. Otherwise, it’s difficult to make decisions.
If you have the core team and the software program team as a
mixed program team, be aware that you may have trouble solving
problems and managing risks. The people on the mixed program
team will want to solve problems at different levels, and you’ll have
too many people on your core team.
2.6 Principles of Consider Your Program
Context
1. Consider your complexity. If your organization wants to start
a brand new agile program on a highly complex architecture
with geographically distributed teams when you have not
succeeded with agile at the team level, your risks will be
different than if the entire organization has agile experience.
The principles are: “Amplify learning” and “See the whole.”
2. Define which program teams your program needs. The prin-
ciple is: “Business people and developers must work together.”
3. Consider how you will help your program team deliver what
the organization requires. The principle is: “Eliminate waste.”

3. Organize Your Program
Teams
Each program is unique. Once you understand your program con-
text, you can decide how to guide your program to success.
3.1 Create Your Core Team
Your core team are your allies across the organization. They are the
people who will help you move the product from an idea to a fully
completed and shippable product.
You need one person from each necessary function across the
organization, and not more than one person.
Back in What Your Core Team Might Look Like, you saw a picture
of a possible core team. You might not have a hardware program
manager, for example. Maybe you don’t need anyone from investor
relations to release your product.
No matter what, make sure that you have some form of deployment,
either in your core team or in the software program team. It doesn’t
matter which team that person sits on, as long as you have a
deployment person somewhere on a program team.
It doesn’t matter what you call the deployment person either:
Release Engineering, DevOps, IT, or something else. Make sure you
have someone whose responsibility is to make sure your product
successfully deploys.
Your core team needs people who can commit their time, and their
department’s time to solve problems, as well as budget. If you can
identify the specific person you need, that’s the best. If you only
26

Organize Your Program Teams 27
know the role, that’s okay. But you also need to know the level of
that role in the organization.
Make sure you ask the questions in The Core Team Provides
Business Leadership. That way, you know you have the right people
at the right level on the core team.
In the past, I have had problems gathering everyone on my core
teams. The sales guy didn’t want to commit to a biweekly meeting.
He was “too busy.” The MarComm woman was too frantic doing
other things. The corporate lawyer never answered his email.
I needed those people for a successful product release. Without
them, we couldn’t know if we had the right dates, if we all
understood the risks. We would be up the proverbial creek.
How could I make it worth their while to come to the core team
meetings?
I have done these things:
1. Asked a specific person by name. “Mary, can you please work
on my new program with me? I enjoyed working with you
on that last program. I’d like to do it again.” When you ask
a person by name for help, that person is more likely to say
yes. If you put out a request on email, everyone feels free to
ignore it.
2. Asked a senior manager to assign “the best person” in his
or her department. I’ve had this conversation with a se-
nior manager more than once: “John, you know that I’m
the program manager for the XYZ program, which is the
company’s #1 priority. I need someone from Training on
the core team. I need your best person, not just to represent
Training. That person will develop new training materials as
Software develops the product, and as Deployment gets ready
for release. We will be ready as an organization to release, all
on the same day. That’s why I need your very best person.”

I use the Voice of Reason, along with the Steely Eyed Glare
and a big smile. I almost always get what I ask for.
3. I use influence, where I think, “What will make it worthwhile
for this senior manager to give me what I want?” This is why
you need to know why the organization wants to start the
program. I have discussed the program’s deliverables with
an eye to the business benefit for the senior manager.
I always tell the members of the core team that we are the best
people in the organization to work on this product—that we can
collaborate and shepherd this product to its final release. That’s why
the organization chose us.
I believe this. Why else would the organization spend money on the
program?
3.2 Beware of Forgetting Core Team
Members
When I coach program managers, sometimes they discover they
have overlooked people or key players for the core team. Sometimes
they forget because the program is small and the core team is
rolled into the software program team. Sometimes it’s because the
program manager invites the correct people and they don’t respond
in a reasonable amount of time. Sometimes, there’s a power play at
work at a higher level in the organization. Sometimes, it’s another
reason.
Do you have some commonly “omitted” roles on your programs?
Review your core team members. Do you have everyone you need,
to release a product?
If not, ask people to participate, or enlist the senior manager in that
area to help you find the right person for your core team.

3.3 The Product Owner Role Is Key to
the Program’s Success
It doesn’t matter if we talk about the program product owner or a
product owner on a team. Each product owner has a key role to play
on a program.
The program product owner, sometimes known as the PPO, or
the delegate to the program team, shepherds the business value of
the roadmap and of the releases. The PPO represents the product
owners to the rest of the program team. The PPO is a servant
leadership position. Your organization might call the PPO a product
manager.
The product owner, sometimes known as the PO, is the person on
the feature team who understands what the customers want and
translates that understanding to stories. You may also need a subject
matter expert such as an architect or senior technical person to work
with the PO. The PO, or the PO team, or the PO and the program
architect assess which features to do first, the technical challenges
with those features, and the Cost of Delay for each feature.
If you have a highly complex product with many feature teams,
consider a product owner value team.
Different Teams

In this scenario, the feature team (product development team) im-
plements a feature. The product value team decides on the product
roadmap and ranks features—what to do when, for the program.
The project portfolio team decides when to commit to a project or
a program.
These teams work from their perspective—feature team, product, or
organization—when they make decisions.
The product owners across the program work as a product value
team, or a product owner team. When they work across the or-
ganization, they can limit the number of interdependencies and
continue to update the roadmap based on what the teams complete.
Anyone with product owner in his/her title must understand the
value of the feature under discussion, and the customer base for
this product. If a product owner doesn’t understand the customer
base for this product, the PO will not make good decisions based
on value. The PO will not be able to answer any of the questions
about risk, such as, “What do our customers need or want?” for this
product.
The product owner must also understand the product technology.
If the PO understands the technology, the team can explain, “We
can do things this way or that way.” Or, “If we implement this
feature first, we can save time on that feature second.” Or, “We can
implement the flow this way and save time for the user.” See the
discussion at Product Manager vs. Product Owner.
When the PO understands the customers and the technology, you
have a great PO. Without both, you miss the boat.
The product owners on the teams know where the product is. They
can see the product evolve every day. They have the responsibility
to make small decisions every day that help the product grow.
Use the intelligence of the product owners as a team to create and
update the agile roadmap. The smaller the features are, the easier
this is.

Random documents with unrelated
content Scribd suggests to you:

20. For office seekers? (Pertinacity)
The names of cities and their nicknames may also be used, thus:
Boston, "The Hub"; Philadelphia, "The City of Homes"; Detroit, "City
of the Straits"; Cincinnati, "Queen City of the West"; Chicago,
"Windy City," or "Garden City"; Buffalo, "Queen City"; Cleveland,
"Forest City"; Pittsburg, "Smoky City"; Washington, "City of
Magnificent Distances"; Milwaukee, "Cream City"; New York,
"Gotham"; Minneapolis, "Falls City"; St. Louis, "Mound City"; San
Francisco, "Golden Gate"; New Orleans, "Crescent City."

WHITE RIBBON SOCIABLE
Invitations should be similar to the following:
Yourself and friends are cordially invited to attend a
White Ribbon Sociable
given by the Y. W. C. T. U. at the home of the
President, Miss Blank,
Monday evening, September 10, 19—.
Have a small white ribbon bow tied on the corner of the card. Of
course all members of the society should wear their white ribbons.
All who serve on the reception committee should wear a large white
ribbon rosette. Also have a white ribbon quartet for the musical part
of the program, and have each one wear a large white ribbon bow
on the left breast. Have plenty of white flowers for decoration, also
use anything white that can be used in any way to help decorate.
Have a large bowl or white dish in centre of dining-table with small
white baby ribbons hanging over the edge, one for each guest you
expect. Tie to the end of each ribbon a small slip of paper bearing
instructions as to what each one is to do. Each guest is to pull out a
slip, see what he is to do, and then proceed to do it at once. Cover
the top of the dish neatly with white tissue paper. Wafers can be
served tied with narrow white ribbon, also coffee or cocoa, or if in
summer serve lemonade.
The following suggestions may be used for the slips of paper:
1. Act in pantomime a doctor's visit.
2. Make a dunce cap and put on head of dignified person.

3. Deliver an oration on George Washington.
4. Sing "Mary had a little lamb," in operatic style.
5. Draw a correct picture of a cow.
6. Tell a funny story.
7. Sing a lullaby to a sofa cushion.
8. Sing a comic song.
9. Compose a rhyme with four lines.
10. Tell a pathetic story.
11. Make a shadow picture of a man's head on the wall with the
hands.
12. Show how a small boy cries when a hornet stings him.
13. Sneeze in five different ways.
14. Shake hands with ten different persons in ten different styles.
15. Recite "The boy stood on the burning deck," in dramatic style.
16. Laugh ten varieties of laugh.
17. Imitate the sounds made by two cats fighting.
18. Show how a man acts when he is lost in Boston.
19. Smile ten different smiles.
20. Tip your hat in ten different ways to ten different people.
21. Show how a dude walks.
22. Auction off an overcoat.
23. Try to sell a book as if you were a book agent.
24. Show how a boy writes his first letter.
25. Name ten things you could do with a million dollars.

WHY WE NEVER MARRIED
An Evening's Entertainment to be Given by Seven Maids and Seven Bachelors
(Copyright, 1899, by the Curtis Publishing Company and republished
by courtesy of the Ladies' Home Journal)
Although this entertainment is here planned to include fourteen
people, the number of those who take part in it may, of course, be
reduced to as few or increased to as many as desired, either by
omitting one or more of the couples already provided for, or by
including more couples and composing additional verses for them.
The characters appear seated in a semicircle, a young man first,
then a young woman, and so on alternately, beginning at the right
as one faces the audience. Each one is dressed in a fashion
appropriate to the character represented. Starting with the first
young man at the right, each advances in turn to the front and
recites.
Number one says:

"Of all the girls that ever I knew,
I never saw one that I thought would do.
I wanted a wife that was nice and neat,
That was up to date, and that had small feet;
I wanted a wife that was loving and kind,
And that hadn't too much original mind;
I wanted a wife that could cook and sew,
And that wasn't eternally on the go;
I wanted a wife that just loved to keep house,
And that wasn't too timid to milk the cows;
I wanted a wife that was strikingly beautiful,
Intelligent, rich, and exceedingly dutiful.
That isn't so much to demand in a wife,
But still she's not found, though I've looked all my life."
Number two next recites:
"The only reason why I've never wed
Is as clear as the day, and as easily said:
Two lovers I had who'd have made me a bride,
But the trouble was just that I couldn't decide;
Whenever John came I was sure it was he
That I cared for most; but with Charlie by me,
My hands clasped in his, and his eyes fixed on mine,
'Twas as easy as could be to say, 'I'll be thine.'
Now tell me what was a poor maiden to do,
Who couldn't, to save her, make choice 'tween the two?
I dillied and dallied, and couldn't decide,
Till John, he got married, and Charlie, he died;
And that is the reason why I've never wed;
For how could I help it, as every one said,
When John, he was married, and Charlie was dead."
Number three now speaks:

"I have never proposed to any girl.
Was I to be caught in the snare of a curl,
And dangle through life in a dizzy whirl?
"Humph! I know too much for that by half!
I may look young, but I'm not a calf;
You can't catch a bird like me with chaff.
"I know their tricks, I know their arts,
I know how they scheme to capture hearts;
I know they can play a dozen parts.
"How do I know so much, you ask?
To reply to that isn't much of a task;
For if you must know, O madams and misters,
I'm the only brother of fourteen sisters."
Number four advances and says:

"My lovers came from near and far,
And sued before my feet;
They told me I was like a star;
They said that I was sweet;
And each one swore if I'd accept
His heart and eke his hand,
That he would be the happiest man
Throughout the whole broad land.
But one proud youth remained aloof,
And stood untouched, unmoved;
Oh, bitter fate! he was the one,
The only one I loved!
I tried on him each winning charm,
I put forth every art,
But all in vain; he turned away,
And took with him my heart.
This is the reason I am left
Alone upon the tree,
Like withered fruit, though not a pear;
Oh, would that I might be!"
Number five recites these lines:

"The only reason why I've never married
Is because all my plans for proposing miscarried;
I wouldn't propose till all was propitious,
Till I felt pretty sure that the signs were auspicious.
More than once I've been moved to propound the fond query,
'Won't you tell me you love me, my beautiful dearie?'
When just at that moment came something or other,
A ring at the bell, or a call from her mother,
Or the sudden approach of her infantile brother,
My words to arrest, my intentions to smother;
And once, when a few leading questions I'd asked,
She laughed as if jokes in my questions were masked;
I couldn't conceive what had caused her commotion,
But 'twas so disconcerting I gave up the notion;
Although I felt certain as certain could be,
That whatever she laughed at, it was not at me."
Number six then says:

"From my earliest years
I've had an intuition
That I was intended
To carry out a mission.
Whatever it might be
I hadn't the least notion,
But I searched for it faithfully
From ocean to ocean.
For a while I kept thinking
That I was surely meant
To preach to the heathen,
But I never was sent.
Then the surging thoughts and feelings
That upon me seemed to press
Surely proved beyond all question
That I was a poetess;
But the editors were cruel,
They were stonily unkind;
And their inappreciation
Drove the notion from my mind.
Now I'm sure that I'm a speaker;
'Tis my latest great impression;
And I'd like to prove it to you,
If I might without digression;
But whatever is my mission,
I've been certain all my life,
That 'tis something higher, nobler,
Than to be a slaving wife."
Number seven speaks thus:

"I used to call on Mary Jane
When I was seventeen;
And Mary Jane was fond of me,
Though I was rather green.
One day I told her why I came,
And what was my intent;
And then she said that I must go
And get her pa's consent.
Her pa, he was a mason rude,
Well used to handling bricks,
And when I came to talk with him
My courage went to sticks.
'K-kind sir, may I have M-Mary Jane?'
I asked with gasp and stutter;
Then came an earthquake, then a blank—
I went home on a shutter.
I never married Mary Jane,
The maid whom I'd selected;
The reason was because her pa—
Well, so to speak—objected."
Number eight next advances:
"I fully intended a bride to be,
But Richard and I could never agree;
He fussed at me daily in fault-finding mood,
And I picked at him though I knew it was rude;
He thought that a woman ought always to do
Just what her husband wanted her to,
And I was as set and decided as he,
That that way of life would never suit me;
And so we kept wrangling all summer and fall,
And at last we agreed not to marry at all;
And that is the reason you now find me here,
Feeling cheap, I admit, and I once was so dear."

Number nine speaks as follows:
"Could I give up all the pleasures
That a single man may claim?
Could I see my bachelor treasures
Sniffed at by a scornful dame?
Could I have my choice Havanas
Bandied all about the place,
Strewn around like cheap bananas,
Looked upon as a disgrace?
Could I bear to find a hairpin
Sticking in my shaving-mug?
Or a pair of high-heeled slippers
Lying on my Persian rug?
Would I want my meditations
Broken up by cries of fright
At a mouse or daddy-long-legs,
Or some other fearful sight?
No, I couldn't, and I wouldn't,
And I didn't, as you see;
Of every life, the bachelor's life
Is just the life for me."
Number ten says:

"My lovers were plenty
As plenty could be;
But of the whole number
Not one suited me;
John was too fat,
Joe was too thin,
And George, who'd have done,
Was without any 'tin';
Dick was a sinner,
And James was a saint,
Who, whenever I shocked him,
Looked ready to faint;
Charles was quite handsome,
The likeliest yet,
But he always was smoking
A vile cigarette;
That I'm very particular
'Tis easy to see,
Which all should remember
Who come to court me."
Number eleven now advances:
"First it was Carrie who claimed my heart,
And I thought from her I never would part;
Then it was Rose, with her winsome eyes
Of an azure as deep as the tropic skies;
And next it was Alice, so mild and meek;
I loved her fondly for nearly a week;
Then came Elizabeth's fickle reign,
And after her Mary and Kate and Jane;
A dozen more for a time held sway,
Sometimes for a month, sometimes for a day;
And yet I'm not married; for, truth to tell,
I could make no choice, I loved all so well."

Number twelve speaks thus:
"I never would marry
The best of men;
Though they've tried to persuade me
Again and again;
I know too well
What's good for me
To wed any man,
Whoever he be;
If he tells you he loves you,
He means to deceive you;
If he says he'll be faithful,
He's planning to leave you;
You may think him as meek
As ever was Moses;
You may think him as sweet
As a garden of roses;
You may think him as good
As good can be;
But just remember
One word from me;
Whatever they seem
To be or have been,
You just can't tell
One thing about men.
Number thirteen and number fourteen advance together, and the
former speaks first as follows:

"I've been in love with lots of girls,
A bachelor's life I hate;
I've all the time that I could want
To find and win a mate;
I've never come in contact with
A brick-objecting pa,
Or been deterred by brothers small
Or loudly calling ma;
I've never found it hard to choose
With whom I would be mated;
Oh, no, 'tis quite another cause—
I'm not appreciated;
I've popped the question o'er and o'er,
But if you will believe me,
There wasn't one of all of them
That I could get to have me.
And that is why I'm left alone,
Now love's young dream is gone,
To darn my hose and mend my clo'es
And sew my buttons on."
Then number fourteen says:

"My friends have all told you the reason why they
Keep on in a lonesome, old-maidenly way,
Without any husband to lighten their loads,
Without any helper to smooth the rough roads;
I, too, am unmarried, but not for the causes
That they have all stated in rhythmical clauses:
My lover didn't die,
And he never went away;
My father didn't stand
A moment in my way;
I've never quarreled once,
Nor been bothered to decide,
But I've got a first-class reason
Why I've never been a bride;
At any kind of mission
I wouldn't even glance;
The simple truth is this—
I've never had a chance;
Other folks, I s'pose, have had 'em,
But they've never come to me;
Though I don't see why they shouldn't,
For I'm willing as can be;
And all I've got to say is,
And I say it frank and free,
If you think I won't get married,
Just you question me and see."
At the close of number fourteen's recitation, all rise and stand in two
rows, facing each other, the ladies in one row and the gentlemen in
the other. The gentlemen then recite in concert as follows:

"Since we all are yet unmated,
And are getting on in years,
Why not now decide the matter
By dividing up in pairs?
If I ask you to accept me,
And my lonely life to bless,
Will you? Will you? Will you?"
Ladies in chorus:
"Yes!"
Each lady takes the arm of the gentleman facing her, and all walk off
to the music of the wedding march.

WIFE OF SANTA CLAUS
An Entertainment for the Sunday-School
The Sunday-school, school or club is assembled; the stage is
concealed by a curtain, and the Christmas tree, which is near the
stage, by another curtain or screen. The tree is decorated in the
usual manner, minus the gifts, which are concealed near the stage
ready to be delivered when the right time comes. The tree need not
be lighted until the closing of any preliminary exercises that have
been arranged. After lighting, the tree should be exposed to the
view of all. When the children have gazed at it for a few moments,
the superintendent or some other suitable person should come
forward, as if to distribute the gifts as usual. He should survey the
tree attentively and from different standpoints, and finally, with great
astonishment, exclaim:
"Why, what in the world does this mean? What strange thing is this?
What is the matter with my eyes? [Rubbing his eyes to see better.] I
can't see! As true as I live, I cannot see a single Christmas gift upon
this tree! Think of it, a Christmas tree with no presents! Am I
growing blind? [Rubbing his eyes again.]
"Do you see any? [Turning to any child near.] Well, I thought so! It is
too true, children, that although we have a Christmas tree, and a
fine one, too, there is not a single gift upon it; no, not even a little
one for a little bit of a girl! Now, this is altogether too bad of Santa
Claus to forget this Sunday-school—when we've gotten all ready for
him, too, lighted the tree and decorated it so beautifully! It isn't a bit
like him, either. He never did such a thing before. He can't have
forgotten us. The blessed old Saint wouldn't do that! Maybe his

reindeer are lame and he is slow in getting here. No! He would have
sent Jack Frost on ahead to tell us to wait. Let me think a moment.
It can't be that any of you children have been so naughty that he
thinks we don't deserve a visit from him, can it? No, no, that cannot
be; it is a mistake, somehow. It is very mysterious; I never heard of
the like before—no, never——
"Well, what are we going to do about it, anyway? Can't some one
speak up and explain this mystery, or at least tell us what to do to
celebrate Christmas?"
At this juncture the sound of sleigh-bells is heard at the back or side
of the stage, and a loud "Whoa!" and a shrill whistle. There is an
instant of bustling, crunching of ice, stamping and pawing of feet,
then the door bursts open suddenly, as if by a gust of wind, and a
nimble little fellow bounces in, clad all in red and flecked with tufts
of cotton on cap and shoulders to look like snow. He wears a high,
peaked cap of red with a bobbing tassel on the peak, and carries a
long thong whip, which he flourishes in time to the rhyme he chants:
"Ho for us! hey for us!
Please clear the way for us!
I'm Jack Frost from Icicle-land,
Driver of Santa's four-in-hand;
Though late you will ask no excuse."
With a flourish he draws back the curtain, announcing "Mrs. Santa
Claus!" There, with a mammoth pumpkin standing by her side, is
seen a beaming-faced little fat woman. She is dressed in a fur cloak,
or fur-lined circular turned wrong side out, an ermine poke bonnet,
made of white cotton-wool, with black worsted tails, and an
immense muff of the same. She steps forward, and in a dramatic
style delivers this address:
Mrs. Santa Claus's Address

"Good-evening to you, children dear;
I know you cannot guess
The reason I am here to-night,
And so I'll just confess
That I am Mrs. Santa Claus—
Old Santa Claus's wife;
You've never seen me here before,
I'm sure, in all your life.
"So if you'll listen patiently,
I'll tell the reason why
Old Santa could not come to-night,
And why instead came I;
He is so very busy now,
Has so many schools—you see
He can't find time to visit all,
And deck each Christmas tree.
"And so he said unto his wife:
'My faithful partner dear,
That Sunday-school's expecting me
To help keep Christmas cheer;
As I can't possibly reach there,
I'm disappointed quite;
I know that they will look for me
With shining eyes so bright!'
"I, Mrs. Santa, thus replied:
'Please let your better-half
Go visit that nice Sunday-school;
'Twill make the children laugh.'
This plan just suited Santa Claus;
He sent Jack Frost to drive;
He knew what fun 'twould be for me
Among you thus to arrive!

"And so, lest him you should forget,
That blessed, dear old fellow
The queerest Christmas gift sends you,
This pumpkin, big and yellow;
He hopes that when you cut it up
You'll quite delighted be,
To find the inside quite different
From what you're used to see.
"Now if the shell is not too hard
I'll cut it open wide,
That you may see with your own eyes
This curious inside. [She cuts it open.]
Ah, yes! we've found the inside now,
And so present to view
This fairy, who, from Wonderland,
Has come to visit you."
The fairy, a little girl dressed in white, with a wand, and wings, if
possible, skips out of the pumpkin and sings:
Fairy's Song
(Tune, "Little Buttercup")

"Yes I am a fairy, a genuine fairy,
And if you cannot tell why
I've come in this pumpkin, this big yellow pumpkin,
The reason to guess you may try.
"I bring you sweet tokens, yes, many fond tokens,
Of love and sweet friendship true;
From sisters and brothers, fathers and mothers,
And many dear friends who love you.
"So here are your presents, your own Christmas presents,
With which you may now deck your tree,
So please to remember the bright Christmas fairy,
The bright Christmas fairy you see.
"I wish you 'Merry Christmas,' a real merry Christmas,
And also a 'Happy New-Year;'
If you love one another, each sister and brother,
No harm from the fairies you'll fear."
The gifts are then distributed by the fairy, who appears to take them
from the inside of the pumpkin. Unless the children are too small,
and likely to be timid, they should go forward to receive their gifts
when their names are called by the fairy, who apparently knows
them all by name, but who is prompted by some one reading from a
list standing behind the curtain close by her side. Jack Frost whisks
about helping the fairy hand out the gifts and assisting the wee ones
to get down off the stage with their bundles. During Mrs. Santa's
address he might carelessly perch himself upon the pumpkin.
The pumpkin is made with a strong wire frame (can be made at any
hardware store), and covered with a deep yellow cambric with an
occasional green smutch painted upon it. It is in two hemispheres
and is tied together strongly at the bottom and loosely at the top, so

that the fairy inside can easily loosen the top string and step out
when Mrs. Santa cuts open the pumpkin with a large carving-knife.
In case it is not practicable to have a pumpkin-frame made,
substitute for it a gigantic snowball made of cotton-wool, covered
with diamond-dust to sparkle like snow-crystals. Two large old-
fashioned umbrellas that are dome-shaped will serve very nicely for
the frame of a spherical ball, if the tips of the ribs are wired
together. It should then be covered inside and outside with white
cloth on which the cotton batting can be basted. With such an
arrangement it would be necessary to dispense with the fairy, but
the little folks might have the surprise of seeing the snowball slowly
open at a snap from Jack Frost's whip, disclosing a nest of smaller
snowballs. These Jack Frost might toss to the children and, when
opened, they might be found to contain candy and nuts.

Welcome to our website – the perfect destination for book lovers and
knowledge seekers. We believe that every book holds a new world,
offering opportunities for learning, discovery, and personal growth.
That’s why we are dedicated to bringing you a diverse collection of
books, ranging from classic literature and specialized publications to
self-development guides and children's books.
More than just a book-buying platform, we strive to be a bridge
connecting you with timeless cultural and intellectual values. With an
elegant, user-friendly interface and a smart search system, you can
quickly find the books that best suit your interests. Additionally,
our special promotions and home delivery services help you save time
and fully enjoy the joy of reading.
Join us on a journey of knowledge exploration, passion nurturing, and
personal growth every day!
ebookbell.com

Agile And Lean Program Management Scaling Collaboration Across The Organization Johanna Rothman

More Related Content

Similar to Agile And Lean Program Management Scaling Collaboration Across The Organization Johanna Rothman (20)

Recently uploaded (20)

Agile And Lean Program Management Scaling Collaboration Across The Organization Johanna Rothman