Slide 1

Slide 1 text

No content

Slide 2

Slide 2 text

Agile software development has its roots in the lean manufacturing paradigm Toyota Production System 
 (Just In Time)

Slide 3

Slide 3 text

Defects ➡ Bugs Overproduction ➡ Extra features Transportation ➡ Task Switching Waiting ➡ Delays Inventory ➡ Partially done Work Motion ➡ Handoffs (Over) Processing ➡ Unneeded processes Agile software development has its roots in the lean manufacturing paradigm The seven wastes in Lean Software Development

Slide 4

Slide 4 text

1. Just In Time 2. Jidoka 3. Poka yoke 4. Kanban 5. Kaizen Agile software development has its roots in the lean manufacturing paradigm

Slide 5

Slide 5 text

Agile software development has its roots in the lean manufacturing paradigm While lean manufacturing is primarily focused around optimization Modern Agile practices will add a systematic innovation process

Slide 6

Slide 6 text

Software is eating the world More and more major businesses and industries are being run on software — from movies to agriculture to national defense. Over the next 10 years, I expect many more industries to be disrupted by software, with new world-beating Silicon Valley companies doing the disruption in more cases than not.

Slide 7

Slide 7 text

Software is eating the world

Slide 8

Slide 8 text

Software is eating the world

Slide 9

Slide 9 text

Software is eating the world And Space X is the most valuable private company with a valuation of $125 billions

Slide 10

Slide 10 text

We have gone full circle Manufacturing Software Engineering Lean Agile

Slide 11

Slide 11 text

www.lilobase.me Let’s reset Agile (at scale) @lilobase #Lean&AgileDay Arnaud LEMAIRE

Slide 12

Slide 12 text

1. The Two Pizzas Team model (skunk works team) 2. Strong alignement with explicit ownership 3. Tighten your feedback loops

Slide 13

Slide 13 text

A fictive project Compliance Operation Development Test Marketing Engineering & Design Functional 
 Analysis Program Manager

Slide 14

Slide 14 text

A fictive project Engineering & Design Functional 
 Analysis Development

Slide 15

Slide 15 text

Cross functional team dedicated to a project

Slide 16

Slide 16 text

Cross team direct communication

Slide 17

Slide 17 text

Introducing the Skunk Work team model The term originated in the 40s for the Lockheed’s Advanced Development Projects Division. Skunk Works was run using « Kelly's 14 Rules ».

Slide 18

Slide 18 text

Kelly’s 14 rules (extract) The Skunk Works manager must be delegated practically complete control of his program in all aspects. He should report to a division president or higher. The number of people having any connection with the project must be restricted in an almost vicious manner. Use a small number of good people (10% to 25% compared to normal). A very simple drawing and drawing release system with great fl exibility for making changes must be provided. There must be a minimum number of reports required, but important work must be recorded thoroughly. The inspection system, meets the intent of existing military requirements and push for more basic inspection responsibility back to subcontractors and vendors. Don't duplicate so much inspection. Funding a program must be timely so that the contractor doesn't have to keep running to the bank to support government projects. There must be mutual trust between the project organization and the contractor with very close cooperation and liaison on a day-to-day basis. This cuts down misunderstanding and correspondence to an absolute minimum. Because only a few people will be used in engineering and most other areas, ways must be provided to reward good performance by pay not based on the number of personnel supervised.

Slide 19

Slide 19 text

Popularized by Amazon through their Two pizzas team « Two-Pizza Teams work like semi-independent entrepreneurial hothouses. Insulated from the greater organisation’s bureaucracy » - John Rossmann

Slide 20

Slide 20 text

Diseconomy of scale in knowledge works Comstock 2011 « We conclude that a 3-7 person team has the best performance » Putman 1997 « Best in Class projects used smaller teams (over 4 times smaller, on average) than the worst performers. » Armell 2006

Slide 21

Slide 21 text

- Not a signi fi cant management overhead - Minimize communication overhead - Minimize inter-locking phenomenons - Minimize over- engineering Why smaller teams perform better ?

Slide 22

Slide 22 text

But beware, your team size may be bigger than you think Team A Team B

Slide 23

Slide 23 text

But beware, your team size may be bigger than you think your true (but hidden) team size The size of your team is the number of people who need to synchronize their work.

Slide 24

Slide 24 text

Project Manager / 
 Product Manager / Product Owner Don’t try to scale Agile Descale your Organization

Slide 25

Slide 25 text

Smalls, autonomous and cross functional teams First ingredient

Slide 26

Slide 26 text

1. The Two Pizzas Team model (skunk works team) 2. Strong alignement with explicit ownership 3. Tighten your feedback loops

Slide 27

Slide 27 text

Autonomy is not a given This is where a lot of companies react 
 by increasing procedures and controls

Slide 28

Slide 28 text

It is all about alignement Autonomy Alignement Most organizations see them as 
 both ends of the spectrum

Slide 29

Slide 29 text

Autonomy and Alignement are indivisible Micromanagement 
 & 
 Mindless execution Autonomy Alignement Confusion 
 & 
 Inaction Misdirected 
 Actions

Slide 30

Slide 30 text

