Este documento discute por qué Amazon no utiliza marcos de escalamiento ágiles y por qué otros pueden necesitarlos. Explica que Amazon se enfoca en mantener equipos pequeños y autónomos que son responsables de entregar valor directamente a los clientes, en lugar de depender de marcos prescriptivos. También proporciona consejos sobre cómo evitar la necesidad de marcos a través de prácticas como coordinación efectiva entre equipos y métricas orientadas al cliente.

1. ¿Por qué amazon
no usa un marco
de escalado y por
qué puede que tú
sí lo necesites?
Por:
Jorge H. Abad L.
@jorge_abad
Blog: http://www.lecciones-aprendidas.info/
Foto de Fondo creado por creativeart - www.freepik.es

2. ¡HOLA!
• Soy Jorge H. Abad L.
• Soy Enterprise Agile Coach
• Pueden encontrarme en:
• linkedin.com/in/jorgeabadl
• @jorge_abad
• Mi propósito es acompañar a
equipos y organizaciones para que
logren resultados grandiosos
• Amo aprender y compartir
experiencias.

3. Miremos unas definiciones

4. Agile
Agile is the ability to create and
respond to change. It is a way of
dealing with, and ultimately
succeeding in, an uncertain and
turbulent environment.AgileAlliance.org
https://www.agilealliance.org/agile101/

5. 5
Agile Alliance
https://www.agilealliance.org/glossary/business-agility
Business Agility
Business agility is the ability of an
organization to sense changes internally
or externally and respond accordingly in
order to deliver value to its customers.

6. Entendamos
un poco a

7. Principios de
1. Pasión por el cliente
2. Responsables y comprometidos
3. Inventan y simplifican
4. Tienen razón, casi siempre
5. Aprenden y son curiosos
6. Contratan y hacen crecer a los mejores
7. Insisten en los estándares más altos
8. Piensan en grande
9. Tienen iniciativa
10. Frugalidad (Los líderes logran más con menos)
11. Se ganan la confianza de los demás
12. Profundizan
13. Tienen determinación; discrepan y se comprometen
14. Obtienen resultados
https://www.amazon.jobs/es/principles
Usamos nuestros Principios de liderazgo todos los días, ya sea que estemos
discutiendo ideas para nuevos proyectos o decidiendo el mejor enfoque
para resolver un problema. Es solo una de las cosas que hace que Amazon
sea peculiar.
1. Customer Obsession
2. Ownership
3. Invent and Simplify
4. Are Right, a Lot
5. Learn and Be Curious
6. Hire and Develop the Best
7. Insist on the Highest Standards
8. Think Big
9. Bias for Action
10. Frugality
11. Earn Trust
12. Dive Deep
13. Have Backbone; Disagree and Commit
14. Deliver Results

9. Su Cultura / Su ADN
https://www.amazon.jobs/es/working/working-amazon

10. Las tres leyes de Agile
• La Ley del Cliente: una obsesión con la entrega de valor a los clientes como el todo y el fin de toda la
organización.
• La ley del equipo pequeño: la presunción de que todo el trabajo debe ser realizado por pequeños equipos
autoorganizados, que trabajan en ciclos cortos y se centran en brindar valor a los clientes, y
• La Ley de la Red: un esfuerzo continuo para eliminar la burocracia y la jerarquía de arriba a abajo para que la
empresa funcione como una red interactiva de equipos, todos enfocados en trabajar juntos para entregar un
valor creciente a los clientes.
https://www.forbes.com/sites/stevedenning/2019/05/23/understandin
g-fake-agile/#9242eb74bbe5
Steve Denning

11. 8 a 10 personas

12. 8 a 10 personas
4 a 6 personas
Es mejorSource: http://www.qsm.com/process_improvement_01.html
0
5
10
15
20
25
2 4 6 10 17
Tiempo Costos
Agregar 4 personas a un
Equipo de 6 va a atrasar el
proyecto 6 meses más

13. El Poder está en el equipo

14. Existe una corta narrativa
• Máximo 6 páginas
• No hay powerpoint
• Revisada exhaustivamente
• Contiene
• Justificación
• Beneficios de los clientes
• Preguntas frecuentes
• Las métricas que se tomarán en
tiempo real

15. Interacción con otros equipos
• “API”ficada (solo se tienen acceso
a datos por APIs)
• El equipo es dueño de sus datos
• Interfaces bien definidas
• Es una irresponsabilidad no
identificar claramente las
dependencias, ni gestionarlas
• Coordinación impecable

16. El Poder está en el equipo
• Empoderado y Autónomo
• Reportando a la alta gerencia
• Dueño del resultado
• Ante la organización
• Ante el cliente
• Obsesionado con el cliente
• Pequeño
• Métricas en tiempo real
• Métricas orientadas al cliente
• Estables al menos dos años

17. Orientación al cliente
Resultado
• Una red fuerte
• Con la mínima
burocracia viable
• Empoderada
• Orientada a generar
valor al cliente

18. ¿Qué nos da un
framework ágil?

19. ¿Qué nos da
un framework
ágil?
• Guía
• Resuelven problemas
• Buenas prácticas
• Reflejan un mindset
• Qué hacer y cuándo
• Me ayuda a verme dentro del diagrama
• Me muestra donde está el cliente
• Me muestra que artefactos voy a usar y a
generar
• Me dice como organizar los equipos
• Como gestionar las dependencias
• Traen dentro de sí un grupo de valores y
principios que tal vez yo no tenía

