Et si on redémarrait l'agile (à l'échelle) – Agile Niort 2021

Slide 1

Slide 1 text

No content

Slide 2

Slide 2 text

Developers Project Manager / Product Manager / Product Owner Executives CEO Decisions Policies Budget Power Deadlines How to crisp.se Reports Data Clear Path of   accountability

Slide 3

Slide 3 text

Developers Project Manager / Product Manager / Product Owner Executives CEO No Decisions Under this Line Software Architectes They endure   the decisions pragmaticengineer.com

Slide 4

Slide 4 text

Developers Project Manager /   Product Manager / Product Owner Executives CEO Bureaucracy

Slide 5

Slide 5 text

Developers Project Manager /   Product Manager / Product Owner Executives CEO Bureaucracy We have to be agile You must be agile Let put agile principles everywhere

Slide 6

Slide 6 text

Developers Project Manager /   Product Manager / Product Owner Executives CEO Bureaucracy You must do daily standup You have to do planning poker You must deliver work every two weeks Pair programming is a waste of time We are late, go faster You must provide us burndown charts

Slide 7

Slide 7 text

Developers Project Manager /   Product Manager / Product Owner Executives CEO (Agile) Bureaucracy (at Scale) Maybe we can… You can’t do that because it’s against our company or team’s principles thoughtworks.com

Slide 8

Slide 8 text

Developers Project Manager / Product Manager / Product Owner Executives CEO Decisions Policies Budget Power Deadlines How to Reports Data Clear Path of   accountability (Agile) Bureaucracy (at Scale)

Slide 9

Slide 9 text

Developers Project Manager /   Product Manager / Product Owner Executives CEO How to scale Agile ?

Slide 10

Slide 10 text

www.lilobase.me Let’s reset Agile (at scale) @lilobase #AgileNiort benderlabs.io Arnaud LEMAIRE

Slide 11

Slide 11 text

Economy of Scale

Slide 12

Slide 12 text

Economy of Scale Diseconomy In Software Engineering

Slide 13

Slide 13 text

What is your team’s size ?

Slide 14

Slide 14 text

Putman 1997 QCM studies on 491 projects « We conclude that a 3-7 person team has the best performance » « The trend appears to have a exponential behavior. The most cost effective strategy is the smallest team, however the extreme nonlinear effort increase doesn’t seem to kick in until the team size approaches 9 or more people. »

Slide 15

Slide 15 text

Armel 2006 QCM studies on 600 projects « On average, Best in Class projects delivered 5 times faster and used 15 times less effort than Worst in Class projects. » « he characteristic that stood out from Don's analysis was team size. Best in Class projects used smaller teams (over 4 times smaller, on average) than the worst performers. »

Slide 16

Slide 16 text

Comstock 2011 Economies and diseconomies of scale in software development.

Slide 17

Slide 17 text

Armel 2012 QCM studies on 1060 projects « On small projects, the large teams were 3 times more costly than the small teams, and delivered 2 times as many defects. On large projects, large teams were a whopping 4 times more expensive than the small ones and delivered 3 times as many defects. »

Slide 18

Slide 18 text

Rodriguez 2012 Empirical Findings on Team Size and Productivity (951 projects) « On small projects, the large teams were 3 times more costly than the small teams, and delivered 2 times as many defects. On large projects, large teams were a whopping 4 times more expensive than the small ones and delivered 3 times as many defects. »

Slide 19

Slide 19 text

Chaos Report 2015 Standish Group study on 25000+ projects

Slide 20

Slide 20 text

Putman 2018 QCM studies on 390 projects « While the additional staff reduced the schedule by approximately 30%, the project cost actually increased by 350%. The additional staff also created 500% more defects that had to be f i xed during testing. »

Slide 21

Slide 21 text

Why small teams perform better ? - Not a signi f i cant management overhead - Minimize communication overhead - Minimize inter-locking phenomenons - Minimize over-engineering

Slide 22

Slide 22 text

Your team size may be bigger than what you think… The size of your team is the number of people who need to synchronize their work.

Slide 23

Slide 23 text

