Governing Agile Delivery

Dan North

Recorded at GOTO 2018

[Music]
good morning welcome so the first thing
to say is I am NOT Gabrielle Benefield
so if you've never seen Gabrielle
Benefield before she doesn't look like
this she's she she has long blonde hair
she's a lot more attractive and has no
facial hair so that's just unfortunately
she can't be here so I am so so the
go-to organized they said okay so we
need someone equally smart engaging
charismatic they were all busy and I was
in town so here I am and I'm going to
talk about the exciting and dynamic
world of governance on agile projects in
that world because it's one of those
things I don't know maybe as I've got a
middle-aged grumpy white guy now so I
get to be a middle-aged grumpy white guy
I spend a lot of time these days with
fairly senior people in organizations
and one of the things that I see is this
massive disconnect between the kind of
people who run the money and the
organization and the big staff and us
folks in agile who's working in a kind
of agile delivery kind of way yeah
almost all the hands went up okay so
before I get started a word from our
sponsors did you remember to rate the
previous session okay if you didn't now
is a good time to get your phone out and
ignore what I say for the next two
minutes and then go what's he talking
about please rate these sessions so
let's start with what is governance I've
been noodling on this for literally
years and I have a problem with
governance I think it's not nearly as
complicated as people say and then when
I look at the people who are saying that
governance is complicated they're also
the people selling governance consulting
and governance tooling and I'm like hey
hang on a minute
I think governance is two questions the
first question is this what are we
spending our money on right that's
called the investment and the second
question is this how's it going what are
we spending our money on how's it going
if you know the answers to those
two questions you've got governance down
okay
the problem is in most organizations in
any non-trivial setup you've got no idea
what the money is actually being spent
on and no idea how things are really
going and so that's where things get
interesting
so really governance is about managing
investment risk that's what we care
about okay
so let's take a look at them like your
regular delivery model I'm coming into
an organization there on a agile
transformation agile who's on an agile
journey journey yeah everyone right
because it's cool yeah
he's using safe I know that's later on
I'm talking about that okay so yeah so
how does delivery work then what does it
look like basically time passes okay
time flies like an arrow fruit flies
like a banana so how does delivery
usually work well we start we start with
initiation there's a program project
scope and we have documents involved in
that we have typically a tendering or a
procurement who's working in like huge
slow-moving does it look familiar
yeah okay so and in budget approval
someone needs to sign off the big sack
of cash in order to do this and then we
go right away that's our first gate
we've got through our first gate so
nobody planning and then planning it
seems like work breakdown resourcing
scheduling henry gantt come up with a
quite a good idea for how you do that
again chart and now we're underway and
we go we're execution this is where the
fun starts
design development testing all of that
stuff okay and we build the thing we're
building and then we release it we have
deployment we have user acceptance for
the transition to life TTL in ITIL terms
so so this is how delivery usually works
and we have these gates and each of
these gates there's a bunch of fairly
grown-up people sitting around here well
yes we approve of this no we don't
approve that's kind of how it works so
how do we govern this we govern this
like this initiation we have a bunch of
stuff we've got a proposition review
right what's the business case look like
if you're a government a public sector
or a large formal organization you might
have an invitation to tender and ITT you
might go out to vendors and say build us
this thing
there's contracts there's budget review
and there's payment schedules and
figuring out how the money is going to
work and how time is going to pass
before we even start I've seen a couple
of familiar faces people I've worked
with in the audience are going yep yeah
that's us and then planning
well that is planning how do we govern
planning well there's a project review
board right there's a PMO sign-off its
financial controls and then again if
you're in a depending on the industry
things like compliance and legal and
regulatory and a whole bunch of other
things that we need and there's and then
we have a review schedule okay the part
of the planning is to figure out how
we're going to review things going
forward and then we get underway on the
execution and let me got steering groups
still who I love soon they're my
favorite and my favourite waste of like
three hours stage-gate reviews
stage-gate reviews ago ok we're on stage
gate I I've yet to find an organization
that has fewer than seven stage gates
from like idea to to actually making
money and and the number of things that
don't make it through a gate is well
vanishingly small and then we have
documentation lots and lots and lots of
involved in some years ago we thought
works or easy to work wonderful
consulting software delivery company big
pioneers of agile methods and they went
into a company where they'd had another
software vendor had been working with
them for about over two years of a
three-year program and they had shelves
and shelves of document they they had
yet to cut a single line of code over
two years in no code at which point
these people were getting a little bit
nervous and so they called thought works
and they said we're getting a little bit
nervous and we're like you should have
been a little bit nervous about a year
and a half ago but you know now's a good
time to be really nervous and then we
end up working with them and it was
great ok mentation loads of
documentation loads of sign-off slow to
handovers write all this is familiar and
then finally release the cab yeah the
cab the change advisory board release
documentation do you have your your
release Docs do you have your change log
and then we have a go/no-go decision
then we have user sign-off and finally
goes live
why why do do it like this and and
there's I was actually in a conversation
with lovely bendin Benjamin Mitchell
this morning a breakfast about kind of
where you start seeing perverse
behaviors and and and weird behaviors in
people and in organizations and in this
concept Virginia Virginia City the the
family therapist had this had this
principle which got a principle of
positive intent should everyone's trying
to help right all that stuff I was just
describing there someone thinks it's
helping so how is it helping so well
each stage case gives us assurance all
right or the illusion of but we believe
it we believe we get assurance because
there's a lot at stake I'm investing big
gobs of money in it I want to feel safe
that we're doing the right thing
remember what am i spending my money on
is it safe well before I start handing
my money over right then I want to know
that things are okay we make big
investments do big projects and big
programs and big investments some people
call them big bets because big bets
sounds more macho than big investments
but basically we do that and we plan and
budget annually who works an
organization with annual budget cycles
the lovely art of augustness Norwegian
CFO who created the beyond budgeting
movement he says it's like having a bank
that's open for two weeks every year
right how would that work because I had
this budgeting thing we plan and we
budget on an annual basis okay because
we're often making multi-year
commitments right there is millions of
dollars tens of millions hundreds of
millions of dollars at stake okay you
know all of these big programs and so do
you know what multi-year commitments are
risky there we go obvious statement
number one right MultiAir commitments a
rescue I do not need my computer to
update Dropbox thank you that's fine you
can go away Dropbox Thanks I love
software that thinks it knows more about
your computer than you do well TM it can
commitment to risky we fear things going
wrong so that's why we have all this
stuff in place what kinds of things go
wrong
what kinds of things go wrong on
multi-year projects everything okay
let's let let's set the bar there I'm
gonna be a little bit more specific so
the first thing that I see going wrong
is cost overruns right we budgeted X and
we're gonna need are some more than X
Mary puffins dick told the wonderful
stories working for the US Department of
Defense many years ago and and they gave
her this like toxic massively over
running project so to try and deliver
any our thanks and so she goes to the
project board she says I'm gonna need
like you know a couple of hundred
thousand dollars to deliver this project
so to finish this project they said oh
I'm sorry mr. Popham dick you already
were already well over budget and we
can't have a couple hundred thousand
dollars she said what's the value
proposition of this project and they
said well when we deliver this project
we'll save you know a hundred million
dollars a year she said right if you
don't give me two hundred thousand
dollars it will fail and they went
here's the check sometimes keeping an
eye on what the goal was what the
purpose was rather than just deltas on
the budget sheet well you said X and you
want x times 1.01 and that's not right
so we see a cost overruns we fear
schedule overruns there are vanishingly
small cases where it being 'late matters
to anyone other than the marketing
department right really I don't care
when twelve point one point one iOS
appears on my phone but I bet someone at
Apple is crying over that date right
because that's how dates work delivering
the wrong thing that's a big deal
right that's one of the reasons I'm
slightly sad that I'm giving this talk
because that means I'm not in the
audience for Gabrielle's talk which was
exactly about this delivering the wrong
thing we've gotten really good at
delivering the thing right or at least
we've spent a huge amount of time
obsessing about delivering the thing
right delivering the right thing is the
realm of product management and I still
think we're very very poor at that we're
getting better at that what else well we
deliver something but it doesn't run
operational instability it's flaky it's
crashy its data corrupting it's all
kinds of bad things are happening ok so
there's lots of things that might go
and then when we put out that invitation
to tender and we got that vendor and
they're delivering staff or they're not
delivering staff and they keep saying
are two more weeks two more weeks to
I've been the developer saying two more
weeks I know what that's like as I've
got no idea two weeks is exactly the
amount of time that I can offer that
means you'll go away if I say four more
weeks you're like that's not good enough
and if I say it'll be ready by the end
of the week you can hold me to it but a
lot of stuff can happen in two weeks so
there'll be two weeks there in two weeks
time isn't ready well no but you know be
two more weeks you can get several
months of run time it's just two more
weeks and so so yes I supply it
instability then we don't know whether
they're reliable we don't know whether
they even gonna be there right and so
what what do we do we think we confront
load the risk so we front-load all the
risk and the way we front-load all the
detail if we can plan in enough detail
everything will be fine what could
possibly go wrong there's an assumption
in that the assumption is that this is
knowable this is plan able okay so some
types of work are largely knowable if
I'm building a bridge or a hospital or a
road or something I know that the first
thing I need to do is clear the site
then I need to dig some foundations and
I need to put in some support pillars
then I need to put in my what's called
core infrastructure so your lift shafts
and all that I can tell you that I can
talk you through all of the bits of
building a hospital and I've never built
one okay at some point I'm gonna need
bricklayers I'm gonna need plasterers I
need electricians and I can tell you
roughly when that happens Henry Gantt
very very smart lad worked with Henry
Ford and Frederick Taylor building
factories in the early 20th century they
knew how to build factories they were
very good at it and that's what the
Gantt chart does it takes a situation
that is knowable breaks it into small
pieces sheduled the small pieces and
starts letting you know when things are
slipping brilliant for the class of
problems that are knowable where you
have unknowable problems
systems-thinking folks call it dynamic
complexity the can live in complexity
people they call it complex rather than
complicated where you have emergent
structure
emergent behavior it's unknowable right
when surprises happen it's not because
you didn't do enough planning it's
because you couldn't possibly have known
so by a weather where there is a classic
complex system so weather is wind water
temperature pressure right you can model
the whole of weather with those four
parameters and bit of geography but
basically that yeah you cannot predict I
cannot tell you whether it will be
raining at 7:42 on Friday okay I can't
and it's not cuz I'm not very clever
we don't have powerful enough computers
I just can't what I can tell you is
roughly what the temperature range is
going to be throughout November okay I
can tell you what the likely
precipitation so I can give you system
kind of characteristics but I can't give
you detail and so we're in this world of
trying to build stuff and we think that
we just need to do more planning so
here's where the the impedance mismatch
happens governance models generally are
designed top-down we start with a
portfolio and we do portfolio management
and portfolio management is we have a
steering groups and executive committees
and and those kind of things right and
then within a portfolio you have a
number of programs of work or
initiatives there's a PMO program
management office and they kind of do
lot of governance and reporting and
metrics and there's a program board for
each of the individual programs has its
own board of people who are trying to
steer it and then that within the pro
program you have a bunch of different
projects and the projects have project
managers and the project manager is how
and the project's had project sponsors
the person who's got the budget and so
on and got its cast of thousands doing
this to attempting to find enough detail
and so this is an it's kind of a PMP the
standard PMP project management model
right which is great except the agile
methods bottom-up so agile methods teams
go seven plus or minus two people TM
right so that's roughly how big of a
team you want you want interdisciplinary
cross-functional teams because scrum
said so you're working small time boxes
because like run it like mini projects
famously said if I'm running a one-week
project how far can a one-week project
slip in a week
about a week
that's we've probably got that I can
probably tell within a week whether I'm
slipping by a week right release
software frequently this is all good
stuff collaborate closely with the user
these are all their good agile
principles planning small time box is
based on feedback right so agile is all
about this team scale on the ground
stuff funding usually incremental just
keep on paying us and paying us and
paying us and we'll keep delivering and
delivering and and if you don't like
what you're seeing turn the money off
that's okay yeah so agile about teams
delivering small slices and acting on
feedback right which is great except
agile methods then look like this got a
whole bunch of teams delivering a bunch
of stuff which is nice okay and
somewhere I've got the boss
how am i add your team's doing and then
you say so what happens in between these
collect Underpants
I don't know something right so so stuff
happens in between and there's a chap
Richard Donal lovely lovely chap Richard
Donal as many years ago now about ten
years ago I wrote a blog post that has
been lost I can't even find it on the
wayback machine on the internet on the
archive dog I'm sure it's out there
somewhere but he wrote this lovely her
article called agile adoption patterns
the only thing wrong with it it's not to
do with agile or adoption or patterns
but apart from that it's brilliant okay
and he describes a sixth stage kind of
process what he was finding again and
again again I worked with him and
thought works for some time and he would
go into organizations and help them on
these kind of transformation type
journeys usually at fairly senior level
and he noticed a pattern of behavior in
the organization or a pattern of
adoption and so what he used to do is
used to coach CIOs and c-suite with this
pattern with his model so that they
wouldn't know what was coming he said
the first thing that happens is the
people break what does that mean well
that means that you come in with your
crazy new ideas no I'm not doing that
and and then you kind of start to
influence them and work with them and
talk to them and they go actually yeah
maybe I'll give that a try
so that's the first thing that people
break the second thing then is the tools
project planning
in tools all of the things that that
plan resources and resource leveling and
and increments and that added all that
staff stops working when you're working
iteratively when you're when you're
discovering as you go okay then the
governance breaks which is this bit okay
so the way I govern a traditional
project my illusion of control I have
all my cost metrics and my time
allocation my hair timesheets here ours
timesheets keep your hands up if you
fill them in honestly yeah no one no one
yeah no you didn't spend fourteen point
five weeks on that hours on that thing
this week they didn't you're lying right
you spent two and a half hours on it you
with an altered round someone was wrong
and read it so you have to go and fix
that and then and then oh you had to
reply to that tweet because you cannot
let that go you lose and then all the
build finish then you have to go and fix
the build
okay it's really really hard to track
and it probably doesn't matter spoiler
so once we get good at governance then
the customer breaks and I don't mean
your wonderful omniscient embedded in
team XP customer or your wonderful
equally wonderful omniscient scrum
product owner I mean you're 50 headed
senior manager screaming lots of
different agendas customer when you're
building a big program okay that breaks
and then finally you know you rain all
that in and then the money breaks right
how do we fund this stuff well we were
funding annually without out to two
weeks at year bank that's not really
gonna work talk about that and finally
if you can make it all the way through
this you get to the boss level the
organization breaks and you win okay and
now you finally have the organization
you wanted the problem is you are here
right most organizations most stages
however far they get with the air quotes
transformation they get stuck somewhere
between the tools and the governance and
so they figure well that's where we are
tune the crap out of JIRA and they
figure that's going to probably fix
things and it probably isn't right I
love this model I think it's really
powerful model the problem is the
problem with this the the step between
tools and governance agile doesn't have
enough
about large programs there's a
difference between Martin Fowler and
some of the other agile signatories and
I'll name Martin by name because I think
it's okay
during the mid-2000s the mid 2010 or
whatever so we've spent about ten years
getting good at team scale delivery and
and then people started saying what
about teams of teams what about kind of
program level delivery and they said ah
Martin you are a guru of agile how do we
do this and he was there he said no idea
I said but Martin you're a guru of agile
he said yep he said yes I am
and no idea he said because that's not
what we were doing that's not what our
John methods are about agile methods are
about delivery in the small actually
agile message are about delivery at all
right so during the 90s you have these
massive multi-year programs that would
just fail and there we go I can see why
that failed we need to do another
multi-year program to stop it wait a
minute hang on and you know repeat ad
budget right so so agile methods emerge
because people are in pain and saying
well we must be able to ship something
what if we try to ship something in just
a few weeks what would that be like and
that's what they emerged for and they're
very very good at that what they don't
have an opinion about is what happens at
scale delivery at scale is a substantive
ly different problem the way I describe
it is this a T is not the same as 8
times 10 all right getting eight people
pointing in the same direction is a
largely solved problem getting 80 people
pointing in the same direction very
different getting 800 people pointing in
the same direction that's fun right but
it's a different kind of problem okay
and so multiple agile teams can
collaborate on the same program of work
but you need to do a bunch of stuff and
funny enough that's what I'm talking
about later today but basically you need
strong technical direction that's the
first thing you need we all need to know
what good looks like from a technical
perspective otherwise we can't scale we
need strong product management as I
mentioned earlier we need we all need to
know what it is we're building why we're
building it who we're building it for
all of that stuff and we need really
strong program management we need to
know that we're all on track ok you put
the word lean in there because
I'm not saying not to have program
management that's irresponsible I'm
saying that the reductionist detail
based program management is incompatible
with iterative emergent development but
that doesn't mean we can't manage that
program it means we need iterative
emergent techniques in order to do that
okay so what we really need is what
called governing principles so Dave
snowed and professor Dave Snowden
annoyingly massive brain he talks about
complexity theory and he's been talking
recently about governing printing
constraints and enabling constraints
okay so governing constraints are the
rules of the road if you like enabling
constraints are constraints we
introduced to encourage certain
behaviors all right so governing
principles drive on the left well drive
on the right here if I drive on the left
bad things are gonna happen right so the
idea is it free you then have freedom
within a framework if I don't give you
any framework at all you don't get
autonomy you get anarchy
you get randomness happening Kent Beck
lovely tweet couple years ago said he
said autonomy without accountability is
just vacation right and this is the
problem I'm actually talking to someone
at the moment I'm gonna be looks like
I'm gonna be working with and she's
heading off a big engineering function
and she said basically what we've got
we've got all these teams and we've
grown from nothing and we've got some
really smart people and we're all using
agile methods and that this she said
that her words are it feels like there's
an incredible amount of drag right what
a lot of powerful phrase is an
incredible amount of drag in delivery
right she's like how do I surface this
how do I make it visible that we're
doing that so we want these governing
these governing principles in order to
align ourselves remember governance
about managing investment risk well then
if I'm managing investment risk I need
to look at investment and I need to look
at what I'm getting for that investment
and so what's the metric that I used to
see what I'm getting for my investment
that's like a question so you can say
stuff what's the number like oh how much
I'll give you how much return do I think
I'm getting for this investment
or ward you will make all that metric
return-on-investment yeah so so but the
thing is ROI it's a blunt instrument
okay it's a blunt instrument because
it's missing a really important piece of
information
ROI doesn't tell you when they invest
all this money and but I don't know when
I'm gonna get my return okay
I also don't know how much is at risk
which is kind of worrying so I'm gonna
drop all this money for years and years
and years
GDS government digital services in the
UK which is the the digital program in
the UK government to drag it kicking and
screaming into the 21st century it only
came to be because there was yet another
disastrous massive government IT failure
this one was in the health service and
it cost 18 billion pounds of I'm a UK
taxpayer that's my actual money about 18
billion pounds and the net output of
that entire program of work was I think
even the British government got
embarrassed about that right which is
nice because then they finally got some
digital smarts which is long overdue
okay but this is the thing there were no
checks and balances to say we look you
know we're sixteen billion in when are
we gonna call it time right well let's
give another couple of billion see what
happens yeah so I don't understand that
I don't understand why there wasn't an
ROI they weren't using something more
sophisticated than ROI so the chap
called Chris Matz
wonderful wonderful product manager
consultant in the UK and he told me
about this thing risk-adjusted return on
capital risk-adjusted return is how you
priced bonds how you price financial
instruments so early with a bond a
government bond you buy this government
bond and and the government pays you a
small amount of money a regular basis
and so you price government bonds
differently from long-term contracts
because the idea is that money now is
worth more than money later so even if
it's the same amount of money if I'm
going to get that money in December I
value that as higher as the same
contract is going to give me that money
in June next year okay risk adjusted
return
it's much more useful number it tells me
when am I gonna get that return how is
it gonna work when you look at a jold
delivery models they actually have worse
risk adjusted return why because you
have transaction cost so every time I do
my little iterative releases and my
little iterative ceremonies and all that
there's a cost to that but I don't get
if I just fly blind for three years yeah
so so there's those transaction costs
add up and that means that I've got
worse ROI it's costing me more money to
get an investment initially at least
right but it has much much better risk
adjusted return okay I did say there
would be math in this is gonna be graphs
at least so yeah so this is our
traditional delivery model that's a
little traditional graph and what we're
gonna do is going to spend this works
[Music]
we're gonna spend a bunch of money money
money money money money there we go and
then we're gonna carry on spending money
so what this looks like this amount of
money this amount of sunk cost
so there's value at risk so if the whole
thing fails right now that's the amount
of money I don't have anymore okay the
more the value at risk the more I am
subject to what's called the sunk cost
fallacy which is this well we're already
sixteen billion in how much worse could
it get two billion is how much worse it
could get two billion if anyone needs
the answer to how much more it's gonna
get off to 16 billion the answers
another two billion and then you stop
okay so so yeah well we have whenever I
here we have an investment in you have
to use Oracle in this situation it's not
an Oracle problem yes but we have an
investment in Oracle what does that mean
that means the more people I can inflict
it on right the lower the cost per use
and the less of an idiot I look because
we didn't have an Oracle shaped problem
oh I see right and for Oracle substitute
any other big product right or big
vendor it's my value at risk the other
thing that this represents is
uncertainty these are how much untested
work I've done I've done all this work
and I haven't tested any of it so I've
now got uncertainty and I've got value
at risk
brilliant right and then finally I do
release yeah and I really really hope I
was right
okay and now I do this release and I
start making money but then of course I
carry on with my incremental funding on
my project and that's that line going
now so that's what traditional delivery
looks like agile delivery same sort
lines again same sort of shape but now
you notice that we've got much much
smaller value at risk okay
and the reason there's a much much
smaller value at risk is we do these
frequent small releases and because
we're doing these frequent small
releases and then spending money and
doing a release and spending money and
win-win-win thing the first thing is
we've got much less value at risk the
second thing is we get feedback so we're
able to steer based on what customers
think right or based on what a
stakeholders thing like I hate you know
this is pretty cool or this is rubbish
okay well luckily we only went a short
way down the rubbish path let's try
going down a different path and the cool
thing is it becomes self-funding right
this program is now paying for itself
yeah so actually and it works like a
startup I actually only need seed
funding if we're building something that
is genuinely valuable I only need seed
funding I can either and this works on
so again reasons for doing work right
I'm going to make money I'm gonna save
money I'm going to protect money right
it's going to act as a barrier to entry
come barrier to competition so if I'm
saving money and I've done this in
organizations we can solo what if we did
this piece of work well it would save
you know X million pounds a year or
whatever well let's start let's start
but let's ship a tiny part of it there's
always a power curve with those kind of
conversations right it'll say even 100
million dollars a year right but it's
not just if we deliver this thing bang
there's a hundred million dollars a year
that's made up of lots and lots and lots
of bits of detail really example from a
bank I was working in all sort of all
the examples of banks have really dull
but one bank I was working in they deal
with quite a lot of trading by quite a
lot I mean 11 percent of the world's
equity trading goes through their
systems they have a trillions of dollars
a day of flow trading it's quite AI
watering and so what happens at the
of the days trading is what's called
operations and operations is matching
all of the counterparties yeah I sold
you a thing and you bought the thing and
that's we got to figure out the both
sides of that and and put it somewhere
and then there's netting so if we've
done 28 trades with each other rather
than 28 little payments we figure out
who owes who what I go I owe you that
much and then we're done and so on and
so the idea is you take all these
hundreds of millions of trades and you
met them all together and you match them
all up and they add up to zero and they
never add up to zero and that's
operations is Oh didn't add up to zero
again yeah we should go find out why and
so the operations part is really
expensive because it's lots and lots and
lots of these deals that we've got to
try and figure out how to match and we
know that if we could make them always
out to zero we would save a lot of money
but it's not a single fix we know that
there are many many classes of what are
called breaks or fails like the bits
that don't match up and we can
categorize them and we can say well
let's see what's the most common type of
break or what's the most time-consuming
or expensive to fix kind of break let's
go after that and that might only be a
few weeks or a couple of months of work
on this 3-5 year program and so within a
few weeks we can then put that into
production and guess what that class of
problems goes away that amount of work
doesn't need to be done now so we can
start iteratively there are surprisingly
few again situations where it's all or
nothing if you're launching a space
craft okay that's fairly binary you know
it goes up oh it doesn't go up or worse
yeah and so there's a whole bunch of
things that you really do need to line
up most of us aren't putting rockets
into space let's be honest most of us
are doing yet another iteration on their
internal reporting app right that's kind
of what how we roll right
there's someone was saying I was a
lovely thing when when Elon Musk landed
a a completely unmanned rocket onto a
completely unmanned raft in the middle
of the Pacific those say again I'm
trying to studying debug react
but difference in kind of things that
one does life well so this means that we
need to rethink our underlying
assumptions okay so the first thing we
need to rethink is this flow a value
much more important than utilisation of
workers okay so are we getting results
right are we getting results more
important than our people busy we
measure busyness and there's a reason we
to help right why do we measure busyness
rather than results well let's look at
the history traditionally it takes a
very very impact your work has is
distant in space and time from when that
work happened and a lot of organizations
that distance in space and time might be
years right there's it's really hard
almost impossible to correlate we did
this work with we had that impact and so
because I don't have a value lever the
only lever I've got is cost well I just
double down on the cost leaver don't I
right so I'll try and make everything
cost left costing less that'd be great
oh can we get rid of some of your team
cost in that so instead if we can say
look we can if we work in small enough
chunks we can correlate the work we're
doing with the impact is having and so
that means then we can decide how we're
going to do that work let's measure the
crap out of results let's measure the
then we can relax about things like
utilization and busyness okay feedback
we need feedback to reduce uncertainty
normally we don't even think about
feedback because we're convinced we know
the answers because the problems
reducible if it's irreducibly complex we
don't know the answers newsflash if we
in a car you don't get in the car just
point it you're getting in a car and
you're continually doing these tiny
little adjustments okay as the traffic
moves as lights change every now and
then you might need to slam your foot on
the brake because someone runs out in
front of the car or something okay but
you're continually adapting to feedback
the macro story is I'm getting in my car
and I'm driving into town and I'm going
to go to the light so I'm gonna turn
left and I'm gonna go to the other
Junction depending on how busy it is
I'll go right or I'll go straight across
I can tell you that basically the plan
yeah but I could also tell you that I
cannot tell you minutes to minute what
I'll be doing I can't tell you where
Road because I don't know where everyone
else is yeah it's a complex adaptive
system so feedback is vital to reducing
uncertainty and that means that lead
time lead time is the only game in town
lead time is your quality metric it's
your value metric lead time i describe i
define lead time as the time the wall
clock time between a commitment and
thank you right
that's lead time so so I I'm going to do
something for you here here I made you a
thing and what do you say thank you so
these lovely yeah I say I made you a
thing and what do you say and she says
it's the wrong thing really sorry I need
to go back and I need to fix it and then
I come back and I say here I made you a
better thing what do you think do you
like it yeah what do you say thank you
see and that's the great thing with lead
time if you get lead time - thank you
incorporates things like rework and
errors and all of that because all the
time you're delivering buggy crap that
doesn't solve the problem no one said
thank you yet right so I don't care
about time to production I care about
time to someone actually getting a
benefit from the work we did and
sometimes that's infinity because they
never did okay so lead time is the only
game in town
hmm okay so what can we do to manage
lead time well reduce batch size okay
that's the first thing we can do work in
smaller chunks smaller chunks get done
quicker than bigger chunks and it's not
linear it's not even exponential it's
what's called an asymptote which means
the bigger the chunk the closer to
infinity long it takes right that's a
really long time okay
small batches get done quickly okay and
funny enough small batches have less
variability in them which is a nice
bonus okay so there's a wonderful paper
from many years ago 2004 I think three
project managers that sort works again
wrote a wonderful paper still out on the
Internet's called the slackers guide to
project tracking okay and the slackers
guide to project tracking what they did
across a number of projects is they kept
two sets of graphs two sets of burn up
charts one of story points that estimate
story points and then measure all the
and their prediction
of when and how much and whatever and
one of just stories so how many cards
have gone through and what they
concluded was that the graphs from just
measuring stories and measuring story
points were basically the same graph so
there was no additional benefit to
measuring story points right my favorite
part is the conclusion the conclusion is
and so that means if you keep them all
reasonably small the variance doesn't go
crazy and you can just call them all one
how big is this story one how big is
this story I'm ready I'm ready for you
right you need a lot fewer Fibonacci
cards so also the size one what they
also discovered and then it got
forgotten and I tried to reintroduce it
in behavior driven development but they
also discovered by accident was this if
at the point you're describing the story
the feature you also talked through the
acceptance criteria for that feature
they tend to all be much more similar
sizes hmm and the way they would do this
is this they'd look five by three index
cards and on the front of the game it's
kind of right you know store customer
details or whatever it was and on the
back he'd write the acceptance criteria
okay so I need to store address name and
then what about multiple addresses we'll
do that later
multiple addresses later one address for
now okay so that's the acceptance
criteria so now it bounds and the great
thing with a five by three index card is
even if you've got small writing you
can't get that much on there yeah the
natural bounding okay and so they had
these five by three index cards and that
was how big a story was and on the back
he'd write acceptance criteria and that
meant that all stories were size one
okay so reduce batch size keep work
within the team okay anything with lean
operations this should be very familiar
okay any work that leaves the team ends
up on someone else's backlog and even if
they're super committed and super keen
on helping you and it goes straight to
number three on their backlog I've only
got two things ahead of it and a week
later you go where's my thing and I go
it's still at number three why
number three where things keep hopping
over it but it's still number three but
yeah we've got a different one and two
now great okay how long has it been
number three I've been a while and and
why because some other people much more
shouty than me needed items one and two
right and so this is the thing you now
you have no control over work that's
outside of you're outside of your world
so inspections and reviews right code
inspections code reviews if you're
blocked on some X inspection or review
bring that into the team and then well
identify it what we need to govern with
so I made up an acronym VESA so I sold
parts of this right so one so the e1 of
the esses and one of the aids comes from
engineering and I added some stuff so
once they visualize right visualize your
value stream mapping event storming
whatever works for you to visualize
right so visualize make sure you can see
what the work looks like then whatever
your work is what are we just doing cuz
we just do it and what are we just doing
what can we get rid of so eliminate what
you don't need to eliminate the
vestigial stuff the stuff that's there
cuz we've always done it
whatever's left simplify that can we do
those three things as one piece why do
we have to do that and then that and
then that again can we just combine
those into a smaller simpler thing once
we've simplified then we try and
standardize and finally for extra credit
we can automate the standardized stuff
okay I see this as a kind of a virtue
journey right it doesn't matter how far
along this you managed to get you did
good in the world right we only got as
far as eliminate that's fine celebrate
that we've got as far as simplified
whoo-hoo we're going to standardize
brilliant we automated itwe have a bonus
today off holiday meal it doesn't matter
how far you get along that line you did
good and then what we want is a process
becoming self evidencing what i'm
hearing called
continuous compliance which is making me
happy in a quick example 18f so this was
again right you only get really good
stuff after a really big disaster
so healthcare.gov Obamacare went live
well for values of live it turned out it
just collapsed catastrophically on day
one it could deal with like you know
twelve concurrent users or something
and 300 million Americans wanted to sign
up so didn't look good so a bunch of
jokers call 18f approached Obama and
said look it's a website right yes yes
it's a website I said so we're pretty
good at websites why don't we go fix
this that'd be great so they went to
fixed it and they started work and they
said okay well so how do you fix a
government website and they said our
thud poom you'll need to read these
documents so this chart there are 200
there are 325 325 sets of regulatory
documents not regulations documents full
of regulations in order to build a
government website and they went oh
that's how you can spend a billion
dollars on it that law and so what they
did which I thought was rather brilliant
is they they split these regulations
into Devon ops and it turns out about a
third of them are dev and two-thirds of
them are ops in terms in other words a
third of them are to do with the stuff
you're building and how you're building
it and version control and stuff like
that and the other two-thirds are to do
with things like operational stability
data at rest security compliance yeah
the other and they said hmm if we built
a platform where all of that was just
true anything you put on it is already
compliant yes I guess it is and so they
built it they call it cloud gov and if
you're a US public servant anywhere you
can just put stuff on it okay and these
different bits of cloud go so there's
like you know most depending on whether
you're doing stuff that's got national
security implications or personal data
implications or health data implications
there's different levels of compliance
in there but basically once your stuff
runs on cloud Garfinkel FedRAMP now once
your stuff runs on FedRAMP it's gonna be
fine and so they managed to completely
automate 269 of these constraints into
cloud gov another forty-one are
basically templates that's what shared
means so you know you spin up your
project and it's basically copies a
template of another project that has
version control has testing has test
automation has a build pipeline has all
that that's 41 of them
leaving you with 15 which is still quite
a lot of work but it's not 325 so now to
start a new thing the 15 are again
they're pretty straightforward
do you have source control check there's
stuff like that and that means that now
US government projects can start much
more quickly and much more effectively
and be much more confident that they're
doing the right things than they ever
used to Thank You 18f that's very cool
and so and GDS in the UK has done
something similar and I'm working with
an enormous German bank that's basically
done a very similar thing they now have
exactly the percentage but a significant
proportion of all new work at this Bank
is being done on this platform and
they've introduced a new rule a new a
new release process for what they're
called small releases and if your
release is a small release if it's
within certain parameters you can use
this much more streamlined release
process so his vision my buddy his
vision was idea to production safely in
a day that's - thank you right and he
slammed there he's now idea to
production in a half a day so in a big
heavily regulated slow-moving German
Bank you can decide you want to make a
change have that change in production in
front of actual users by lunchtime right
that's pretty cool and so a lot of these
projects in our kind you know that's
only for small changes and we've got
this big project we're gonna gain this
we're gonna chop our big projects into
lots of small releases so we can use it
he's going ok do that then winning and
and this is the thing is that once you
have those enabling constraints you
don't have to use this platform that's
an enabling constraint but if you do if
you slice your stuff into small pieces
so you can you can go home early you
don't have to do all that governance
stuff because he already did it for you
so then wrapping up governance is about
managing investment risk
that's it what am i spending my money on
is it safe okay
iterative delivery methods reduce risk
and surface uncertainty so we can see it
which is kind of cool
but your governance needs to change to
benefit from this if you have reductive
detail focused governance you cannot
possibly
the benefit from iterative emergent
information you already planned it okay
all software development carries
uncertainty newsflash
talking to a room for the software
people it's like we already knew we
can't eliminate uncertainty okay we can
surface it early and by using these
controls and using these approaches it
means that we can get much better handle
on what it is we're trying to do so we
just need to shift our governance to
follow the iterative world that we're