Why Agile doesn't Scale & what you can do about it

Dan North

Recorded at GOTO 2013

Get notified about Dan North

Sign up to a email when Dan North publishes a new video

so what I want to talk about I I spent
about eight years working at one of the
I think most effective agile delivery
firms in the world they're exceptionally
good at what they do and they are very
very fussy about recruiting who they
hire how they train them how they get
them doing things these guys are you
know what I'm trying to get across is
that they're at the top of their game
time after time I would see the same
pattern emerge we would go in we would
deliver something usually pretty special
in a very short timeframe people would
be happy and energized and we're to all
come back six months a year 18 months
later and everything had just reverted
and it was heartbreaking and it happens
once or twice do you think I care this
is just unfortunate and then there's
soif for me certainly something clicked
and I just went right okay I need to
figure out what causes this stuff to
revert and what we could do about it and
I spent about I know the last probably
two years while I was with thought works
trying to solve that and then the four
years or so since and I'm still
struggling with it and where I've got to
is agile doesn't scale and and I know
people are going to throw things at me
hopefully money rather than fruit but
what's interesting is the most common
counter argument I hear for agile does
scale then you just need to X you just
need to do this thing is what I can't
help hearing is like cars do float down
you can make a cup float you just need
to roll it onto a ferry and then it's
fine and at the other end the car rolls
often the car floated that's not a
function of the car okay the car was
able to cuz you put stuff around it and
really what I want to talk about today
is the stuff that you need to put around
give it a chance of surviving over time
okay and I'm talking when ice when I
used the word agile I'm talking the you
know the broadchurch of agile delivery
methods Chris Matz is a independent
consultant in the UK recently if that
look in the last couple of days
blob something I thought was really
useful to this conversation which is he
says when we say agile do you mean agile
as in the values in the original
manifesto do you mean agile as in as it
is practiced or agile the brand okay and
and I'm not gonna you know answer that
under saying when you're talking with
each other and with your your colleagues
maybe customers clients about that try
and figure out which one of those you're
using maybe use different words so why
our child doesn't scale this is a
rubbish title okay so how about this how
agile can cross the chasm and why it
usually doesn't okay I'm going to talk
about which chasm as well and as we go
so okay here's what the talk isn't okay
and this is the talk I keep seeing in
various different places which kind of
prompted meters and once her to rail
against it a bit a guaranteed formula
for scaling agile star not guaranteed or
a formula okay that's a complete ripoff
of there's a advert on the site of a
buff in a Simpsons episode where it says
free money and a little star not free
which I just thought was brilliant
so okay first of all we need to get some
terms out here what do we mean by scale
there's lots of different ways you can
scale delivery and when I say delivery
what I'm talking about is technical
technological solutions to business
problems so I'm staying very much in
these sort of enterprise space because I
know so what do you mean by scale we can
scan out across the number of axes we
can scale to solve bigger problems well
I think actually agile methods have a
really good story around this I've seen
complex problems solved using you know
short iterations short release cycles
rapid feedback good customer engagement
you know attention to the the the rigor
of software so that the practice is you
like your TDD and you a proper unit
testing and automation and those things
are very very good at taking a kernel of
an idea and growing it and growing it
and growing it and I just noticed olá
binney's wandering around the building
somewhere and he built out the most
incredibly I think wonderful and
complicated modeling system for trying
to understand genomes mutations in
cancer development right I I got all of
those words wrong okay but but look up
this talk it's amazing and he started
with you know well because he's a Lisp
guy so he started with a pair of
parentheses and just built out from
there and built this thing so that I
think you can solve big problems as long
as you you you have the space if you
like to grow them in the way that you
need to grow them bigger solutions
there's an assumption is a learned
assumption that big problems need big
solutions and really often big problems
don't need big solutions you may have a
tiny tiny tiny problem so I tell you a
kinds of mayhem to emerge I use the word
root cause guardedly because it makes it
sound like there is such a thing as
cause and effect rather than systems
influencing each other but you know it's
a good approximation so in a lot of
cases big problems don't need big
solutions sometimes they do and and this
is where things get interesting what I
mean by scaling is big programs of work
big programs of work means many people
okay so it may be that the thing we're
trying to do is very wide and there's
lots of maybe interdependences and it's
very time constrained I need to do this
thing in a short amount of time I need
lots of bodies on it I'm aware that you
know 911 can't have a baby in a month
and all of that stuff I'm also aware
that if I have two three five twelve
teams I'm not going to get two three
five twelve times the throughput because
I've got all the communication overhead
but if I can get good at that I can get
more than one X right there is a there
is a a a function of scaling so when I
talk about scale I'm talking about
taking on bigger problems with more
people so so why is that hard what what
could that possibly be hard we know you
know we've got our core values of of
communication and simplicity and and all
those things are already called out for
us so as long as we just keep doing
those we're going to be fine yeah surely
that's gonna make sense well the problem
we've got is that when you have lots of
teams doing stuff particularly
ironically lots of very experienced very
highly skilled teams they're gonna solve
things locally and they're gonna solve
surprising ways you're gonna look at
something go wow I hadn't even occurred
to me you could do that that's brilliant
which is fine if they're the only people
in town if they're not the only people
happening in lots of different places at
the local optimizations and the problem
we've got is that doesn't roll up into
anything useful what that rolls up into
well I'll give you an example I come
from the UK in the UK many of their
thousands of years ago this is before we
got invaded by everyone actually we did
get invaded by pretty much everyone so
back before those days you you basically
had you had the Welsh you had the people
living in Scotland peaked the scottie
came over from Ireland so that's a funny
one but you had these different places
and they spoke different languages so
you had Celtic and pick T and the other
ones right and and the reason for that
wasn't they were just sort of you know
being contrary it was geography okay so
when you have we didn't have bit of
mountains inning look we've got some
brilliant impressive hills and we've got
these hills running up the middle of the
country and that meant that people on
one side of the hills spoke
different language okay they had locally
optimized communication they didn't need
to they probably didn't know these guys
were here until they kind of started
running out of stuff and then went
invading I went hey you guys speak a
different language if we hit you hard
enough you'll start speaking our
language sounds a bit like enterprise
consulting actually you know and we
still do and and interestingly as well
we're on the subject of language look at
what happens over time so the in
whenever it was 16 something we chucked
out a load of proto Americans or there'd
say the founding fathers left Plymouth
and went to went to America and at that
time we all spoke the same language we
spoke 17th century English and they
that's how most of them were from
because again geography but bow first
into what is now various different
flavours of American dialect and and
flavors of English dialects so they've
diverged and spellings and idioms and
those kind of things diverged it's a
very similar thing so as we're designing
systems as we're designing software
there's no such thing as emergent
architecture at scale or emergent design
at scale emergent design at scale is a
platypus right duckbill platypus which
is a an evolutionary wonderful thing
it's perfectly adapted to its
environment I wouldn't want to maintain
one I wouldn't want to be the guy who's
go hang on it's got this thing at the
front and of what at the back of tail
how's that work it's really it's not
obvious right no one said the right
things for this creature should be this
it was kind of Wow I mean there's this
little logical niche so I'll just fit in
here and grow a bill okay
that seems to work the other thing and
this is something that agile folks find
hard and as an agile folks myself I find
this hard you kind of want to think that
because when you use agile methods in
the stuff we're used to it works so well
my experience has been when I started
doing things like pair programming in
particular was a real profound
experience for me learning how to EDD
works learning how to DD actually drives
design rather than is a testing thing
that was really profound just the the
thrill of automating away something
really boring and having it never ever
fail again and never irritate me again
was wonderful
so this surely this is just one of those
it plays everywhere and then you realize
that these guys and all of the agile
methods in the you know the original
Snowbird get together we're all 90s
methodologies all nineties methodologies
so it's like the turn of the millennium
is when they all got together at
Snowbird they were solving a different
thing they weren't trying to solve
scaling delivery they were trying to
solve any delivery at all
we were dreadful at delivery we never we
never did it would happen these two
three five year programs that would
Rumble on and spend all the money and
then we come back and go oh sorry
like that or better someone would go you
guys are all idiots get the next one and
the next one would come in and say hey
we've figured out what they did wrong
they're a bunch of idiots it's going to
take us two years to fix it oh okay
let's do that
doesn't have an opinion about scale
agile has an opinion about getting
anything out the door so the original
description of scrum said look just
target 90-day releases if you can get
down to a release every quarter you're
winning right what we'll do is we'll
sprint to the halfway line then we'll
six weeks sprints and and then we'll
know whether we're even close to
delivering something in 90 days and you
know the Kennish wavers buddies looked
at him and said you're crazy can we
can't deliver anything in 90 days you
know now if we go more than nine days
without a delivery we can get a bit
twitchy so that's what they were trying
to solve for they weren't trying to
solve very very they weren't trying to
sort of scaling okay that wasn't even
interesting yet so the problems start
with this is that if you are good and in
fact especially when you're good agile
delivery in the small if I'm managing a
portfolio of work that's the first one
of those big words portfolio look at
that if I manage a portfolio
of which your project is one of them I'm
gonna start getting a bit concerned
because you're not making the same
noises as all the other people okay some
of these things are not like the others
I want to tell you a story once upon a
time there was a project I was on this
is back in the thought works days I
won't tell you where I was working
because well I surround fold you'll
you'll realize to yourself but this
happened we had we were one project up
here where are we that's us
guess which project so you've got these
three very square peg type projects and
fairly agile thing going on and all of
these projects were of a similar size
maybe 50 people okay so our program team
if you like had four teams have like 10
people plus some other folks around them
and the other three programs were a
similar sort of size and this would
happen every month we would have
steering and we'd report up to the
we're green because that was the answer
you're expecting what color is your
project what's your current status red
amber green status it's green that's the
only allowable answer so said okay well
then we're green and then we said green
and then we said amber and then what
yeah where amber shut up what do you
mean amber is it like who do I need to
fire do I need to get rid of the project
manager no you don't the the reason what
amber is this is we have a decision that
needs making that's a program level
decision so we don't want to make it
locally because we're likely to maybe
derail some of the other guys or cause
you know surprises now we had a really
good project manager and she had
identified that what we needed to do was
was escalate this to say hey steering
guys steer us and so they weren't used
to hearing we need some help they be
used to hearing means I need a shout at
the project manager because that's how
it goes green again okay so we said
here's the decision we need to make and
they said oh well that's pretty easy
we'll make that decision make the
decision next month are all green again
next month remember again oh wow
we became known as the whitey project
but you again you actual folks again
what do you just keep disturbing us in
this to this steering meeting for a bit
of a lie down you know this is my quiet
time you want me to what make decisions
well and and of course as big
organizations do they run what along
didn't make a decision next month we
reported read now they don't like
projects reporting read because they
then have to start telling people okay
having your project in read status is a
reportable offence right so they said
what do you mean read and we said well
you know the decision we needed you to
make last month because that would put
us at risk
well you didn't like it and now we're at
risk because red means we are materially
at risk of not delivering and so we need
you to make that decision and they went
oh oh so actually these red amber green
statuses are about us and the program
not about your project yes oh okay we
hadn't thought about that
and so then business as usual because we
needed the decision made making or we
that needed to happen that was bigger
than the project so maybe you know
things like hardware right when you're
on a venue in a big organization you
can't just go get hardware you need this
whole process and if there's a portfolio
of projects like this the chances are
there's going to be a hardware like a
procurement function somewhere buried
deep in the PMO and in our case there
was and so that's where some of those
later embers were like you know what we
still haven't seen the the production
kit that you're shipping from wherever
inflated right brother's buying it
locally and so then this happened
got to the end of the year that project
failed that project failed that project
of them and this isn't a very such story
this is a this is what happens when you
are trying to make decisions off bad
information okay
now luckily that the program that the
project that we were involved in
delivering had enough of outside that it
funded the rescue of all of those over
the next year or whatever but they're
worth for comparable projects one of
them delivered three of them didn't and
the thing I learned was we weren't
talking the same language as the other
projects and it was on us right when you
start changing stuff you need to go to
the people who were in whose environment
you're changing you can't just expect
them to get on board and there's a
certain and I'm guilty of this as anyone
there's a certain kind of arrogance or a
belief in the process like surely just
look at what we're doing it's patently
self-evidently better than the thing
you've been doing therefore get on board
there's it doesn't really work like that
um and and a few years ago Chuck would
Richard Donal he's one of the smartest
lean operations folks I've ever worked
with blogged a wonderful wonderful
articles I'm Richard Donal calm it's
called agile adoption patterns I take
issue with two of the words in that
title okay
the thing he describes isn't really
agile adoption the early part of it is
as well adoption the rest of it is
basically lean organization change and
the things he describes aren't patterns
the model is really good so I say let me
just walk you through it
and it kind of frames the rest of what I
want to talk about okay so the first
thing that happens when you start some
kind of adoption the people break okay
what does that mean that means we are
we're changing their working environment
changing how their what good looks like
right we're changing how how they work
we're often changing you know the team's
they sit in I'm used to sitting as a
business analyst I'm used to sitting
with all my business analysts buddies on
the fourth floor and what you're pulling
me up to sit with the team of smelly
programmers do you know who I am
right yeah this kind of thing going on
so the people break their they're
confused they're it's this is changes is
difficult and as well we
need to be very aware of they didn't
sign up for this okay I'm working at a
large American bank at the moment and
we're busy causing all kinds of mayhem
organizationally and a lot of the people
involved didn't sign up for that they've
literally been working in this Bank for
20-something years they've been working
in this one job or in this one
organization they've had many jobs
they've been working in this one
organization from you know for as long
as I've been working and I've been in
lots of different companies I don't
usually last very long so yeah and we've
come in and just completely moved their
cheese robe you said okay well now we're
gonna do and some of them are really
game they say no you know I've been here
twenty something years and I'm a senior
senior senior manager and I throw in my
title and I'm gonna I'm gonna come along
and just join us join us delivery team
he's like whoa that's pretty cool some
of them are just you can see the whites
we're breaking stuff around them so okay
so as people start to get on board with
it they suddenly realize the tools break
they realized that the the the control
mechanisms they had the things they used
to measure don't apply anymore so in in
old world we measure activity we measure
busyness we measure because we can see
those things we measure maybe tickets
closed in some support function so that
that's what we might measure utilization
utilization is a good thing to measure
because I can look around and I can see
if someone's busy and so the the
perverse incentive there what's gonna
happen as soon as someone looks at me
I'm going to just start typing okay
don't worry
there's a lovely Dilbert a few years ago
I said okay we're gonna start rewarding
people for lines of code produced Dover
okay so but we're good at that so we're
good at things like introducing tooling
we've gotten really good at that so then
what happens is this the governance
breaks what do I mean by governance
going to come back to this again again
in this talk because this I think is the
crux of everything go
is this are we okay are we invested in
the right things how do we know what
we're doing how do you know whether
point at which we start - whoa what is
there in the manifesto about governance
like program level governance multi
project multiple work stream governance
interdependence eat governance that well
that kind of isn't anything so we're
gonna need to figure some stuff out
once we get the hang of governance and
all of those sorts of things so now
we're now we've met now we've scaled
okay we've done the first level of
scaling if you like we've understood
what it means like to manage a portfolio
of things each thing is locally doing
fine okay well then what happens well
then the next thing that happens is the
customer breaks now for a lot of you
folks I suspect when I first saw this I
thought hang on a minute we've solved
customer on-site customer or product
owner whatever your flavor of agile
might be we've got this the custom what
do you mean the customer brakes well at
scale the customer is no longer the
customer the customer is a nebulous
concept okay
the customer is really a placeholder for
understanding the market so it's it's
all of the different kinds of market and
and product kind of rolls so product
management market engineering all that
kind of stuff is all tied up in the idea
of the customer so one of my pieces of
work that I'm helping out with at this
Bank has 50 I'll say again 50 director
level people senior level people
all clamoring for work through this very
very narrow pipe okay of you know a
small number of teams who are able to
deliver and managing the expectations
across 50 people is an incredibly hard
job okay it's actually several people's
these people before this stuff ever even
hits the pipe okay understanding how
stakeholders respond to better
information different information when
you start talking about cycle times and
and throughput and lead times and an SLA
s around that kind of stuff versus all
of the Gantt chart II things they used
to seeing is a complete adjustment and
then okay so then what happens well now
we've got the hang of getting all these
people to you know to understand things
like opportunity casting cost of delay
and all that great then what well then
the money breaks or the funding or the
financial controls however you want to
look at it we're used to being in
top-down cost accounting organizations
anywhere in the West is pretty much
that's how it works you have the people
the top of the organization have big
pots of cash and then they have now
smaller pots of cash and lots of cash
down to your project okay so we have
this very is height rocket called
dribble down of money and we're trying
to get work going across the
organization and those things don't work
together and once you can start seeing
people from very different parts of the
organization wanting something that cuts
across all those different parts of the
organization how you fund that becomes a
non-trivial problem there's I'm looking
at work that hasn't started that hasn't
started four months not because no one
wants it to start because they still
haven't figured out between them who
should pay for what okay it's like it's
heartbreaking what happens finally
finally if you're really really lucky
and if you have a whole bunch of things
come together finally the organization
breaks this is the point at which now
we've got a sort of throughput
accounting and our beyond budgeting and
we've got some very senior people in the
organization prepare to take a massive
risk of rebuilding the organization
around value streams around customers
and I might be exaggerating the number
one okay with the amount of snake oil
I'm hearing about scaling like it's a
solved problem do my thing it's a solved
problem it really is not a solved
it's something you can chip away at and
something you can have an impact on and
have a significant and lasting impact
but boy is it's not a self problem okay
so we're next
okay this is where we are you see this
you are here we are between stage two
stage three okay that's where we've been
for about the last ten years to be fair
that's where our joke started as I said
I want to get past the people in the
tools right because that's delivery I
want to solve delivery and the only
person I'm not gonna say the only person
the only methodology in that room in
Snowbird in 2001 that even had an
opinion about scaling was Alistair
Cohen's crystal and that's because it
was a whole family of methods and the
family of methods were actually a way of
codifying how various axes of hard
something was so is it like from from
its the impact of failure so impact of
failure is someone gets a bit annoyed
someone dies okay so there was like a
bit annoying business impacting which is
why it's gonna cost us some money
business critical it's gonna shut us
life critical 34 and then he has another
axis which is how big of a problem how
many people is it going to involve
because that's another level of
complexity and there's there's several
dimensions to this and that's one of the
reasons people aren't doing crystal now
is it's really hard to even get the
model in your head and the model is a
massive simplification of what actually
happens right so you are here so if I
flip this on its side I could maybe
illustrate this slightly differently
okay as anybody read the leprechauns of
software engineering any hands okay it's
on it's on lean pub so it's like it cost
my not very much wonderful wonderful
very short ebook the leprechauns worse
off for engineering and what what he
does is he looks at received wisdom
that's been handed down from software
engineer to software engineer through
the through the ages and just drive the
truck through it so you know the thing
about that we've got data that some
programmers are 10 times more productive
than other programmers
that was made up right that was made up
you know the thing about the exponential
cost of change which actually is about
the exponential cost of discovering a
defect which is often just the
exponential cost of anything as a
project goes on no data there is no data
for that okay go read the leprechauns or
suffer engineering it's a it's a fun and
slightly unsettling read so in the light
of that this is not a graph there is no
data behind this this is subjective this
is qualitative this is the experience
I've had so here's what I've seen I've
seen that getting past the people in
tools bit is solvable is
deterministically solvable is
reasonable amount of time if you tell me
various things about your organization
and about your people and about your
products and about what you do I can
come up with a pretty good stab at how
many people for how long is it going to
take to be able to make a significant
impact on those two levels just cuz I've
done it a bunch of times and I've worked
with people who've done it a bunch of
times and this is this is where our
they're consulting in certainly of the
agile world has been for the last decade
or so around about between tools and
governance in fact what I'm going to do
is put an extra thing in here you see
this this is a lot like the crossing the
chasm thing you can't see a red dot okay
I need a different pointer
there's a question mark there we don't
know usually how to get past breaking
the tools and introducing better tools
and battles I mean things like systems
methodology processes as well as actual
tools you know planning and tracking
development tools like so there's
organizational tools as well we're good
at that okay we've seen enough of that
to get good at it though to the
governance bit how do we scale this how
to report it how do we make it make
sense that's a lot harder ok so so I
call this thing here this thing in the
middle here the chasm of credibility ok
I don't
here when I speak to Angela folks or
particularly these days sometimes I'll
be in the room on a client side of you
know some fairly senior folks talking to
you may be agile consulting firm and
we'll be talking about things like
governance and we'll say so how do you
do planning and tracking well know can
you tell us how long this thing will
take well not exactly know okay I'm
gonna need to know how long it's going
to take how much it's going to cost me
and then I hear them saying the things I
used to say and boy does it sound
embarrassing from my side of the table
because they say things like well you
can't know it's impossible to know
everyone else who tells you a number
that they're lying there making out you
know because they can't know it's
unknowable what we'll do is this is
after a few sprints what's a sprint our
two weeks okay after a few pairs of
weeks we'll be able to tell you what our
velocity is in story points and then we
can figure that out to a burn up that
will give you a range of what hey when
is it going to be done how much do I
need to spend on this problem well what
we're gonna do is we're gonna start with
the team and they're gonna have a sprint
zero and they're gonna what - stop stop
using those words at me right tell me
how you are going to govern tell me how
you're going to convince me that there
will be responsible activity ensuring
delivery of this thing well what we're
gonna do it's it's and you just see this
thing go around and eventually one of
them just gets worn down you know
sometimes it's the client it says I'll
just start just start and see what
happens okay and yeah and again we're
not doing it because we don't want to
give them good answers it's that we've
convinced ourselves that there aren't
good answers and we've convinced
ourselves of the arguments why and so
we're going with the arguments rather
than taking a stab at the answers we are
as uncomfortable with uncertainty
ironically as the organizer as the
traditional folks are there big Gantt
charts so what I mean but government's
like you you use this word I do not
think it means what you think it means
what do we mean by governance well
execution is what we do
okay execution is getting code getting
product out the door but and in the
small that's pretty much all you need
right but now what happens is when you
have multiple work streams going on
you neither think we'll delivery
assurance how do I know that the various
pieces across my program are going to
make sense okay how do I know that what
is that what are the interdependence is
what are the impacts if this things
light is there our knock-on effect of
these other things how many things work
in parallel who needs to know about what
and this is where I want to have an eye
to those local optimizations that might
derail stuff versus the local
optimizations which absolutely fine to
stay local and then finally governance
is the piece across that that says how
do i what am i investing in am i missing
in the right things what's my expected
ROI so a business case and that kind of
stuff so and these top two also go by
the name portfolio management so now if
we look just very very briefly on
they're going to these in a little bit
more detail but very briefly let's look
at what we care about in each in each of
these situations so portfolio management
is balancing options it's saying here's
a bunch of things I could invest in
which one should I invest in what are
the relative weightings of those things
which things matter which things don't
matter oh hang on this thing's turning
out to be more expensive than I thought
what decision am I going to make based
on that information this thing is coming
less expensive than I thought
I now can do some other stuff
discretionary stuff what should I do
okay so it's those kind of conversations
so what happens then what happens at
these different levels well this is
usually what happens this plan do check
what's actually plan do check act but I
preferred that I think it's more
descriptive of what happens so this is
this is the the lean description of how
how discovery and delivery works it's
so plan have an experiment have a we're
going to build this product were going
to try this thing do it and then
validate see whether it works and then
change your mind based on that change
your direction based on that and so
adapt might be doing the same thing but
more it might be do a different thing
we've done
I think now it might be oh hang on a
minute that was a surprise okay that was
a bit of a surprise
we should probably back out that change
so I was in Spotify recently just for a
few days and you know how you sort of
think they're gonna be a really cool
company with all cool stuff and a really
cool office they are
that's quite a fun week so they have
this riff on that which I really like
think it build it ship it tweak it now I
also think there's a subliminal
reference to pop will eat itself from
the early 90s so if anyone else gets
that reference and let me know but it's
really nice it's it's and they've
actually got this on the walls in the
building think it build it ship it tweak
it is what we do and we go around cycles
and cycles of that okay so that's team
scale okay they have they call them
squads but that's team scale it's
locally optimized you team makes team
decisions off they go running all that
stuff and you know what we're really
good at this this is the thing that
actual is and does incredibly well okay
this is the thing that I in the 90s when
I was a very at five six years into my
career I was okay at programming the the
thing that I felt was a sea change in my
capability to solve problems was when I
started doing some of this other stuff
Kent Beck describes it brilliantly he
says I'm not a great programmer I'm a
good programmer with great habits I
disagree I think he's a great programmer
as well but what I did was stole a bunch
of his habits in the early 2000s and
that worked out quite well
so that's execution we're good at this
okay this is the thing we're good at
what but the takeaway is that that
expertise that skill that compact
capability isn't transferable it doesn't
mean you can necessarily do the next bit
so what's delivery assurance about its
cross team concerns it's understanding
what's interesting across those teams
its product trade-offs so do you know
what on your work stream on this on the
part of the product you're involved in
here's some things that you need to do
and you can prioritize those and that's
all fine and then on another work stream
over here there's some other stuff going
on oh do you know what we've realized
that we need
to shift the weighting of these entire
parts of the product so we need to get
more of this through the pipe at the
expense of some of that
so listen team a over here we're going
to actually shift your direction a bit
but we're doing fine I know you are and
I'm if this isn't about you I'm really
sorry there's a program level thing that
we need to shift
yeah well ie the probe the project team
could couldn't have known that from the
data they've got looking inwards to
their project they can't know that
because they don't see across the whole
program yeah and unless they're involved
in that as well so that's why you need
that kind of broad look technical
trade-offs okay so as each team
discovers a thing and that thing might
have a far-reaching impact they often
don't go and talk to the other teams all
right so they don't they'll the amount
of times I've seen on a fairly you know
modest science program maybe 50 people
or something three different databases
there'll be some Oracle stuff some
sequel server stuff and maybe some Mongo
yeah why did you make those choices
oh just pencil it I've got a guy on the
team that knows sequel server so he was
really up you know we said that these
other guys were using Oracle he said not
on my project and so so we didn't use it
and and so now again from each local
silo of team makes a lot of sense right
from a program level someone's the other
side of that usually wearing a Motorhead
t-shirt with long hair and often with
sandals going why have I got three of
these things to manage you yeah so your
operations folks are looking at this
going why didn't no one think of me okay
so the technical concerns across the
whole program are about how do we figure
out the ecosystem of delivery and
sometimes we're good at this okay I've
seen agile programs that have really
really good delivery shorts figuring
this stuff out and doing this really
well okay governance Oh scary word what
happens in governance well things like
this organizational concerns should we
even be funding this um I referenced
Christmas again because he's one of my
favorite people in this space he's done
a little work with what's called real
options he was involved with a large
energy company in the
mm and he was on a 50 million pound
program of work which is about 12 Crona
at the moment have you seen an exchange
rate we're not doing so well about 15
million pound program of work he was
responsible or he was the business
analyst on a 20 million pound piece of
it and he was scratching his head saying
this thing doesn't make sense I can see
why we're doing this but I don't see how
the rest of it how it fits in with the
rest of the pieces I don't understand
how the program works and here's
certainly motive his boss and his boss
shut up Chris no I really don't
understand why we're doing this thing
and it's gonna cost 20 million pounds
send what Chris didn't know is that in
the time it took him to respond his boss
had gone on holiday his email escalated
to his boss who was the CFO and the CFO
said about this twenty million pound
hole in a program you could within 24
hours let me know exactly what that
and then it turned out that the whole
thing simply didn't hold water is one of
these massive vanity projects and so
they cancelled it okay I think that is
an epic epic win of governance 50
million pounds didn't get spent
literally years of people's lives didn't
get wasted doing a thing that simply
would never have worked and so now
what's the opportunity cost of that all
of that time and money can be diverted
to something else yeah Wow
so organizational concerns there isn't a
there isn't a test for that right
investment trade-offs which things
should we be investing in and this is a
strategy level this is like should we
even be investing in saving costs or
increasing visibility of information or
moving into new territories I don't know
maybe there's a relatively low-risk way
of exploring those things maybe there
isn't okay maybe it is an all-or-nothing
decision I need to really spend some
time thinking about it portfolio
balancing has anyone heard of portfolio
usually even get exposed at this level
okay but this is the kind of information
that needs to bubble up so
so we want to surface the right
information and the problem we have or
not the problem the challenge we have
for scaling agile for take it for being
and what is a scaling edge what I mean
is this
I love the incredible effectiveness of
applying agile methods at the execution
level it is world-beating I've not found
anything else as soon as I do I'll drop
it like a stone and start doing the new
thing okay
I simply haven't and I've been looking
pretty hard for about 10 years right
we the stuff we do at an execution space
is brilliant what I'm trying to figure
out is what's that what's the thing it
needs to be what's the soil it needs to
be in in order to thrive so there's two
kinds of conversations there's this
conversation that goes on between
governance and deliver assurance are we
investing in the right things well let's
see are they on track or what does on
track me well you know budget return on
investment yada yada and then because of
that delivery assurance has a
conversation of execution and you can
see where the sort of feedback happens
and you can pick each one of these four
off what is governance eight of
assurance what does assurance a to
execution and and right and so on each
of those conversations what should the
content of those conversations be what
should each layer be telling and hearing
from each other layer in order to make
however time four minutes left okay I
should move a lot faster so what
assurance have we learned anything new
that might materially affect the
delivery right are we nearly there yet
right delivery assurance is like the
five-year-old's in the back of the car
you're driving on holiday oh yeah I mean
it anything that might materially affect
stuff because if so I need to I need to
make some decisions governance our
investments online with our objectives
two moving parts their objectives change
based on market and economy and all
kinds of other stuff and investments the
choices of investments change as you
learn stuff and deliver assurance
anything we should be doing differently
how do we surface that
so then contextual consistency oh I got
right we're gonna go through very
quickly is this the first thing is you
need to create and share a clear vision
this is a technical vision a product
vision a directional vision a
organizational vision this needs to be
this is the aunt weren't this antics X
looper he the guy who wrote the little
prince has this wonderful description
about if you want to build a you want to
get but a group of people to build a
ship don't tell them about wood and
carving and all that give them a taste
for the ocean describe what it feels
like in their hair yeah
create a vision guiding principles
enable people to do things locally okay
and what that needs is strong and
consistent leadership I thought long and
hard about these most strong leadership
it has to be opinionated not dogmatic
but opinionated it has to listen but it
has to be strong enough to make
decisions and consistent if you're
changing your boss you know your your
management team in your business every
you know the current half-life of a CIO
is like 18 months right nothing is gonna
happen in 18 months at that level
someone needs to decide this is a ten
year play and this is what they're gonna
do okay
this is what Beato bugs this I just
pronounce his name really badly it's
been doing in in statin or was being a
setter for a long time is this and he's
stuck with it and he's champion there so
what that means now this is the
empowerment piece once everyone has
those global principles once everyone
knows what the decision-making framework
looks like they can make good local
decisions they know what kinds of
stolen directly from beyond budgeting
all decisions need to be transparent all
decisions need to be accountable what
does that mean that means anyone can
decide to do stuff to spend money to
invest to change direction to whatever
it is but if anyone called you on it and
anyone's allowed to call you on it have
an answer okay
have a case make the case again strong
and collaborative leadership okay so
this is at a team level as well the
collaborative is not committee
okay collaborative is not consensus
consensus means everyone decides to
compromise and everyone resents the
decision collaborative is everyone is
heard someone sets the direction okay
difference between Ernest Shackleton and
Scott of the Antarctic okay one of them
brought all the people back the other
one died and is much more famous so this
is Maya this is the tweetable definition
if you like of contextual consistency
given the same context given the same
constraints we are likely to make the
same decisions okay because that means
now some of this stuff happens so here's
some of my guiding principles we don't
have time to go into many of these today
this top right one difference is data if
we're all working off the same
conceptual framework the same guiding
principles the same vision and you're
doing something different from what I
would that's data I can look at and go
oh you're doing something I wouldn't do
I wonder what's different in your
context that's causing you to do that
rather than you're an idiot and I need
to hit you with a stick
okay so differences data says if we all
have this shared vision then it means
that we're all able we're empowered to
make good local decisions knowing what
the landscape is looking where the
action is 'm this is about kind of
opportunity cost cost of delay value
stream mapping all that stuff where you
put flood lights on the gaps in between
the process or the gaps in between the
systems yeah because that is almost
always where the cost is where the waste
is where the massive massive gains are
to be made we tend to look where the
action is we look where the noise is
which is why for literally over a
century we've been measuring effort an
activity and utilization rather than
things like queue depth cost of delay
those kind of things so wrapping up I'm
out of time for questions I'm afraid so
scaling is more than just small things
bigger okay you can take and you can't
take the car and make it float
if you want the car to float you need to
put it on a big boat okay it can't float
but it needs something that is
substantively different from the car
itself okay guiding principles strong
leadership start to lay the groundwork
for that to happen crossing the chasm of
credibility is really hard it's not
impossible it's really hard and it's a
different thing and this is where I
think we're going this is where this is
really exciting for me because you know
I've been to this conference in
particular a number of times and you see
themes over over over years it's really
interesting and this is the first time
I'm really hearing and you know a number
of people talking about we're trying to
make these you know organizational
impact and that's very exciting we're
going to struggle with it a lot but it's
a really exciting struggle to have