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

Transcript

2. Developers Project Manager / Product Manager / Product Owner Executives CEO Decisions Policies Budget Power Deadlines How to crisp.se Reports Data Clear Path of 
 accountability
3. Developers Project Manager / Product Manager / Product Owner Executives CEO No Decisions Under this Line Software Architectes They endure 
 the decisions pragmaticengineer.com
4. Developers Project Manager / 
 Product Manager / Product Owner Executives CEO Bureaucracy
5. Developers Project Manager / 
 Product Manager / Product Owner Executives CEO Bureaucracy We have to be agile You must be agile Let put agile principles everywhere
6. 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
7. 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
8. 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)
9. Developers Project Manager / 
 Product Manager / Product Owner Executives CEO How to scale Agile ?
10. www.lilobase.me Let’s reset Agile (at scale) @lilobase #AgileNiort benderlabs.io Arnaud LEMAIRE
11. Economy of Scale
12. Economy of Scale Diseconomy In Software Engineering
13. What is your team’s size ?
14. 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. »
15. 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. »
16. Comstock 2011 Economies and diseconomies of scale in software development.
17. 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. »
18. 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. »
19. Chaos Report 2015 Standish Group study on 25000+ projects
20. 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. »
21. Why small teams perform better ? - Not a signi f i cant management overhead - Minimize communication overhead - Minimize inter-locking phenomenons - Minimize over-engineering
22. 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.
23. Developers Project Manager / 
 Product Manager / Product Owner Executives CEO Don’t scale Agile Descale your Organization
24. Create smalls, independents teams that can ship software at will without any defect.
25. www.lilobase.me Thanks ! @lilobase #AgileNiort2021 benderlabs.io
26. 1. Align your teams with your problem space 2. Optimize for Continuous Delivery 3. Create Ultra High Alignment 4. Provide Real Autonomy
27. 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
28. 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
29. 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
30. 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
31. 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
32. 1. Align your teams with your problem space 2. Optimize for Continuous Delivery 3. Create Ultra High Alignment 4. Provide Real Autonomy
33. 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
34. 2. Optimize for Continuous Delivery Market It Shorten your Feedback Loop Team Working Software Company User
35. 2. Optimize for Continuous Delivery Mesure the right things Lead Time Cycle Time Recovery Time
36. 1. Align your teams with your problem space 2. Optimize for Continuous Delivery 3. Create Ultra High Alignment 4. Provide Real Autonomy
37. 3. Create Ultra High Alignment Hoshin Kanri
38. 3. Create Ultra High Alignment Accountability
39. 3. Create Ultra High Alignment Outcome Based Roadmap Jason Doherty
40. 1. Align your teams with your problem space 2. Optimize for Continuous Delivery 3. Create Ultra High Alignment 4. Provide Real Autonomy
41. 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
42. 4. Provide Real Autonomy With a direct passthrough to the customer Team Can be internal
43. 4. Provide Real Autonomy Remove hand-offs Back-end Front-end Dev Ops Team Team Dev Q&A
44. 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
45. 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:
46. www.lilobase.me Thanks ! @lilobase benderlabs.io alemaire@quantis.fr https://roti.express/r/nysdkn