- Principle number four, build incrementally
with fast, integrated learning cycles.
Kind of self-obvious isn't it?
Let's talk about it a little bit.
I've, honestly, struggled for years
trying to describe agile and waterfall
in as clean of terms as I could
showing the various benefits and it's always been hard.
This incremental development thing is
not an easy thing to explain.
But at some point I cam across, I don't remember when,
I just came back to the original, fundamental
Scientific Method, and the Scientific Method says
there's something I don't know and I wanna learn it,
what do I do?
I put forth a hypothesis, we're gonna hear
that word a lot more later, I create an experiment
to test the hypothesis, I run the experiment
and I evaluate the results and I adjust and I do it again.
That's called, in Deming and Shewhart's world
that's called plan, do, check, act,
that's the basic, in their view, process, control,
continuous improvement cycle, plan, do, check, act.
Now if we think about this a little bit
and we think about the former slide
which showed our waterfall processes
creating a result, how many times did I plan,
one, how many times did I act,
one, and how many times did I check, one.
It's not that you didn't do a plan, do check, adjust cycle,
you only did it once.
So you headed down this path of massive uncertainty
building a system you've never built before
with one chance to get it right,
I don't think that's a really good plan.
So what we wanna do instead is have lots
of those cycles, right.
Apply fast learning cycles, we wanna go very quickly
through this process learning as we go.
Lots of little PDCA cycles.
What is a sprint in (inaudible)?
We plan the sprint, we execute the sprint,
we review in retrospect and we make adjustments
for the next sprint, it's nothing more than that.
So the easiest way I think to describe the difference
between traditional development or stage gated development,
agile development, is not by the manifesto,
it's how many times you have to plan,
do, check and act, how many learning cycles do you get.
And by the way, the faster the cycles the faster learning.
And this does a lot of things, it improves the efficiency
by decreasing the time between the action and effect
because it's really quick.
So here's my action and here's my effect
and now I have to remember what went wrong.
Well guess what, I've got feedback on that piece right now.
So the feedback is ready, I coded that thing
just a week ago and now I see why it doesn't work.
That's really fast.
Versus, holy cow, I think those of you
who write software out there as I used to
know the following paradigm, you wrote some software,
it's been six months, you open it up,
you look at it and you go, oh, my goodness,
who wrote this code, blah, blah, blah,
I can't believe, oops, those are my comments.
You forget your stuff, your mind moves on to new things
and it's very difficult to go back to that.
In addition, obviously we reduce the cost of risk-taking
because right here I can pivot.
I can go, oh, good sprint, bad system,
let's change the design in the system.
This is facilitated by small batch sizes.
Why, because I need just the amount of work
I can do this batch, I'll just call a little back log here,
in that period, I don't need this gigantic thing.
And if I only have this gigantic thing
I have to bust it up.
And if I'm being held hostage to proving
everything on that gigantic requirements list
over time, then I don't have a small batch size
that I can work with.
So we need small batch sizes to move it through the system.
And that requires an increased investment
in development environment.
I saw a talk by Jez the other day
where he talked about the HP case study
that's online building printers applying DevOps
talking about the fact that they dramatically reduced
the nonproductive time overall, I don't remember
the exact numbers, but one net effect
was a lot of the nonproductive time
was now invested in test automation.
Leaving, I think, four or five times
the amount for actual coding and innovation.
So we may have to do that.
We're gonna have to change the way
our investment profile works.
But with that automation, the shorter the cycles,
the faster the learning.
Fast learning cycles, plan, do, check, act.
One of my favorite reads and strongly recommend to you
is Dantar Oosterwal's The Lean Machine,
it's the story of Harley-Davidson back in the 90s,
you're probably not old enough,
but I remember riding a Harley in the 70s
and they were cool, they were the coolest machines ever.
If you've never ridden a Harley,
you almost have to, it's a really cool thing to do.
And then the Honda Gold Wing Coupe came along
and all the sudden it's very different,
all the sudden there's this really fast,
much more reliable machine and Harley went into trouble.
So they decided to do adopt lean
and they were coached by Dr. Alan Ward
was their mentor and you'll see that in the book there
and they went through the process
and Dantar has a lot of learning in there
that I think are synthesized so well.
One of them is that, "Product development
"is a process of converting uncertainty to knowledge."
Oh, yes, that's it, I don't know.
And having specs helped me know what I think
I need to do, but I don't really know.
So it's okay not to know.
So in agile and lean thinking, it's okay not to know,
we're gonna convert uncertainty into knowledge
and those are controlled by integration points.
So we come back to the PDCA cycle
and what do we see?
We see, well, if this is just, for example,
I'm working on the engine and I'm migrating the engine
more quickly here, there's a new carburetor
and I'm getting feedback by that,
my carburetor's working pretty good,
seems like the engine runs, but the engine
hasn't been hooked up to the new drive train yet.
So I've got some new horsepower, can I handle it,
I don't know 'cause all I've done so far
is prove that the new carburetor works.
And by the way, does the engine and the drive train
and the frame all hold together to make a great Harley?
Well that's a bigger cycle.
So what you see in safe is based upon this principle
of synchronous, harmonic learning cycles.
These cycles are the same, these cycles are the same
and the slowest one is what controls
the overall rate of learning.
Development can proceed no faster than the slowest point.
So I don't really know if I have a full Harley.
Now I don't really know if I have a full carburetor
til here, so imagine all the experiments
you could do in that time frame.
Important learning, nested PDCA cycles.
I really wanna think about the problem.
And you see that in safe, you see the team iterating,
you see they are using those together
to integrate the system.
You see the PI cycle so that the arts
can come together with more to do.
What he notes here is what's built into safe.
Improvement comes through synchronization of design loops
and faster learning cycles.
That's how you get better.
Synchronized the loops, shorten them.
So if you're running three week sprints,
run two week sprints, if you're running two week sprints,
think about running shorter sprints than that.
Really, really fun learnings from the Harley-Davidson story,
it's also a really fun read.
What's the net result of that for risk?
People with a traditional perspective say,
where's the risk mitigation plan in safe?
Where do yo manage risk?
The risk mitigation plan in safe
is the fact that integration points reduce risk,
objective evaluation working systems
that we'll talk about in a second
is the thing we use to reduce risk.
Now, what Harley also points out
is that they always thought that they were building
good Harleys and sometimes they would go out here
and crash and burn, well maybe not literally
crash and burn, but not have a good release.
And they're going, well, what is this?
We thought we were building a Harley
and we did build it, it just didn't really work.
It crashed and burned at the end.
They call that false positive feasibility.
That's managers worst nightmare.
I think it's okay, but I'm not.
That false positive feasibility
represents the risk that remains inside
the waterfall project until such time
as you've done a full integration.
You don't know until the integration happens.
So that risk remains, all that risk in the project remains.
Well we start out agile development
with the same degree of risk for sure,
but we move very quickly down this path.
Each iteration, sprint, PI, whatever you wanna call it,
whatever that frequency is reduces risk.
So when we get to the end we're truly done.
This is the boring release of your next CRM system,
the next big release of our framework
on top of the latest version of WordPress, it's boring.
Why, because we found all the problems
and addressed them integrally.
So those are absolutely critical ways
to think about mitigation of risk.
So if you're working with folks
that believe that risk is an issue,
and they should, we have an answer for that
which is, yeah, we're gonna address the risk
right upfront by basically integration points
and objective evaluation of working systems,
which is principal number five.