Developers Project Manager /   Product Manager / Product Owner Executives CEO Don’t scale Agile Descale your Organization

Slide 24

Slide 24 text

Create smalls, independents teams that can ship software at will without any defect.

Slide 25

Slide 25 text

www.lilobase.me Thanks ! @lilobase #AgileNiort2021 benderlabs.io

Slide 26

Slide 26 text

1. Align your teams with your problem space 2. Optimize for Continuous Delivery 3. Create Ultra High Alignment 4. Provide Real Autonomy

Slide 27

Slide 27 text

1. Align your teams with your problem space E-Commerce Team E-Marketing Team Invoice Team Stock management Shipping Full f i lement Supplier Management Payment gateway Accounting Order Management Invoicing Catalogue Search engine

Slide 28

Slide 28 text

1. Align your teams with your problem space Catalogue Payment gateway Supplier Management Invoicing Accounting Search engine Order Management Shipping Stock management Full f i lement

Slide 29

Slide 29 text

1. Align your teams with your problem space Catalogue Payment gateway Supplier Management Invoicing Accounting Search engine Order Management Shipping Stock management Full f i lement

Slide 30

Slide 30 text

1. Align your teams with your problem space Perform an inverse Conway Maneuver « HR are accidental architects of your designs software systems » « Team Assignments are the f i rst draft of the architecture » - Michael Nygard

Slide 31

Slide 31 text

E-Commerce Team 1. Align your teams with your problem space Have explicit boundaries « We Provide empirical evidence that product ambiguity exists, and it is more likely to be present across organizational and system boundaries » - Sosa & al, 2004 « « …Mismatches between product architecture and organizational structure [are] positively associated with quality problems » - Gokpinar et al, 2010 Invoice Team Order Management Invoicing

Slide 32

Slide 32 text

1. Align your teams with your problem space 2. Optimize for Continuous Delivery 3. Create Ultra High Alignment 4. Provide Real Autonomy

Slide 33

Slide 33 text

2. Optimize for Continuous Delivery Continuous Delivery Automated testing Stakeholder involvment Continuous Integration Deployment automation Unit Testing Integrated tests Infra As Code Coding standard Version Control

Slide 34

Slide 34 text

2. Optimize for Continuous Delivery Market It Shorten your Feedback Loop Team Working Software Company User

Slide 35

Slide 35 text

2. Optimize for Continuous Delivery Mesure the right things Lead Time Cycle Time Recovery Time

Slide 36

Slide 36 text

1. Align your teams with your problem space 2. Optimize for Continuous Delivery 3. Create Ultra High Alignment 4. Provide Real Autonomy

Slide 37

Slide 37 text

3. Create Ultra High Alignment Hoshin Kanri

Slide 38

Slide 38 text

3. Create Ultra High Alignment Accountability

Slide 39

Slide 39 text

3. Create Ultra High Alignment Outcome Based Roadmap Jason Doherty

Slide 40

Slide 40 text

1. Align your teams with your problem space 2. Optimize for Continuous Delivery 3. Create Ultra High Alignment 4. Provide Real Autonomy

Slide 41

Slide 41 text

4. Provide Real Autonomy Two pizza Team « Two-Pizza Teams work like semi-independent entrepreneurial hothouses. Insulated from the greater organisation’s bureaucracy » - John Rossmann

Slide 42

Slide 42 text

4. Provide Real Autonomy With a direct passthrough to the customer Team Can be internal

Slide 43

Slide 43 text

4. Provide Real Autonomy Remove hand-offs Back-end Front-end Dev Ops Team Team Dev Q&A

Slide 44

Slide 44 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 f i cult terrain, or where outcomes depend on interactions with other people. » – John Kay

Slide 45

Slide 45 text

1. Align your teams with your problem space 2. Optimize for Continuous Delivery 3. Create Ultra High Alignment 4. Provide Real Autonomy Don’t try to Scale Agile, but instead:

Slide 46

Slide 46 text

www.lilobase.me Thanks ! @lilobase benderlabs.io alemaire@quantis.fr https://roti.express/r/nysdkn