How to scale a program painlessly, Which scaling models work well, what parameters need to be considered for a program, How to use metrics for a large program

1. How to scale a Program
painlessly

2. What
A large pool of work
Aligned by business purpose
Organised across multiple teams performing multiple functions
Constrained by a specific time period
Investment funded by one or more business functions based on certain expected
business payout

3. Managing a program
Try a pilot for demonstrating initial outcome
Look at scaling through initial pilots - across multiple functions
Strive for maturity quickly in some functions
Move towards achieving quicker ROI for faster business results

4. Common challenges
Scaling goes wrong - too many functions evolving at the same time
Functional teams do not mature and do not start delivering value
Onboarding multiple teams
Delivered outcome cannot be tied to program goals for defining ROI

5. How do we achieve these results - Scaling & maturity
Do not try to scale too many functions at the same time. For e.g. if engineering is
still not mature, do not try to scale user training and releases
Focus on scaling and achieving maturity in one function and use those learnings
in other teams too
This graph shows how with 4 functions should be
scaled in a staggered fashion.
Spend enough time to scale each of them and let
them gain maturity before starting to scale other
functions

6. Look at results attribution right from when we start building the product.
Looking at what to measure and how to measure when you build something is
key. It is also important based on your source of funding to show constant
progress in the program
How do we achieve these results - Result attribution
Indicating a release
happened to lift topline
Indicating a release
happened to lift
bottomline
A good way of achieving this is
also having very clear business
drivers for each release - specific
user targets that will convert to
these metrics

7. Is there a process to follow
Most processes are people centric and always follow who the leader is.
Best rule of thumb: Make any scaling process anti-fragile (More info here)
Things to remember:
Continuous exposure to faults and automatic fixing is the primary measure
Continuous attention to technical excellence, reality, redundancy
Antifragile architectures emerge from self – organizing, context aware teams
The most efficient and effective method of building an antifragile organization is building on
honest, open and transparent communication
At regular intervals, the developing team reflects about the context situation, on how to
become more effective, then tunes and adjusts its behavior accordingly.

8. This is too abstract - Break it down please
Program
structure
Communication
Primary
Measure
self – organizing, context aware teams
honest, open and transparent communication
Continuous exposure to faults and automatic fixing
Focus technical excellence, reality, redundancy
Team norm
Reflects on the context situation to be more effective ,
adjusts its behavior accordingly

9. What am I still missing
Context
Changing scenarios where
unexpected events are the real
paradigm shifting entities
Dimensions
All stakeholders, and the
broader environment, lead the
antifragile organization
Ability to recognise
these events
Ability to learn
from these events
Internal stakeholders
are active & carry out
the program
External stakeholders
are passive and our
primary learning area
for errors

10. So which of the current program models have these?
Does SAFe does what you are calling out?
Any model that prescribes a specific way of scaling assumes teams have to be
taught the ways of work for effectiveness and cannot figure out themselves.
For this reason, any prescriptive model CANNOT achieve true anti-fragility.
Hence they all lose the ability to demonstrate quick measurable success to
business.

11. Thanks
Prashanth Madhavan Narasimhan