Alignement require clarity Then you add clarity: - A common understanding of goals and objectives - People can make rapid decisions without seeking approval - Standards and agreements - Where the autonomy starts and ends is essential to rapid, high-quality decision-making. It start with a (long term & inspiring) mission Explain the why, give goals, not procedures!

Slide 31

Slide 31 text

Explicit boundaries allow for 
 better collaboration When boundaries are unclear most people will not explore, but rather keep their head down and play it safe. Stepping over invisible boundaries invites punishment.

Slide 32

Slide 32 text

Autonomy require competency (mastery) As an of fi cer, David wanted to give more autonomy to the crew. But it was a disaster. Unused to their new-found freedom, the crew members made mistake after mistake. They did not have the competence for that level of autonomy. To perform well, teams need to be competent. They need to know how to deliver the optimal solution using the most appropriate technical practices. In other words, team members need to be skilled at their craft.

Slide 33

Slide 33 text

The secret sauce: cohesion (trust) Aristotle project: « What makes a team effective at Google? » The researchers found that what really mattered was less about who is on the team, and more about how the team worked together, and the fi rst factor was « psychological safety » within the team.

Slide 34

Slide 34 text

This is not a justification to avoid difficult conversation

Slide 35

Slide 35 text

Autonomy and Alignement are indivisible Autonomy Alignement Clarity 
 (Vision & shared understanding) Competency 
 (Mastery) Cohesion 
 (Trust) Don’t forget the third A: accountability!

Slide 36

Slide 36 text

Its is aligned with personal drivers Autonomy: the desire to have control over what we do Mastery: the satisfaction that comes from becoming better at what we do Purpose: the feeling that we are doing something that matters

Slide 37

Slide 37 text

Turning followers into leaders From Command & Control – Submerge the ship! – Aye aye, sir! To Shared Understanding – Captain, I intend to submerge the ship. Water depth has been checked and is four hundred feet, all men are below, and the ship is rigged for dive. – Go ahead.

Slide 38

Slide 38 text

Create alignment to provide autonomy with clear ownership through explicit boundaries. Second ingredient

Slide 39

Slide 39 text

1. The Two Pizzas Team model (skunk works team) 2. Strong alignement with explicit ownership 3. Tighten your feedback loops

Slide 40

Slide 40 text

Longer feedback loop leads to bigger defects « The wiring wasn't following the expected routing through the fuselage, so when we got to the end they weren't long enough » said one German mechanic. He asked not to be identi fi ed out of fear that he might lose his job. "The calculations were wrong," he said. "Everything had to be ripped out and replaced from scratch."

Slide 41

Slide 41 text

Engineering is about feedback loop Empirical De fi ned Chem ical Electrical Civil Aviation Aerospatial Biological Formals methods were developed to save money when prototyping is too costly. BigTech Continuous Integration

Slide 42

Slide 42 text

Engineering is about feedback loop Empirical De fi ned Chem ical Electrical Civil Aviation Aerospatial Biological Pace of innovation SpaceX

Slide 43

Slide 43 text

An iterative process Design Test Simulation 3D modeling Parallel exploration 3D printing Automated tests Fast full scale prototyping It helps the design to converge faster Shortest possible cycle time

Slide 44

Slide 44 text

An iterative process A Model X gets 27 hardware and software changes a day, 540 per month, or 5,400 each year. A legacy automaker delivers a model refresh or update earliest after 2 and often after 5-7 years. Legacy automakers avoid making because they believe it’s costly and their organization is not designed for it in short they believe it’s impossible. Because the hardware and software of Tesla vehicles change so frequently, a dedicated person from the local government works at Tesla every day to review each car and sign off on its homologation to ensure it is ready to be delivered to a customer.

Slide 45

Slide 45 text

An incremental process

Slide 46

Slide 46 text

An incremental process Most organizations thinks they will save time by starting here 2010 2013 2015 2018 2018 2019 2009

Slide 47

Slide 47 text

Risk is rewarded, failure expected “Our goal is to make it to orbit without blowing up. If the booster even does its job and something goes wrong [right after launch] with the ship, I’ll still count that as good progress. Actually, to be totally frank, if it takes off without blowing up the stand, — ‘stage zero’ [the tower, tanks, etc.] — , which is much harder to replace than the booster, that would be a victory. That’s my number-one concern”.

Slide 48

Slide 48 text

Introduce some empirical discovery in an incremental way through fast iterations that may fails Third ingredient

Slide 49

Slide 49 text

Obliquity « Strange as it may seem, overcoming geographic obstacles, winning decisive battles or meeting global business targets are the type of goals often best achieved when pursued indirectly. This is the idea of Obliquity. Oblique approaches are most effective in dif fi cult terrain, or where outcomes depend on interactions with other people. » – John Kay

Slide 50

Slide 50 text

Don’t try to « Scale » Agile, instead: - Create smalls, autonomous and cross functional teams - Provide alignment to give autonomy with clear ownership through explicit boundaries -Introduce some empirical discovery in an incremental way through fast iterations that may fails

Slide 51

Slide 51 text

www.lilobase.me Thanks ! @lilobase [email protected]