A talk about reinventing process, figuring out what we want to do well and influencing workplaces

1. Leeroy Driven
Development
Leeeeeeroy Jeeeenkins
John Nicholas
john.nicholas@dinoroar.io
No, I’m not hiring. I want you to hire me though.

2. Last talk ….
Was all about coupling and so complexity.
This talk ….
Reducing Coupling and Complexity in our Delivery Process

3. "organizations which design systems ... are constrained to produce designs which
are copies of the communication structures of these organizations."
— M. Conway[2]
“When placed in the same system, people, however different, tend to produce
similar results”
- Demming
“Subordinate the System to the bottleneck”
- Eliyahu M. Goldratt

4. Graph taken from here: (Enjoy the irony because we all know that following indexes is better than results from active traders)
https://www.marketcalls.in/trading-lessons/the-dunning-kruger-effect-what-differentiates-novice-and-expert-traders.html

5. The Problem with
Dunning-Kruger is:
What if you are the
stupid one?

7. What on earth is
the point?

8. Meet Leeroy the Developer
● Pushes code 5-6 times a day - ‘Yeah its in prod’
● Acts in a fairly autonomous manner (No I in team … no U either)
● Away talking to people in other areas of the business - Not Coding
● Can’t use git - doesn’t branches
● ‘Is this really important? I’d rather do this’
● ‘Do we really need meetings?’
● ‘Hey do you want to go and chat for 5 mins?’

9. He is
a colossal pita

10. But what if? ….
● Commits because total confidence in Deployment Process
● Less QA oversight because QA already put quality into the tiny iterations
● Walking around talking to customers (consumers of work product) - whilst
others wait on responses via slack / email
● Not branching because confers no benefit to continuous integration
● Not checking emails because pairing
● Questions because trying to get at the assumptions and test them
Demming is all about understanding the effect you have on the system beyond your role - what if
Leeroy empowers others to also be able to do this?

11. Sounds
Reasonable
Doesn’t
It

12. Competative
Advantage
Amount Of
Work
DDD
- Very costly to balls up
- Huge payday if win
Buy It
Do It Now
- Iterate later
- No time to think
Work on
Practising
Being Good
Where to play (Enterprise) ? ….

13. #Trust

14. No Relationship = No Trust
● To Leeroy EveryLeeroy is Leeroy - you have to treat everyleeroy as leeroy
● You cannot tell people into trust - you have to come along together with them.
Trust is born out of a sustained lack of fear and building empathy in a relationship
with someone
Then we can start experiments
(Change management, cognitive dissonance, emotional drain, resilience, one to
ones, servant leadership, who is your customer in varying situations, what do they
think they want? What do you think they need? Is that what they are telling you?
Subtle subtle cues)

15. #Fear and
Process in Las
Vegas

16. Process as (and is) a response to Fear
Process should used for testing hypothesis as a proxy for trust.
Sadly:
‘Things gone wrong! People must be wrong! Process make People Work Right!’
The problem: If process is antidote to fear of failure then when met with failure the
options are
1. More Process
2. Process Better
Why not Less Process?

17. Why do our boards all look the same?
Backlog : 3 amigos : dev : QA : pre release : released : done
● if we can build trust then can we abandon the idea that process is necessarily
good? - Let’s start from our desired behaviour and fix problems
● If we can demonstrate value in a change then that change will just take root.
● We can experiment via helping someone else fix their problems.
One cannot simply delete all the jira columns.
No, we need to go on a really long adventure

18. Find someone to
Help (QA!)

19. The QA probably
feels the same
way about this
stuff as you.

20. QA probably spends time on regression
● Get blamed when deploy fails - and have no ownership of the process
● Probably running manual regression - time / unreliable
Go bring them into development, make friends, find what annoys them and fix it.
● One 2 ones - listen: there will be low hanging fruit
● Pairing - do your job and their side by side
● Discover that actually you want QA Driven Development
● QA gets to start doing things like exploratory testing

21. How To Leeroy ...
1) Do not branch ever
2) Make you local environment the same as your target environment.
3) Automate deployment of basically nothing all the way to production from a
console command.
4) Deploy things that measure the health of the ‘service’ this will become
integration test points to test if deployment was successful - make that script
assert against them.
5) Show the QA, bring them in - add to it until they are happy
6) You are deploying automatically all the way to production. Congratulations.
7) You are also running tests on production
Now work with the QA to both add value and *protect* value. Feature flag,
duplicate + modify then replace (Doubly so in microservice world)

22. Your company
probably cannot
deploy very well

23. Do not ever
deploy / commit / write
‘work’ that you cannot
turn off

24. The QA comes FIRST
Write The Assert First

25. Let’s make
friends with a
BA / PO

26. Now you connect to value
● QA generally extend the scope - BA/PO should generally reduce via
prioritisation and trimming the fat.
● Now the feedback loop from changing priorities to deployable code is 3
people at a desk working alongside one another together. There is something
Heideggerian going on, it feels good.
● Now the dev column collapses into the 3 amigos column
Now the Board looks like this
BackLog : 3 Amigos : Deployed : committed

27. You *can* Deploy
before you
commit!

28. LEEEEEROY
JEEEENNKINS

29. Why deploy before commit?
● No One cares if it works on your machine
● We want stakeholder buyin during value creation.
● Replace a build process with a continually integrated deployment process.
● A successful state of deployment consists of deploy + all tests successful
● Our tests are built by the QA, if the QA has no confidence in the tests then it's
time for a conversation. LISTEN and then implement.
● The key is to take control of the dependencies as part of the deploy process.
Terrified yet?
….

30. Deploying before committing feels wierd
● Code does not go stale
● Makes everybody acutely aware that everything they do will go live.
● Everything gets very serious and very fast paced
● Everything gets *really* safe - you can try things and refactor confidently.
● It subordinates everything to the weakest part - verification and deployment.
A thin slice is not just a small incremental commit. It is a small incremental
deployment that unlocks a piece of value.
This requires bringing all parties together to focus on this goal of forwardness.
The thinner you slice the harsher deployment becomes.

31. Thats it, highly condensed
Lots more things to think about
● Taking Lean Startup ideas and applying them to dev processes
● Haven’t gone into the PO / Customer Value stuff at all here
● Hopefully the experiment -> measure -> learn loop visible in relations
● Cycle of adding value to your customers and bringing in next column left can
be extended all the way out.
● Smashing lead time.
● Consider this with little inventory being built up and elaborated against a 6
month+ inception / queueing period many companies employ
● Working closely with people like this increases friction. Focussing on building
relationships and helping others to practise this almost kata style is very
powerful.

32. Who Is Leeroy Jenkins
1. If you do not know who he is, google it. Giggle, enjoy
If you do know who he is then maybe you didn’t know this: (Spoiler Alert)
1. It was staged, the guild wanted to recruit.
2. He's made no money on the back of it
3. Private Leeroy was cut from the warcraft movie
4. Its weird how much you discover you don’t know whilst failing to find a gif

33. Thank You - Its
over now.
Questions?