20. Algunos son más
prescriptivos otros más libres

21. Nexus

22. LeSS

23. SAFe

24. Scrum@Scale
Lo pintan así Pero se siente así

25. Kanban

26. Los Marcos vs. los Equipos en Amazon
Framework
Equipos
Pequeños
Empoderados
End 2 End
Gestión de dependencias
Empoderamiento del Product
Owner
Kanban No Aplica Tal vez Depende del contexto No Aplica
Scrum of Scrums Si Tal vez
Delegada en las personas.
Requiere ser impecable para
tener éxito
A nivel de equipo y requiere
coordinación con los otros Product
Owners
Nexus Si Tal vez
Delegada en las personas.
Requiere ser impecable para
tener éxito
A nivel de equipo y requiere
coordinación con los otros Product
Owners
LeSS Si Requerido
Delegada en las personas.
Requiere ser impecable para
tener éxito
A nivel de equipo y requiere
coordinación con los otros Product
Owners
Scrum @ Scale Si Requerido
Delegada en las personas.
Requiere ser impecable para
tener éxito
Solamente a nivel de equipo. El
Product Owner es coordinado por el
Chief Product Owner
SAFe Si Requerido
Garantizada e impuesta por el
framework
Solamente a nivel de equipo. El
Product Owner es coordinado por el
Program Manager.

27. Lista de
verificación
para no usar
marcos de
escalamiento
 Tienes equipos pequeños (8 personas máximo)
 Tus equipos son responsables de los resultados
ante la organización
 La coordinación entre tus equipos es impecable
 Tus líderes de Producto (Product Owners) están
completamente empoderados
 Y ellos gestionan las dependencias con otros
equipos (o entre todos colaboran)
 Lo que hacen tus equipos se encuentra “API”ficado
 Son una red de equipos sin burocracia
Están orientados radicalmente hacia los clientes

28. ¿Pero cómo evito la ruta
de los frameworks?

29. 29https://www.amazon.com/dp/B07B9F83WM/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1

30. Prácticas de organizaciones
de alto desempeño
http://services.google.com/fh/files/misc/dora_research_program.pdf
https://www.devops-research.com/research.html
Revísalo: Altamente
recomendado

31. Prácticas de organizaciones de alto desempeño
– Elementos - Causas

32. Prácticas de organizaciones de alto desempeño
– Elementos - Causas

33. Prácticas de organizaciones de alto desempeño
– Elementos -Resultados

34. Prácticas de organizaciones de alto desempeño – Elementos -
Resultados

35. Dos papers recomendados
https://itrevolution.com/acc-downloads-extra-materials/
https://itrevolution.com/book-downloads-extra-materials/

36. Toyota kata

37. Toyota kata

38. Otro camino, adoptar el
corazón de la agilidad
• Qué hacemos para:
• Mejorar nuestra colaboración
• Mejorar nuestra reflexión
• Mejorar nuestra mejora
https://heartofagile.com/?lang=es

39. La verdad…
Yo creo que no puedes evitar la
ruta de los frameworks

40. Mira los frameworks como
un punto de partida

41. Pero… ¿que tan obsesionado
estas con generarle valor a
tu cliente?
o… ¿al cliente de tu cliente?

42. y ¿qué tan empoderados están tus equipos?
¿de que métricas son responsables?
¿y esas métricas generan información valiosa?

43. ¿qué podés “copiarle” a Amazon?

44. ¿Del framework o frameworks que
usas qué podrías hacer mejor?

45. ¿Comprendes qué problemas soluciona tu
framework y sus prácticas?¿sabes cuándo
quitar o poner una práctica?

46. ¡Gracias!
• Jorge H. Abad L.
jorge.abad@gmail.com
•
@jorge_abad
• linkedin.com/in/jorgeabadl
•
• Blog http://www.lecciones-
aprendidas.info/

47. Algunas Referencias
• https://www.forbes.com/sites/stevedenning/2019/05/23/understanding-
fake-agile/#9242eb74bbe5
• https://www.forbes.com/sites/stevedenning/2019/06/02/how-amazon-
became-agile/#1c02341e31aa
• https://itrevolution.com/devops-books/

48. 48
https://assets.devopsdays.org/events/2018/toronto/DevOpsDaysTO_May31_2
018_NicoleForsgren_JezHumble.jpg
https://devopsdays.org/events/2018-toronto/program/nicole-forsgren

50. Aviso de Copyright
• Usted es libre de:
• Compartir- copiar, distribuir y trasmitir el trabajo
• Modificar- adaptar el trabajo
• Bajo las siguientes condiciones
• Atribución. Ud. debe atribuir el trabajo en la manera especificada por el autor o licenciante (pero
de ninguna manera que sugiera que ellos aprueban su uso del trabajo).
• Nada de lo dispuesto en esta licencia menoscaba o restringe los
derechos morales del autor.
• Para más información ver http://creativecommons.org/licenses/by/3.0/

51. Información de contacto
• Jorge Hernán Abad Londoño
• jorge.abad@gmail.com
• jorge.abad@tcs.com
• linkedin.com/in/jorgeabadl
• @jorge_abad